[openjms-developer] [ openjms-Bugs-875841 ] Error performing JNDI lookups from Sun ONE App Server 7

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #875841, was opened at 2004-01-13 13:27
Message generated for change (Comment added) made by tanderson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=875841&group_id=54559

Category: jndi
Group: v0.7.6-rc3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bo Min Jiang (bmjiang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error performing JNDI lookups from Sun ONE App Server 7

Initial Comment:
When performing JNDI lookups of OpenJMS resources 
from Sun ONE App Server 7, a CORBA BAD PARAM error 
occurs, indicating that one or more classes has not been 
made serializable.

The following classes need to be made serializable:

org.exolab.jms.jndi.mipc.NameServiceProxy
org.apache.avalon.excalibur.naming.DefaultNamespace

It seems that the package 
org.apache.avalon.excalibur.naming has been 
deprecated on the Avalon site (and moved to a 
repository on codehaus.org), so I am not sure if I should 
submit a bug to the Avalon group.

----------------------------------------------------------------------

>Comment By: Tim Anderson (tanderson)
Date: 2004-01-30 00:21

Message:
Logged In: YES 
user_id=557161

Sun One App Server must be attempting to serialize the 
Hashtable after passing it to 
InitialContextFactory.getInitialContext(). 
Before your changes, the Hashtable would contain the 
RemoteContext.NAMING_PROVIDER and 
RemoteContext.NAMESPACE properties, so serialization 
failed. 

I've checked in the changes - they will be available in the 
final 0.7.6 release.

----------------------------------------------------------------------

Comment By: Bo Min Jiang (bmjiang)
Date: 2004-01-27 07:41

Message:
Logged In: YES 
user_id=645251

I added the writeObject and readObject methods (along with 
println statements for debugging) to 
org.apache.avalon.excalibur.naming.RemoteContext and 
removed the changes to make DefaultNameSpace and 
NameServiceProxy serializable. I found the following during 
testing:

1. SOAS (Sun ONE AS7) doesn't seem to invoke the methods 
writeObject and readObject of the RemoteContext class when 
performing the JNDI lookup on OpenJMS resources.

2. I got more detailed logs from SOAS by changing the logging 
level, and a ClassCastException occurs when the JNDI lookup 
is being performed - it seems that SOAS is trying to serialize 
class org.apache.avalon.excalibur.naming.DefaultNamespace, 
but throws a ClassCastException because DefaultNamespace 
is not serializable

I tried to see if the problem occurred when the 
RemoteContext instance was being created, and made some 
changes to the end of method getInitialContext in 
org.exolab.jms.jndi.mipc.IpcJndiInitialContextFactory:

Hashtable env = new Hashtable(environment);
env.put(RemoteContext.NAMING_PROVIDER, provider);
env.put(RemoteContext.NAMESPACE, namespace);
return new RemoteContext(env, parser.parse(""));

Rather than instantiate RemoteContext with the variable 
environment passed into the method, I created a new variable 
env using a copy of the data in the variable environment, and 
passed that into the RemoteContext constructor. Strangely 
enough, this change fixed the problem, and 
DefaultNameSpace and NameServiceProxy weren't even made 
serializable. I'm not exactly sure why the change works, 
though - perhaps someone has an idea.

I made the changes to 3 classes:

org.exolab.jms.jndi.mipc.IpcJndiInitialContextFactory
org.exolab.jms.jndi.http.HttpJndiInitialContextFactory
org.exolab.jms.jndi.rmi.RmiJndiInitialContextFactory

JNDI lookups from SOAS using tcp, http, and rmi are 
successful.  I also ran some of the examples and JNDI lookups 
were successful as well.

The CVS diff is in the file jndi_lookup_patch.txt

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2004-01-25 13:36

Message:
Logged In: YES 
user_id=557161

I think org.apache.avalon.excalibur.naming.RemoteContext 
needs to have the following methods added:

    private void writeObject(ObjectOutputStream out) throws 
IOException {
        out.writeObject(m_baseName);
        Hashtable env;
        if (m_environment.containsKey(NAMING_PROVIDER) ||
            m_environment.containsKey(NAMESPACE)) {
            env = new Hashtable(m_environment);
            env.remove(NAMING_PROVIDER);
            env.remove(NAMESPACE);
        } else {
            env = m_environment;
        }
        out.writeObject(env);
    }

    private void readObject(ObjectInputStream in) 
        throws IOException, ClassNotFoundException {
        in.defaultReadObject();
    }

Please verify this before  28/1 so I can include it in the final 
0.7.6 release (make sure you remove the changes to make 
NameServiceProxy and DefaultNamespace serializable first!)  

----------------------------------------------------------------------

Comment By: Bo Min Jiang (bmjiang)
Date: 2004-01-23 10:10

Message:
Logged In: YES 
user_id=645251

The stack trace for the exception is attached. The minor 
code is 6.

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2004-01-17 23:15

Message:
Logged In: YES 
user_id=557161

A more correct approach would be to implement the: 
 private void writeObject(java.io.ObjectOutputStream out)
     throws IOException
 private void readObject(java.io.ObjectInputStream in)
     throws IOException, ClassNotFoundException;
methods as per the Serializable interface, so that the 
RemoteContext.NAMING_PROVIDER and 
RemoteContext.NAMESPACE attributes of m_environment 
aren't serialized.

I'm not going to make the 2 classes Serializable for the reason 
stated previously, but if you submit a patch along the above 
lines, I will apply it.

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2004-01-17 22:30

Message:
Logged In: YES 
user_id=557161

It looks like Sun ONE App Server is trying to serialize the 
org.apache.avalon.excalibur.naming.RemoteContext class - 
which would be OK but for the fact that the m_environment 
attribute of the parent AbstractContext contains instances of 
the 2 classes you mention, which aren't Serializable.

They aren't Serializable because it doesn't make sense for 
them to be - deserializing them would result in an error.

Can you include the exception stack trace, and minor code 
with Sun One's description of the minor code, so I can 
confirm this?

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2004-01-17 22:28

Message:
Logged In: YES 
user_id=557161

It looks like Sun ONE App Server is trying to serialize the 
org.apache.avalon.excalibur.naming.RemoteContext class - 
which would be OK but for the fact that the m_environment 
attribute of the parent AbstractContext contains instances of 
the 2 classes you mention, which aren't Serializable.

They aren't Serializable because it doesn't make sense for 
them to be - deserializing them would result in an error.

Can you include the exception stack trace, and minor code 
with Sun One's description of the minor code, so I can 
confirm this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=875841&group_id=54559