A: 

Your problem is probably related to the fact that there is some native code involved here. This is even true for JCo 3. Whereas JCo 3 does not make usage of the native RFC library anymore, it still requires JNI to communicate with the CPIC layer.

Getting a JVM to unload a native library is an exercise in utmost frustration. The JNI Specification states that a native library will be unloaded when the ClassLoader associated with the class it provides the implementation to is unloaded, but trying to force a ClassLoader to unload is virtually impossible within the JVM.

If your EAR file includes the sapjco3.jar it will be reloaded each time your code is reloaded. This very likely will causes exceptions as the native library can't be loaded more than once and there is practically no way to unload native code. So you might consider to place the sapjco3.jar outside of the J2EE container and let your J2EE engine load that library once at start time rather than putting it into the EAR that gets reloaded over and over.

Tom
Yes, I've fight first with this issue (included in .ear), now sapjco3.jar and sapjco3.dll are placed in <glassfish>domains/domain1/lib/ext and works fine, the only issue is in case of SAP connection changes, therefore they aren't common, it's only necessary to restart glassfish when SAP forces a password change in the user we are connecting with. I thought in classloader way but this is black magic to me.Thanks a lot.
franblay
Even after placing sapjco3.jar under the lib/ext path, you should still be able to create, delete, change your JCo destination and provider objects as part of your container. Therefore I don't see any reason why one should not be able to alter a JCo connection object by changing any of the connection properties like its password.
Tom
Yes, yes, we can do a changePropertiesForABAP_AS whenever a change in the connection occurs... but as far as you have a "fresh" deployment of the app. If we do a redeploy, or deactivation/activation, the link between our app. and jco connection object gets broken. We can use the connection, as it is somehow alive but we can't change it. jcoDestination=JCoDestinationManager.getDestination(); works always, but after an update of the app changePropertiesForABAP_AS fails, object eventListener=NULL. We need to restart the server. Maybe I missed some point in the internals of the jco connector....
franblay
A: 

Which release of SAP are you intending to connect to? We had several problems with the Java Connector, it was not really threadsafe and could not be embedded into a EJB application properly. Same problems came with SAP's seculib for single sign on. It either didn't work. The only solution was to load it outside of the J2EE engine.

Have you ever thought of replacing the JCO with webservices? Of course it's slightly slower as the data has to go through the ICF but it's more robust. We switched all our integrations to this solution.

Matthias Kneissl
The sap connector works very well, the only issue is what i asked for and we can live with it, it's a "ugly" solution but we can afford a restart unpon a single connection change (user password mostly)I thought about web services but this is a very intensive app. with sinchronizations and BAPI executions every 5 sec. or so and sometimes big amounts of data. WS are more "asincronous" and we needed this feeling of "all under control" with RFC. But it's a way to have in mind.Thanks a lot.
franblay