9:14 a.m.
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.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:38 a.m.
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.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
3:55 p.m.
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.
>
4:50 p.m.
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
7:30 a.m.
On Thu, 2008-11-13 at 14:50 -0800, Scott Stark wrote:
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.
Or we could just bind the controller into jndi. :-)
But besides being ugly and potentially a backdoor security problem
it doesn't work if the instance is registered in a scoped controller.
The controller instance needs to be binding specific.
The real solution is to use the "referenceable" mechanism within jndi.
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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
7:31 a.m.
On Thu, 2008-11-13 at 14:50 -0800, Scott Stark wrote:
Currently naming only depends on mc artifacts for testing. I
would create a new mcnaming for the mc specific features.
Ok, I'll create a subproject within the naming project
for the MC enhancements.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
7:36 a.m.
On Fri, 2008-11-14 at 14:31 +0100, Adrian Brock wrote:
On Thu, 2008-11-13 at 14:50 -0800, Scott Stark wrote:
> Currently naming only depends on mc artifacts for testing. I
> would create a new mcnaming for the mc specific features.
Ok, I'll create a subproject within the naming project
for the MC enhancements.
I want to provide an @JNDI annotation similar to the @JMX
lifecycle to make this easier for developers.
This will be important if we ever get around to
changing our naming contexts to read-only since we
can just change the @JNDI aspect to use the new
mechansim for binding to jndi.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
8:20 a.m.
I want to provide an @JNDI annotation similar to the @JMX
lifecycle to make this easier for developers.
This will be important if we ever get around to
changing our naming contexts to read-only since we
can just change the @JNDI aspect to use the new
mechansim for binding to jndi.
How does this compare with what we already have:
-
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/aop-...
8:07 a.m.
On Fri, 2008-11-14 at 15:20 +0100, Ales Justin wrote:
> I want to provide an @JNDI annotation similar to the @JMX
> lifecycle to make this easier for developers.
>
> This will be important if we ever get around to
> changing our naming contexts to read-only since we
> can just change the @JNDI aspect to use the new
> mechansim for binding to jndi.
How does this compare with what we already have:
-
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/aop-...
I didn't know it existed. :-)
The obvious things that are missing is are:
* The on-demand processing I described.
* whether the object should be bound using the
NonSerializableObjectFactory or can be bound directly.
* What custom ObjectFactory should be used if the binding
implements Referenceable
* The abilitiy to make the object bound into jndi
aop remoteable
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5:51 a.m.
I'll have a crack at this.
Adrian, what did you mean under:
* The abilitiy to make the object bound into jndi
aop remoteable
* The on-demand processing I described.
You mean that the default ObjectFactory
takes OnDemand into an account?
Adrian Brock wrote:
On Fri, 2008-11-14 at 15:20 +0100, Ales Justin wrote:
>> I want to provide an @JNDI annotation similar to the @JMX
>> lifecycle to make this easier for developers.
>>
>> This will be important if we ever get around to
>> changing our naming contexts to read-only since we
>> can just change the @JNDI aspect to use the new
>> mechansim for binding to jndi.
> How does this compare with what we already have:
> -
>
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/aop-...
I didn't know it existed. :-)
The obvious things that are missing is are:
* The on-demand processing I described.
* whether the object should be bound using the
NonSerializableObjectFactory or can be bound directly.
* What custom ObjectFactory should be used if the binding
implements Referenceable
* The abilitiy to make the object bound into jndi
aop remoteable
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
6:07 a.m.
Ales Justin wrote:
I'll have a crack at this.
Adrian, what did you mean under:
> * The abilitiy to make the object bound into jndi
> aop remoteable
That path leads to the AOPDispatcher singleton and we don't
want to have
singletons in MC.
I would rather see the usage of ejb3-remoting2. Which can basically make
anything remotable.
And bind not the remotable ref by itself, but rather a ref via
ObjectFactory and make the remotable ref reference that one. Then you've
solved the bind remotable MC into JNDI problem.
If you want to see a lazy MC bound into JNDI in action, see
ejb3-nointerface.
The most important thing and change is that you must have an interface
to make stuff remotable, which flies against the MC POJO model.
Carlo
> * The on-demand processing I described.
You mean that the default ObjectFactory
takes OnDemand into an account?
Adrian Brock wrote:
> On Fri, 2008-11-14 at 15:20 +0100, Ales Justin wrote:
>>> I want to provide an @JNDI annotation similar to the @JMX
>>> lifecycle to make this easier for developers.
>>>
>>> This will be important if we ever get around to
>>> changing our naming contexts to read-only since we
>>> can just change the @JNDI aspect to use the new
>>> mechansim for binding to jndi.
>> How does this compare with what we already have:
>> -
>>
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/aop-...
>>
>
> I didn't know it existed. :-)
>
> The obvious things that are missing is are:
>
> * The on-demand processing I described.
>
> * whether the object should be bound using the
> NonSerializableObjectFactory or can be bound directly.
>
> * What custom ObjectFactory should be used if the binding
> implements Referenceable
>
> * The abilitiy to make the object bound into jndi
> aop remoteable
>
>> _______________________________________________
>> 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
6:13 a.m.
On Tue, 2009-05-05 at 13:07 +0200, Carlo de Wolf wrote:
Ales Justin wrote:
> I'll have a crack at this.
>
> Adrian, what did you mean under:
>
> > * The abilitiy to make the object bound into jndi
> > aop remoteable
That path leads to the AOPDispatcher singleton and we don't want to have
singletons in MC.
Its only a singleton within AOP. As long as the name used to bind
the remote object into the dispatcher is unique it doesn't matter.
I would rather see the usage of ejb3-remoting2. Which can basically
make
anything remotable.
And bind not the remotable ref by itself, but rather a ref via
ObjectFactory and make the remotable ref reference that one. Then you've
solved the bind remotable MC into JNDI problem.
The actualy mechanism should be an implementation detail,
if it is done properly.
The important part is that it should be an "aspect" not done 27
different ways in 27 different projects.
All you should have to do is something like:
<bean ...>
<annoation>(a)org.jboss.naming.JNDI(binding="/foo/bar",
remotable="true", remoteInterfaces={...})</annotation>
The implementation detail is binding some lifecycle handler
to the @JNDI annotation. What it does can change as required
(including nothing if that's what you want :-)
If you want to see a lazy MC bound into JNDI in action, see
ejb3-nointerface.
The most important thing and change is that you must have an interface
to make stuff remotable, which flies against the MC POJO model.
That's not true of AOP remoting. It doesn't need an interface but
there are some less strict constraints, e.g. the class can't be final.
Carlo
>
> > * The on-demand processing I described.
>
> You mean that the default ObjectFactory
> takes OnDemand into an account?
>
> Adrian Brock wrote:
>> On Fri, 2008-11-14 at 15:20 +0100, Ales Justin wrote:
>>>> I want to provide an @JNDI annotation similar to the @JMX
>>>> lifecycle to make this easier for developers.
>>>>
>>>> This will be important if we ever get around to
>>>> changing our naming contexts to read-only since we
>>>> can just change the @JNDI aspect to use the new
>>>> mechansim for binding to jndi.
>>> How does this compare with what we already have:
>>> -
>>>
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/aop-...
>>>
>>
>> I didn't know it existed. :-)
>>
>> The obvious things that are missing is are:
>>
>> * The on-demand processing I described.
>>
>> * whether the object should be bound using the
>> NonSerializableObjectFactory or can be bound directly.
>>
>> * What custom ObjectFactory should be used if the binding
>> implements Referenceable
>>
>> * The abilitiy to make the object bound into jndi
>> aop remoteable
>>
>>> _______________________________________________
>>> 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
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
7:03 a.m.
Adrian Brock wrote:
On Tue, 2009-05-05 at 13:07 +0200, Carlo de Wolf wrote:
> Ales Justin wrote:
>
>> I'll have a crack at this.
>>
>> Adrian, what did you mean under:
>>
>>
>>> * The abilitiy to make the object bound into jndi
>>> aop remoteable
>>>
> That path leads to the AOPDispatcher singleton and we don't want to have
> singletons in MC.
>
>
Its only a singleton within AOP. As long as the name used to bind
the remote object into the dispatcher is unique it doesn't matter.
> I would rather see the usage of ejb3-remoting2. Which can basically make
> anything remotable.
> And bind not the remotable ref by itself, but rather a ref via
> ObjectFactory and make the remotable ref reference that one. Then you've
> solved the bind remotable MC into JNDI problem.
>
The actualy mechanism should be an implementation detail,
if it is done properly.
The important part is that it should be an "aspect" not done 27
different ways in 27 different projects.
All you should have to do is something like:
<bean ...>
<annoation>(a)org.jboss.naming.JNDI(binding="/foo/bar",
remotable="true", remoteInterfaces={...})</annotation>
Hehe, remotable is also an aspect. :-)
For example I could remote it via Remoting2, Remoting3, Agnostic, RMI, etc.
The binding name in the end determines the remoting protocol.
More importantly it also determines local v.s. remote semantics of a
call. e.g. pass by ref or pass by value.
The implementation detail is binding some lifecycle handler
to the @JNDI annotation. What it does can change as required
(including nothing if that's what you want :-)
So you don't want to suddenly change the call semantic.
That's why I would rather see it stacked, in the likes of:
@JNDI(binding="/foo/bar", interfaces={...})
@JNDIFacade(binding="/foo/bar2", factory=Remoting2Factory.class,
interfaces={...}, delegateBinding="/foo/bar")
(needs work to make it more friendly)
or in EJB3 style:
@JNDI("bean/endpoint")
@Local(MyInterface.class)
@LocalBinding(jndiBinding="bean/local")
@Remote(MyRemoteInterface.class)
@RemoteBinding(factory="SomeFactory", jndiBinding="bean/remote")
> If you want to see a lazy MC bound into JNDI in action, see
> ejb3-nointerface.
>
> The most important thing and change is that you must have an interface
> to make stuff remotable, which flies against the MC POJO model.
>
>
That's not true of AOP remoting. It doesn't need an interface but
there are some less strict constraints, e.g. the class can't be final.
- must have an empty constructor
- all fields must be serializable
- should not do anything funky during construction
Basically all limitations of a no-interface EJB 3.1 view, which is only
usable locally.
So while true that it doesn't an interface, in practice I don't
recommend a no-interface approach.
Carlo
> Carlo
>
>>> * The on-demand processing I described.
>>>
>> You mean that the default ObjectFactory
>> takes OnDemand into an account?
>>
>> Adrian Brock wrote:
>>
>>> On Fri, 2008-11-14 at 15:20 +0100, Ales Justin wrote:
>>>
>>>>> I want to provide an @JNDI annotation similar to the @JMX
>>>>> lifecycle to make this easier for developers.
>>>>>
>>>>> This will be important if we ever get around to
>>>>> changing our naming contexts to read-only since we
>>>>> can just change the @JNDI aspect to use the new
>>>>> mechansim for binding to jndi.
>>>>>
>>>> How does this compare with what we already have:
>>>> -
>>>>
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/aop-...
>>>>
>>>>
>>> I didn't know it existed. :-)
>>>
>>> The obvious things that are missing is are:
>>>
>>> * The on-demand processing I described.
>>>
>>> * whether the object should be bound using the
>>> NonSerializableObjectFactory or can be bound directly.
>>>
>>> * What custom ObjectFactory should be used if the binding
>>> implements Referenceable
>>>
>>> * The abilitiy to make the object bound into jndi
>>> aop remoteable
>>>
>>>
>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
7:30 a.m.
On Tue, 2009-05-05 at 14:03 +0200, Carlo de Wolf wrote:
Adrian Brock wrote:
>
> <bean ...>
> <annoation>(a)org.jboss.naming.JNDI(binding="/foo/bar",
> remotable="true", remoteInterfaces={...})</annotation>
>
Hehe, remotable is also an aspect. :-)
For example I could remote it via Remoting2, Remoting3, Agnostic, RMI, etc.
The binding name in the end determines the remoting protocol.
More importantly it also determines local v.s. remote semantics of a
call. e.g. pass by ref or pass by value.
> The implementation detail is binding some lifecycle handler
> to the @JNDI annotation. What it does can change as required
> (including nothing if that's what you want :-)
>
So you don't want to suddenly change the call semantic.
That's why I would rather see it stacked, in the likes of:
@JNDI(binding="/foo/bar", interfaces={...})
@JNDIFacade(binding="/foo/bar2", factory=Remoting2Factory.class,
interfaces={...}, delegateBinding="/foo/bar")
(needs work to make it more friendly)
or in EJB3 style:
@JNDI("bean/endpoint")
@Local(MyInterface.class)
@LocalBinding(jndiBinding="bean/local")
@Remote(MyRemoteInterface.class)
@RemoteBinding(factory="SomeFactory", jndiBinding="bean/remote")
Yes, a different annotation is probably preferable.
But JNDI needs to know whether to bind directly or bind the "proxy"
so it will have to look for the annotation anyway and integrate
with the actual remoting mechanism.
So while true that it doesn't an interface, in practice I
don't
recommend a no-interface approach.
Nor do I, but the feature is there if you need it and it works
for you.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
6:20 a.m.
On Tue, 2009-05-05 at 12:51 +0200, Ales Justin wrote:
I'll have a crack at this.
Adrian, what did you mean under:
> * The abilitiy to make the object bound into jndi
> aop remoteable
> * The on-demand processing I described.
You mean that the default ObjectFactory
takes OnDemand into an account?
The ObjectFactory knows how to start
the pojo/service and deliver the real object when somebody
looks up the jndi binding.
If nobody looks up the jndi binding then the service
is not started.
I already have a (largely untested) implementation of
it on my disk along with some other bits in a new naming-mc-int
subproject.
It doesn't include the remoting stuff though.
Adrian Brock wrote:
> On Fri, 2008-11-14 at 15:20 +0100, Ales Justin wrote:
>>> I want to provide an @JNDI annotation similar to the @JMX
>>> lifecycle to make this easier for developers.
>>>
>>> This will be important if we ever get around to
>>> changing our naming contexts to read-only since we
>>> can just change the @JNDI aspect to use the new
>>> mechansim for binding to jndi.
>> How does this compare with what we already have:
>> -
>>
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/aop-...
>
> I didn't know it existed. :-)
>
> The obvious things that are missing is are:
>
> * The on-demand processing I described.
>
> * whether the object should be bound using the
> NonSerializableObjectFactory or can be bound directly.
>
> * What custom ObjectFactory should be used if the binding
> implements Referenceable
>
> * The abilitiy to make the object bound into jndi
> aop remoteable
>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
6:36 a.m.
On Tue, 2009-05-05 at 12:51 +0200, Ales Justin wrote:
> I'll have a crack at this.
>
> Adrian, what did you mean under:
>
> > * The abilitiy to make the object bound into jndi
> > aop remoteable
>
> > * The on-demand processing I described.
>
> You mean that the default ObjectFactory
> takes OnDemand into an account?
>
The ObjectFactory knows how to start
the pojo/service and deliver the real object when somebody
looks up the jndi binding.
If nobody looks up the jndi binding then the service
is not started.
I already have a (largely untested) implementation of
it on my disk along with some other bits in a new naming-mc-int
subproject.
It doesn't include the remoting stuff though.
Can you push this stuff in (commit it),
and I'll pick it up from there.
I'll add the remoting part or anything that we feel is missing.
I'll check what kind of hacks Carlo has done as well. :-)
Eventually trying to have a single impl.
> Adrian Brock wrote:
>> On Fri, 2008-11-14 at 15:20 +0100, Ales Justin wrote:
>>>> I want to provide an @JNDI annotation similar to the @JMX
>>>> lifecycle to make this easier for developers.
>>>>
>>>> This will be important if we ever get around to
>>>> changing our naming contexts to read-only since we
>>>> can just change the @JNDI aspect to use the new
>>>> mechansim for binding to jndi.
>>> How does this compare with what we already have:
>>> -
>>>
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/aop-...
>> I didn't know it existed. :-)
>>
>> The obvious things that are missing is are:
>>
>> * The on-demand processing I described.
>>
>> * whether the object should be bound using the
>> NonSerializableObjectFactory or can be bound directly.
>>
>> * What custom ObjectFactory should be used if the binding
>> implements Referenceable
>>
>> * The abilitiy to make the object bound into jndi
>> aop remoteable
>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
7:33 a.m.
On Tue, 2009-05-05 at 13:36 +0200, Ales Justin wrote:
> I already have a (largely untested) implementation of
> it on my disk along with some other bits in a new naming-mc-int
> subproject.
> It doesn't include the remoting stuff though.
Can you push this stuff in (commit it),
and I'll pick it up from there.
I'll add the remoting part or anything that we feel is missing.
Ok, I'll tidy it up this week and commit what I've got.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:35 a.m.
On Tue, 2009-05-05 at 14:33 +0200, Adrian Brock wrote:
On Tue, 2009-05-05 at 13:36 +0200, Ales Justin wrote:
> > I already have a (largely untested) implementation of
> > it on my disk along with some other bits in a new naming-mc-int
> > subproject.
> > It doesn't include the remoting stuff though.
>
> Can you push this stuff in (commit it),
> and I'll pick it up from there.
>
> I'll add the remoting part or anything that we feel is missing.
>
Ok, I'll tidy it up this week and commit what I've got.
This has been committed.
https://jira.jboss.org/jira/browse/JBNAME-32
Its in naming trunk in the new naming-mc-int subproject.
This will need some tweaking for all the other things we discussed.
The biggest one being the "remotability".
There are some basic tests of the feature, but they obviously
need more coverage.
If you use the BootstrapNamingTest in your tests, you should
automatically have the jndi server and
the relevant aspects configured - see the
shared bootstrap.xml config in the src/resources/tests
I also tidied up the maven build and updated to more recent
versions of the thirdparty jars while I was there.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
3:40 p.m.
Adrian, was this ever committed somewhere?
Scott Stark wrote:
Ok by me.
Adrian Brock wrote:
> On Fri, 2008-11-14 at 14:31 +0100, Adrian Brock wrote:
>
>> On Thu, 2008-11-13 at 14:50 -0800, Scott Stark wrote:
>>
>>> Currently naming only depends on mc artifacts for testing. I
>>> would create a new mcnaming for the mc specific features.
>>>
>> Ok, I'll create a subproject within the naming project
>> for the MC enhancements.
>>
>
> I want to provide an @JNDI annotation similar to the @JMX
> lifecycle to make this easier for developers.
>
> This will be important if we ever get around to
> changing our naming contexts to read-only since we
> can just change the @JNDI aspect to use the new
> mechansim for binding to jndi.
>
------------------------------------------------------------------------
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5:42 a.m.
On Mon, 2009-05-04 at 22:40 +0200, Ales Justin wrote:
Adrian, was this ever committed somewhere?
No. It needs a change to the transaction manager setup to make
it work properly.
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=145582
Scott Stark wrote:
> Ok by me.
>
> Adrian Brock wrote:
>> On Fri, 2008-11-14 at 14:31 +0100, Adrian Brock wrote:
>>
>>> On Thu, 2008-11-13 at 14:50 -0800, Scott Stark wrote:
>>>
>>>> Currently naming only depends on mc artifacts for testing. I
>>>> would create a new mcnaming for the mc specific features.
>>>>
>>> Ok, I'll create a subproject within the naming project
>>> for the MC enhancements.
>>>
>>
>> I want to provide an @JNDI annotation similar to the @JMX
>> lifecycle to make this easier for developers.
>>
>> This will be important if we ever get around to
>> changing our naming contexts to read-only since we
>> can just change the @JNDI aspect to use the new
>> mechansim for binding to jndi.
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
7:23 a.m.
On Thu, 2008-11-13 at 22:55 +0100, 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.
Which part of "pseudo code" didn't you understand. ;-)
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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5706
days inactive
5880
days old
jboss-development@lists.jboss.org
21 comments
4 participants
participants (4)
-
Adrian Brock -
Ales Justin -
Carlo de Wolf -
Scott Stark