JBAS-2528 - NonSerializableFactory(-ies)

[mnasato]

Discussion thread for http://jira.jboss.com/jira/browse/JBAS-2520

"Mirko Nasato" wrote:

NonSerializableFactory uses the atom as the key in its map. If you bind

java:/app1/MyObject

using rebind(Context ctx, String key, Object target) as suggested in the old documentation (the JNDIMap example)

http://www.huihoo.com/jboss/online_manual/3.0/ch13s26.html

and then bind

java:/app2/MyObject

the second object overwrites the first one, so when you lookup "java:/app1/MyObject" you actually get the second one.

See also

http://sourceforge.net/mailarchive/message.php?msg_id=12501043

"Mirko Nasato" wrote:

Problem originally found in the mbean shipped with the Quartz scheduler

http://jira.opensymphony.com/browse/QUARTZ-303

"Adrian Brock" wrote:

So use the EJB3 version.

I've changed to a feature to merge the two implementations, or more accurately use the EJB3 version.

"Mirko Nasato" wrote:

As said the problem wasn't with my code but with Quartz, for which I have proposed a fix already. I am reporting the bug in case it may affect some other old code around.

"Adrian Brock" wrote:

It isn't a bug. You must give the NSOF a unique name.
The EJB3 implementation does not have this requirement.

If you want to discuss it further, use the forums.

[mnasato]

So then my question is: why should I use the factory in the EJB3 package if my code has nothing to do with EJB3?

If org.jboss.util.naming.NonSerializableFactory has this limitation and cannot be easily changed because that would break existing code, why not deprecate it and add the new implementation in the same org.jboss.util.naming package?

[mnasato]

Sorry, the corret link to the Jira issue is

http://jira.jboss.com/jira/browse/JBAS-2528

[starksm64]

You could use the ejb3 version by copying its 50 lines of code into your own object factory implementation. You do not have to introduce an dependency on all of the ejb3 codebase.

You could use the mechanism used by the ejb3 version to resolve the context local name into a globally unique name to pass into the org.jboss.util.naming.NonSerializableFactory:

 Name name = ctx.getNameParser("").parse(strName);
 int size = name.size();
 String atom = name.get(size - 1);
 // The globally unique key
 String key = parentCtx.getNameInNamespace() + "/" + atom;

I don't see where it has been said that the org.jboss.util.naming.NonSerializableFactory cannot be changed to use this approach to ensure uniqueness. It should be done.

[mnasato]

You could use the ejb3 version by copying its 50 lines of code into your own object factory implementation.

I am not sure my company would be happy to release our whole application as LGPL because of those 50 copied lines. ;-)

Anyway the existing org.jboss.util.naming.NonSerializableFactory already works well enough if you use rebind(Name name, Object target) instead of rebind(Context ctx, String key, Object target) and that's what I submitted to Quartz as a patch to their service mbean.

So I don't have an immediate problem to solve. I did have a big problem in my company because of this but I fixed it already. What I am complaining about is that the API is confusing and people easily shoot themselves (or somebody else) in the foot. And having another NonSerializableFactory in a different package just adds to the confusion.

I guess that in more general terms the difficulty for you JBoss developers is to realise which classes are part of a "published API" that other people will use and which ones are for "internal" use only.

I don't see where it has been said that the org.jboss.util.naming.NonSerializableFactory cannot be changed to use this approach to ensure uniqueness.

That's my own statement, after a quick look at the code. Seems to me that you can easily change rebind(Context ctx, String key, Object target) but not unbind(String key) because it's missing the Context. You'd need an unbind(Context ctx, String key) instead, like in new EJB3 implementation. But if you change the method signature you break old code. Which may be the right thing to do in this case?