Having a singleton will result in the same hassles as we see with the
URL stream handler factory and the like. For example, what if you have
multiple frameworks running in one VM? What if multiple people try to
set the static?
Addressing the problem depends somewhat on who is expected to provide
the class name, the lifecycle of the resultant singleton and what
happens in the case of conflicts.
Check out the URLStreamHandlerService for an OSGi example of the this
kind of situation. (may be a bit difference because the URL scenarios
requires that things be added and removed...). You might also look at
the Equionx implementations of this to see the contortions that we have
to go through to deal with the static.
Jeff
Alan Cabrera wrote:
I'm currently implementing a spec, JSR319, which has an agent factory
that seems dictate that one should instantiate an agent singleton
using a system property to specify the agent's class name; the class
is AvailabilityAgentFactory. So, IIUC, this requires that I use
Class.forName() to instantiate it.
Now, having attended brother Hargrave's traveling salvation show
where he preached about the evils of Class.forName(), I'm obviously a
little nervous about my immortal soul. Luckily the spec is still in
early draft review. I wonder what to recommend to them.
My current thinking is to ask them to provide a static
setAvailabilityAgent to set the singleton instead of instantiating
it. This will allow OSGi implementations better control over where
the agent gets instantiated.
Thoughts?
It sure would be cool to have a white paper to hand to these Expert
Groups on how to behave nicely in an OSGi world.
Regards,
Alan
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
