Re: [jboss-dev] On demand JCA and JTA for the web-profile

We could have an javax.naming.spi.InitialContextFactoryBuilder that was KernelControllerContextAware and looked up the InitialContextFactory bean given by a name in the environment properties so that this could be done. I was going to add such a builder to the new externalized and mcized naming project extension. This ObjectFactory could go in that project. Currently naming only depends on mc artifacts for testing. I would create a new mcnaming for the mc specific features.

Carlo de Wolf wrote: > Finally you're entering the JNDI ring. :-) > > An object factory must have a no-argument public constructor, because > it's constructed by the naming server. So you can't have a controller > as a field in there. > > Carlo > > Adrian Brock wrote: >> Related to this, where's the best place to put a generic on-demand >> jndi ObjectFactory? >> Is this something that should go in the naming project? >> >> i.e. something like the following pseudo code: >> >> private Controller controller; >> >> private String contextName; >> >> public class OnDemandObjectFactory implements ObjectFactory >> { >> >> public Object getObjectInstance(Object obj, Name name, Context >> nameCtx, Hashtable<?,?> environment) throws Exception >> { >> ControllerContext context = controller.getContext(contextName); >> if (context == null) >> throw new RuntimeException("No such context: " + contextName); >> // Not started so bootstrap it >> if (ControllerState.INSTALLED.equals(context.getState()) == false) >> { >> controller.changeState(contextName, ControllerState.INSTALLED); >> if (ControllerState.INSTALLED.equals(context.getState()) == false) >> throw new RuntimeException("Could not install context: " + >> contextName); >> } >> return context.getTarget(); >> } >> } >> >> On Thu, 2008-11-13 at 16:14 +0100, Adrian Brock wrote: >> >>> See: >>> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189122#... >>> >>> >>> This will be the first real use of the "new" on-demand processing. >>> >>> The idea is that unless the webapp looks up a user transaction >>> or transaction synchronization registry (there's a sticking point >>> there) or the admin deploys a transactional datasource, then jca and >>> jta won't bootstrap by default. >>> >>> This won't effect the other configurations since we always provide >>> a transactional datasource out-of-the-box for jms persistence >>> and other services reference the transaction manager anyway >>> so they will always bootstrap. >>> > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development