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