[ openjms-Bugs-875841 ] Error performing JNDI lookups from Sun ONE App Server 7
"SourceForge.net" <[email protected]>
| Newsgroups | gmane.comp.java.openjms.devel |
|---|---|
| Message-ID | <[email protected]> |
Bugs item #875841, was opened at 2004-01-13 02:27
Message generated for change (Comment added) made by bmjiang
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: Open
Resolution: None
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: Bo Min Jiang (bmjiang)
Date: 2004-01-26 20: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 02: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-22 23: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 12: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 11: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 11: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
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn