Class location problems...

Classic Servoy
1

Hi All,

I have a plugin that will be an interface to a complex .NET web service using the SUN WSIT (Web Services Interoperability Technology - or something similar to that - intended to provide compatibility between the next Microsoft iteration of web services and Java) classes. I’m testing now with Servoy 3 and the Java 1.6 beta to have the required SUN classes included in the JRE.

The WSIT wsimport tool creates stub classes from a wsdl document description that are used within the custom java code to make calls on the .NET server functions and receive the results. Within Eclipse, everything works just fine. However, when I move the plugin to Servoy, I receive an error (I’m logging these myself from within the plugin as Servoy doesn’t find out about them) that ONE of the many stub classes cannot be found (not even one that I use). The class is within the *jar file (and I’ve tried packing all the generated stub file classes within the same jar as my code, as well as separately in their own .jar file and loading them from the *.jnlp file with the same result).

I suspect that I’m missing something obvious (ignorance of the ‘newbie’ to java…) but, although it may be obvious to some, it obviously isn’t to me! Can anyone provide a bit of insight to the lost?

Thanks greatly in advance!

Pete

2

I found an issue with Servoy when you try to load the classes dynamically. Is that what you try to do? Everything needs to be in the plug-ins directory.

Further I, (but that could be me), think this kind of info is way to generic. It can be too much, that is your issue while debugging, but certainly my issue ehn trying to help you…

3

Hi Marcel,

I’m not trying to be generic! I guess I’m afraid that extreme details… such as which classes call what… will just get confusing. It all gets pretty detailed and confusing pretty quickly! :) But let me try to be better!

I am attempting to load all the classes immediately when Servoy initializes the plugins. At that point I instantiate all my main objects, which make calls on the tool-generated web client stubs, which in turn call functions in the Sun classes. It seems that these look back to the stubs during their initialization and it is during this period that the problem arises.

Here’s a stack trace from inside of my plugin…

Mon Nov 13 12:36:51 EST 2006 ERevisionsAccess: ERevisionsProvider: Processing call to ERevisionsProvider(ilog)prior to new ERevisionsAccess.
Mon Nov 13 12:36:53 EST 2006 Error in ERevisionsAccess(ilog): class: ERevisionsWSDL.GetLine could not be found
com.sun.xml.ws.modeler.RuntimeModeler.getClass(Unknown Source)
com.sun.xml.ws.modeler.RuntimeModeler.processDocWrappedMethod(Unknown Source)
com.sun.xml.ws.modeler.RuntimeModeler.processMethod(Unknown Source)
com.sun.xml.ws.modeler.RuntimeModeler.processClass(Unknown Source)
com.sun.xml.ws.modeler.RuntimeModeler.buildRuntimeModel(Unknown Source)
com.sun.xml.ws.client.ServiceContextBuilder.processAnnotations(Unknown Source)
com.sun.xml.ws.client.ServiceContextBuilder.completeServiceContext(Unknown Source)
com.sun.xml.ws.client.WSServiceDelegate.processServiceContext(Unknown Source)
com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(Unknown Source)
com.sun.xml.ws.client.WSServiceDelegate.getPort(Unknown Source)
javax.xml.ws.Service.getPort(Unknown Source)
ERevisionsWSDL.ERevisions.getERevisionsSoap(ERevisions.java:50)
com.adblocks.wsit.erevisions.basicplugin.ERevisionsAccess.(ERevisionsAccess.java:102)
com.adblocks.wsit.erevisions.basicplugin.ERevisionsProviderWindow.(ERevisionsProviderWindow.java:40)
com.adblocks.wsit.erevisions.basicplugin.ERevisionsProvider.(ERevisionsProvider.java:101)
com.adblocks.wsit.erevisions.basicplugin.ERevisionsBasicPlugin.initialize(ERevisionsBasicPlugin.java:140)
com.servoy.j2db.plugins.PluginManager.initClientPlugins(Unknown Source)
com.servoy.j2db.J2DBClient$7.run(Unknown Source)
com.servoy.j2db.util.am.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
Mon Nov 13 12:36:53 EST 2006 ERevisionsAccess: ERevisionsProvider: Processing call to ERevisionsProvider(ilog); er: com.adblocks.wsit.erevisions.basicplugin.ERevisionsProviderWindow[win0,0,0,0x0,invalid,hidden,layout=java.awt.BorderLayout,rootPaneCheckingEnabled=true]
Mon Nov 13 12:37:09 EST 2006 ERevisionsAccess: Processing call to unLoad.

The ERevisionsXXX are my classes in this plugin. The ERevisionsWSDL.XXX are classes generated as stubs by the web services tool (wsimport) either in the Netbeans plugin or from a command line. The last call that I wrote is the

com.adblocks.wsit.erevisions.basicplugin.ERevisionsAccess.(ERevisionsAccess.java:102)

that starts the whole thing off…

Because this works in Eclipse, there must be some path/classpath or other little problem that I’m missing such that the stub classes aren’t found by the WSIT classes, but I can’t figure out what it might be or how to fix it. The *.jar that includes the ERevisionsWSDL.XXX class (the stubs) also contains a classpath within the manifest that ‘points’ to a ‘lib’ subdirectory. I’ve placed this within the directory used by the *.jnlp file (where the ERevisionsWSDL jar resides) as it is in the structure for the Eclipse, and the paths are relative (so they should be correct, I think).

My directory structure is as below

Servoy (Dir)
—|
…----Plugins (Dir)-|
…----BasicErevisionsPlugin.jar
…----BasicErevisionsPlugin.jnlp
…----BasicErevisionsPlugin (Dir)–|
…— ERevisionsWSDL.jar
…—lib (Dir)
…—Sun.*.jar files used by the stubs in ERevisionsWSDL pointed to by classpath variable within ERevisionsWSDL.jar manifest

The Sun.*.jar files seem to be found and called, but they, in turn, appear to need the stub files in the directory above them, and cannot find at least one of these files (the getLine.class). This is my last attempt at making things work. Might I be correct in assuming that the problem is these files that are within that nested ‘lib’ directory? Maybe the classpath that is included in the ERevisionsWSDL.jar cannot be used within Servoy… then where should they go?

I don’t mean to inundate you with details this time! You’ve been very sweet to offer to help and I appreciate it, but getting that ‘middle ground’ of enough detail, but not way too much detail, is a challenge! :wink:

If this hasn’t sent you packing, I’d love any thoughts you have!

Thank you!

Pete