# Where to put application-specific classes when not using Webster under GS7

Where is it recommended that one put application specific classes/jars that one wants GS to know about under GS 7.0, when not using Webster / codebase / etc.

Under GS 6.x, application-specific classes placed in the GigaSpaces/lib dir, for instance, would be found -- remote applications could write such classes to the space with no trouble. Now, under GS 7.0,. when trying to have a remote application write classes to a space that the space server has not seen before, I now get the following error:

SEVERE [com.gigaspaces.persistent] - Catch exception during traveling with Iterator of StorageAdaptorEntries.; Caused by: java.lang.ClassNotFoundException: com.mycompany.myproduct.myclass
at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at com.j_spaces.sadapter.GenericJDBC.SAUtilities.getObjectFromBytes(SAUtilities.java:136) at com.j_spaces.sadapter.GenericJDBC.SAUtilities.getDynamicParameters(SAUtilities.java:204) at com.j_spaces.sadapter.GenericJDBC.SAUtilities.getFieldsValues(SAUtilities.java:353) at com.j_spaces.sadapter.GenericJDBC.SAUtilities.getEntry(SAUtilities.java:317) at com.j_spaces.sadapter.GenericJDBC.SAEntriesIter.nextMatchEntry(SAEntriesIter.java:221) at com.j_spaces.sadapter.GenericJDBC.SAEntriesIter.next(SAEntriesIter.java:146) at com.j_spaces.sadapter.GenericJDBC.SAEntriesIter.next(SAEntriesIter.java:54) at com.j_spaces.sadapter.GenericJDBC.JDBCStorageAdapter.count(JDBCStorageAdapter.java:5261) at com.gigaspaces.internal.server.space.SpaceEngine.getPersistentRuntimeInfo(SpaceEngine.java:2552) at com.gigaspaces.internal.server.space.SpaceEngine.getRuntimeInfo(SpaceEngine.java:2614) at com.gigaspaces.internal.server.space.SpaceEngine.getRuntimeInfo(SpaceEngine.java:2578) at com.gigaspaces.internal.server.space.SpaceImpl.getRuntimeInfo(SpaceImpl.java:1333) at com.j_spaces.core.admin.JSpaceAdminImpl.getRuntimeInfo(JSpaceAdminImpl.java:84) at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.gigaspaces.lrmi.LRMIRuntime.invoked(LRMIRuntime.java:372) at com.gigaspaces.lrmi.nio.Pivot.consumeAndHandleRequest(Pivot.java:379) at com.gigaspaces.lrmi.nio.Pivot.handleRequest(Pivot.java:467) at com.gigaspaces.lrmi.nio.Pivot$ChannelEntryTask.run(Pivot.java:146) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)

Previously, if I had a missing application-specific class, I would get a de-serialization error in GS.

I would like to know if this stack trace represents the same error, or a similar condition, and how to avoid this error. Also, if there is a special location where such application-specific classes should reside, when not using Webster, I need to know this as well.

thanks,

-dave

edit retag close merge delete

Sort by » oldest newest most voted

Dave,

Are you having this problem when you disable persistency (not using the storage adapter)?

The storage adapter is not the recommended way to persist data. You should use the EDS approach that allows you to map objects to tables via Hibernate.

Shay

more

http://www.gigaspaces.com/wiki/displa...

I have copied my application specific jar files into the lib/optional/pu-common directory. However, it is not obvious to me that this makes sense to do. We are not deploying services in PU's. However, our space is cranked up by GSM/GSC. I find now that my client application can write entries into the space now without an exception, but once I quit the client app and re-connect to the space and attempt to read these entries back out, I get the same exception / stack dump on the space server.

thanks,

-dave

more

In general missing classes at the space side are loaded from the client side on the fly via GigaSpaces remote dynamic classloading technology added with XAP 7.0. This avoid de-serialization problems we had with user defined fields.

If you want to avoid the de-serialization activity (and you are not running a local cache) you can run in light serialization mode. This might speed a bit the remote operations performance.

If you want to avoid any dynamic classloading (and use the default serialization mode) you should place relevant jars as part of the PU jar lib folder (one that will just start a space) , or within the pu-common folder found under one of the folder under the Gigaspaces root/lib.

Shay

( 2009-08-27 06:00:21 -0600 )edit

Shay,

We are just trying to quickly move our system from GS6.x to GS7.0 -- we are not trying to add anything new to it (ie... we do not want to implement the Hibernate mapping, etc). At this point, we just want to be able to use GS7 as a space server to store and retrieve Entries as we do under GS 6.x --- I do not know that we made any conscious choice about using a "storage adapter" -- do you mean whether we are running the space in persistent mode or not? This is a persistent space, for instance, but we have not changed anything from how we were doing this in 6.x. As I said before, we just want to store Entries in the space -- we are not interested in suddenly implementing HIbernate mapping -- we are just trying to run our existing app under GS7.

Under GS6.x, we used full serialization, so that the GS server had to have the classes or JARs for any classes that were referenced from within the Entries we were storing in the space. We want to follow that same model here for the moment (our goal is to quickly move to GS7, not re-implement our system). I'm aware of the serialization modes that existed in GS6.x - we had at one time toyed with turning it off, but instead put our classes / jars in the right place. Exactly which serialization mode under 7.0 should we then use?

As I said in my second post, I tried putting our application-specific jars in GigaSpaces/lib/optional/pu-common -- but I was unsure whether this was the correct thing to do. Is there a better place to put these jars? At the moment, putting our internal jars in pu-common did not seem to help. Should these jars just be in GigaSpaces/lib/ ??? Or is somewhere else better?

thanks,

-dave

( 2009-08-27 06:47:57 -0600 )edit

If placing your libraries under /lib/optional/pu-common does not help - you should report this to the support team. This is one way to resolve the problem. Another option you might want to try is to create a jar with relevant pu.xml (with the space tags) and application jars within the lib folder and deploy it.

Shay

( 2009-08-27 07:57:45 -0600 )edit

Shay,

Under GS6.x, we used full serialization, so that the GS server had to have the classes or JARs for any classes that were referenced from within the Entries we were storing in the space. We want to follow that same model here for the moment (our goal is to quickly move to GS7, not re-implement our system). I'm aware of the serialization modes that existed in GS6.x - we had at one time toyed with turning it off, but instead put our classes / jars in the right place. Exactly which serialization mode under 7.0 should we then use?

thanks,

-dave

( 2009-08-27 09:10:13 -0600 )edit

I am seeing some different behavior if I unzip a JAR file into a class hierarchy (ie... a bin directory contents com/mycompany/myproduct/mymodule/...) directly into the lib directory.

Should I be putting JAR files directly in the lib directory or should I dump a bin directory in there instead?

thanks,

-dave

( 2009-08-27 10:19:44 -0600 )edit