I think it would be better to have a static getAgent method. The implementation of this method can be written or modified to handle the deployment environment. When running in OSGi, it could lookup the agent in the OSGi service registry. When running without OSGi, it could use a system property to load and instantiate the agent.
This is how one can implement XML Parsers in OSGi. See section 702. The JAXP static get factory methods can be implemented to locate the parser implementation via the OSGi service registry. But as Jeff pointed out, having a singleton agent seems a bad idea in the first place... -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Alan Cabrera <[EMAIL PROTECTED]> To: OSGi Developer Mail List <[EMAIL PROTECTED]> Date: 2008/06/29 11:49 AM Subject: [osgi-dev] Class.forName() 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
