Object Factories: Java vs C#

[kwaclaw]

I am writing both, Java and .NET clients against the same Slice definitions of classes without methods (only data members). All works fine with .NET, but in Java I get Ice.NoObjectFactoryException errors, and I only get my client working once I add the appropriate factories. This is with ICE 3.2.1.

This seems to contradict the docs, with state (for both, java and C#) that one does not need to register an object factory for classes that only have data members.

One example of the Slice definitions I am using is:

  ["clr:property"]
  class State {
    string Key;
    string CountryKey;
    string Id;
    string Name;
  };
  
  sequence<State> StateSeq;

  ["clr:property"]
  class Country {
    string Key;
    string Id;
    string Name;
    StateSeq States;
  };

  sequence<Country> CountrySeq;

  ["ami", "amd"] interface CommonServices {
    ...
    idempotent OpStatus GetCountries(out CountrySeq countries)
      throws ServiceError;
    ...
  };

Calling GetCountries() throws an Ice.NoObjectFactoryException. Is this my error, a problem with the docs, or a bug in ICE for Java?

Regards,

Karl

[mes]

Hi Karl,

By any chance are you specifying a Java package via metadata? If so, that can cause object unmarshaling to fail. Briefly, to unmarshal an object, the Ice run time converts an object's type id as it is sent over the wire into a classname (such as Acme::Widget into Acme.Widget) and the run time attempts to load that class dynamically. However, if you specify package metadata, the name of the Java class changes to something the Ice run time cannot predict, therefore you need to take additional action.

See the manual for details.

Take care,
- Mark

[kwaclaw]

Hi Karl,

By any chance are you specifying a Java package via metadata? If so, that can cause object unmarshaling to fail. Briefly, to unmarshal an object, the Ice run time converts an object's type id as it is sent over the wire into a classname (such as Acme::Widget into Acme.Widget) and the run time attempts to load that class dynamically. However, if you specify package metadata, the name of the Java class changes to something the Ice run time cannot predict, therefore you need to take additional action.

No, I have not added any metadata directives for Java to my Slice definitions.
The application is a JBOSS application, if that helps. All I am doing to use ICE is I am adding Ice.jar into the class path, and I am using slice2java to generate the Java classes.

See the manual for details.

Take care,
- Mark

On a first read, I am not sure this applies to my situation, but admittedly I am no Java expert.

Regards,

Karl

[mes]

As long as the class files for the generated code are in your CLASSPATH, the Ice run time should be able to unmarshal the objects. And I assume that the class files are in your CLASSPATH, otherwise your program wouldn't be able to run. Unless of course you are using Dynamic Ice to invoke GetCountries.

It would also be helpful to see the full stack trace of the exception.

- Mark

[kwaclaw]

As long as the class files for the generated code are in your CLASSPATH, the Ice run time should be able to unmarshal the objects. And I assume that the class files are in your CLASSPATH, otherwise your program wouldn't be able to run. Unless of course you are using Dynamic Ice to invoke GetCountries.

No, I am not using dynamic Ice, and the class path should be OK, otherwise the application would not run at all. The class path is to some degree configured on JBOSS, as the application is deployed into a JBOSS directory.

It would also be helpful to see the full stack trace of the exception.

- Mark

See below. Pretty long, but you asked for it. :-)

Regards,

Karl

Stack trace:

Ice.NoObjectFactoryException
reason = ""
type = "::IServices2ICE::Country"
at IceInternal.BasicStream.readObject(BasicStream.jav a:1343)
at IceInternal.BasicStream.readPendingObjects(BasicSt ream.java:1554)
at IServices2ICE._CommonServicesDelM.GetCountries(_Co mmonServicesDelM.java:147)
at IServices2ICE.CommonServicesPrxHelper.GetCountries (CommonServicesPrxHelper.java:184)
at IServices2ICE.CommonServicesPrxHelper.GetCountries (CommonServicesPrxHelper.java:156)
at iservices.WsCountryList.doGet(WsCountryList.java:4 0)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:697)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:810)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doF ilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve .invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationV alve.invoke(SecurityAssociationValve.java:159)
at org.jboss.web.tomcat.security.JaccContextValve.inv oke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11Conn ectionHandler.processConnection(Http11Protocol.jav a:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread .run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Unknown Source)

[mes]

Hi Karl,

We don't have much experience with servlets, but I suspect the problem is caused by a Web server configuration issue or a security restriction that prevents the Ice run time in your servlet from loading a class dynamically, or a combination of the two. For example, perhaps the Web server only permits classes from a particular directory to be loaded dynamically.

You should be able to verify with a simple standalone client that the unmarshaling works. If you still can't resolve the issue, I think your only recourse is to install object factories.

Take care,
- Mark

[kwaclaw]

Hi Karl,

We don't have much experience with servlets, but I suspect the problem is caused by a Web server configuration issue or a security restriction that prevents the Ice run time in your servlet from loading a class dynamically, or a combination of the two. For example, perhaps the Web server only permits classes from a particular directory to be loaded dynamically.

You should be able to verify with a simple standalone client that the unmarshaling works. If you still can't resolve the issue, I think your only recourse is to install object factories.

Take care,
- Mark

Yes, it works with a simple console application.
I guess you are right, its probably a JBOSS security issue.

Thanks for the help,

Karl

[kwaclaw]

Hi Karl,

We don't have much experience with servlets, but I suspect the problem is [CODE]caused by a Web server configuration issue or a security restriction that prevents the Ice run time in your servlet from loading a class dynamically, or a combination of the two. For example, perhaps the Web server only permits classes from a particular directory to be loaded dynamically.

You should be able to verify with a simple standalone client that the unmarshaling works. If you still can't resolve the issue, I think your only recourse is to install object factories.

Take care,
- Mark

Just one more observation to add: Not so sure that security is an issue, because dynamic class loading actually works. I simply installed a default object factory that basically does the same thing the ICE runtime does. Here is the main method:

  public Object create(String type) {
    type = type.substring(2);
    String className = type.replaceAll("::", ".");
    try {
      Class c = Class.forName(className);
      return (Object)c.newInstance();
    }
    catch (Exception ex) {
      assert(false);
      return null;
    }
  }

This seems to work without problems.

Karl

[ganzuoni]

No, I have not added any metadata directives for Java to my Slice definitions.
The application is a JBOSS application, if that helps. All I am doing to use ICE is I am adding Ice.jar into the class path, and I am using slice2java to generate the Java classes.

In which directory of your JBOSS installation are you putting the jar ?

On a first read, I am not sure this applies to my situation, but admittedly I am no Java expert.

Regards,

Karl

Well, taming the beast (JBOSS/J2EE) without being a Java expert could be a very exciting experience, really
(It reminds me an editorial of a Connections Issue about learning C++ in 10 easy lessons - or something similar).


Good luck

Guido

[kwaclaw]

In which directory of your JBOSS installation are you putting the jar ?

I am putting it into ..\jboss-4.0.3SP1\server\default\lib .

Well, taming the beast (JBOSS/J2EE) without being a Java expert could be a very exciting experience, really
(It reminds me an editorial of a Connections Issue about learning C++ in 10 easy lessons - or something similar).
Guido

Luckiliy I just had to do a proof of concept for using ICE with Java, and the experts are now taking over. :-)

Karl

[ganzuoni]

I am putting it into ..\jboss-4.0.3SP1\server\default\lib .

Remove from there and put in WEB-INF/lib of your webapp.
Guido

[kwaclaw]

Remove from there and put in WEB-INF/lib of your webapp.
Guido

Yes, that works!!! Many thanks!

Not sure why, though, as my own object factory did work, just not the default one built into Ice.jar.

Karl

[ganzuoni]

Yes, that works!!! Many thanks!

Not sure why, though, as my own object factory did work, just not the default one built into Ice.jar.

Karl

Maybe ICE does not use the classloader attached to the current thread, so it cannot "see" classes that are loaded by the classloader of your webapp.
You object factory instead is loaded by your webapp classloader.

Guido

[kwaclaw]

Maybe ICE does not use the classloader attached to the current thread, so it cannot "see" classes that are loaded by the classloader of your webapp.
You object factory instead is loaded by your webapp classloader.

Guido

Yes, one of my avenues of research was to find out how JBOSS and ICE use class loaders, but obviously I didn't find the answer ...

Thanks for your insights!

Karl

[ganzuoni]

Yes, one of my avenues of research was to find out how JBOSS and ICE use class loaders, but obviously I didn't find the answer ...

Thanks for your insights!

Karl

Beware of JBOSS classloader. I could run into troubles if you need to use
different version of the same product in different web apps.
Even if you put each jar in its onw app.
I prefer Tomcat that has a clean and clever classloader architecture.

Guido.