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

Discussion:

SourceForge.net

2004-01-22 23:10:10 UTC

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-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

SourceForge.net

2004-01-25 02:36:07 UTC

Permalink

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: 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.

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

Post by SourceForge.net
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

SourceForge.net

2004-01-26 20:41:18 UTC

Permalink

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

SourceForge.net

2004-01-29 13:21:21 UTC

Permalink

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