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