Configuring a container for POJOs

[adrian.brock]

So I've committed the intial version of the POJO container.
It is still a prototype (with some horrible hacky code in parts) but it does the job
for the initial M1 release.

You can now configure a set of *single* set interceptors for a POJO
and it will put a proxy container in front of it. Obviously you need an interface
to make this work (this constraint will disappear when we integrate JBoss/AOP).

The key part is that the interceptors are configurable just like other beans
so they can take part in the dependency/configuration mechanism.

Here's an example from one of my tests. The key part here is that the interceptor
has a constructor that must wait for another bean to be created so the bean
it intercepts is also delayed.

<?xml version="1.0" encoding="UTF-8"?>

<deployment>
 <beans>

 <!-- The intercepted bean -->

 <bean name="SimpleBean1"
 bean="org.jboss.test.kernel.xml.support.SimpleBeanImpl">
 <interceptors>
 <interceptor bean="org.jboss.test.kernel.xml.support.ConstructorDependencyInterceptor">
 <constructorParams>

 <!-- Here I make the interceptor wait for SimpleBean2 -->
 <parameter type="org.jboss.test.kernel.xml.support.SimpleBean"><dependency value="SimpleBean2"/></parameter>
 </constructorParams>
 </interceptor>
 </interceptors>
 </bean>

 <!-- The bean the interceptor needs -->

 <bean name="SimpleBean2"
 bean="org.jboss.test.kernel.xml.support.SimpleBeanImpl">
 <constructorParams>
 <parameter type="java.lang.String"><value>ConstructorDependencyInterceptor</value></parameter>
 </constructorParams>
 </bean>
 </beans>
</deployment>

[adrian.brock]

The distinction made, as I understand it, is that the "java:/" is not available external to the JVM in which the JNDI schema is created, as opposed to "java:". That is; "java:/myObject" is not the same as "java:myObject". And there are security reasons for which you may not want objects accessible from an external JVM.

The issue with regards to access to the datasource from an external JVM in JBoss is ultimately a physical restriction with connections rather than an arbitrary choice by the JBoss developers. The DataSource is just a connection factory.

The physical connection is manifested between the JVM in which the DataSource is instantiated, and the actual datasource (database). Passing the connection handle (Connection) to an external environment would be of little use. Now the JBoss developers might produce a proxy implementation for connections manufactured from the DataSource but the cost benefits of a connection pool are diminished by the cost of establishing a separate connection between the external JVM and the JVM in which the real datasource connection resides.

Secondly, were JBoss developers to develop a proxy implementation for the connection pool, there is no security restriction inherent in the Connection manufacture from a DataSource such that exposing the DataSource to external access opens the datasource to possible malicious attack from unauthorised parties.

MHO.

[adrian.brock]

The key feature is that you don't need to add dependencies to the bean itself.
You can define the dependencies on the interceptor.

When we have true aspects, you will be able to automagically get dependencies.

e.g. If you add the transaction demarcation aspect it will *know* it needs to wait for the
transaction manager to be deployed.

Just to reiterate. The dependencies are associated with the aspect not the bean
meaning you only define it once.

[adrian.brock]

So the container construction code is a bit hacky.

I'm actually thinking that this config should be more long winded and more
explicit but giving you more control.
i.e. you construct the whole container using the metadata.

In more detail, currently we have the implicit container when you configure an
interceptor:

 <bean name="SimpleBean1"
 bean="org.jboss.test.SimpleBeanImpl">
 <interceptors>
 <interceptor bean="org.jboss.test.AnInterceptor">
 </interceptor>
 </interceptors>
 </bean>

But how much better would it be if you had more control...

<bean name="SimpleBean1"
 bean="org.jboss.proxy.Proxy">
 <attribute name="interfaces">org.jboss.test.SimpleBean</attribute>
 <attribute name="handler">
 <bean bean="org.jboss.container.bean.BeanContainer">
 <attribute name="Interceptors">
 <bean bean="org.jboss.test.AnInterceptor"/>
 <bean bean="org.jboss.test.AnotherInterceptor"/>
 </attribute>
 <attribute name="Target">
 <bean bean="org.jboss.test.SimpleBeanImpl"/>
 </attribute>
 </bean>
 </attribute>
</bean>

This is great for internal work where you could set an attribute on the Target
at deployment time, but not have the attribute exposed to the user
at runtime via the interface.

Of course there would need to a simpler xml exposed to the users
for the most common use cases which would "transform" into this more long winded
but more flexible form for internal use or if the user wants more control.

[bill.burke]

A couple of things. I think there are 3 types of containers:

1. The bean itself, with no proxy in front
2. A container per bean-type. (i.e. EJB)
3. A container per bean.

JBoss AOP is currently a container per bean-type. I don't think it would be much work to have a container per bean.

BTW, I think you are looking at this in the wrong way. Interceptors/Aspects should not be defined as part of the bean, but rather defined outside the bean, and bound in. (like in JBoss AOP). Your examples above are the wrong approach. THe reason being is that you want interceptors defined for different scopes. You may want an interceptor created as a singleton, per bean-type(per class), per instance, per joinpoint, per class per joinpoint, but have one configuration for it.

JBoss AOP aspects/interceptors are created via a pluggable factory. This factory's api is createPerVM, createPerInstance, createPerClass, etc...

Bill

[adrian.brock]

We actually agree, but our definitions are different.

You will note in my example (it is pseudo code) the interceptors are external
to the bean (target).

What I want to get across is that the container (advisor) is also a bean
and should be constructed through dependency injection so it can take advantage
of microcontainer dependency processing.

[adrian.brock]

Let's take your three types of container (again this is pseudo code):

1) No container

<bean name="SimpleBean1" bean="org.jboss.test.SimpleBeanImpl"/>

2) Container per bean type

<bean name="SimpleBeanInterceptors" bean="org.jboss.container.bean.BeanList">
 <bean bean="org.jboss.test.AnInterceptor"/>
 <bean bean="org.jboss.test.AnotherInterceptor"/>
</bean>
<bean name="SimpleBean1"
 bean="org.jboss.proxy.Proxy">
 <attribute name="interfaces">org.jboss.test.SimpleBean</attribute>
 <attribute name="handler">
 <bean bean="org.jboss.container.bean.BeanContainer">
 <attribute name="Interceptors">
 <depends name="SimpleBeanInterceptors"/>
 </attribute>
 <attribute name="Target">
 <bean bean="org.jboss.test.SimpleBeanImpl"/>
 </attribute>
 </bean>
 </attribute>
</bean>

3) Container per bean

<bean name="SimpleBean1"
 bean="org.jboss.proxy.Proxy">
 <attribute name="interfaces">org.jboss.test.SimpleBean</attribute>
 <attribute name="handler">
 <bean bean="org.jboss.container.bean.BeanContainer">
 <attribute name="Interceptors">
 <bean bean="org.jboss.test.AnInterceptor"/>
 <bean bean="org.jboss.test.AnotherInterceptor"/>
 </attribute>
 <attribute name="Target">
 <bean bean="org.jboss.test.SimpleBeanImpl"/>
 </attribute>
 </bean>
 </attribute>
</bean>

[adrian.brock]

What I'm trying to get across is that the containers need to be constructed using
the microcontainer dependency process. There are dependencies like classloading
or jndi binding that a simple factory mechanism cannot hope to understand/implement.

[adrian.brock]

One thing that is on my roadmap to implement is that the

<bean/>

can specify a factory not just a constructor.

This is needed for more complex POJOs that don't follow the javabean pattern
and will also give more control on how objects are constructed.
Of course the same thing can also be achieved with constructor aspects
but this would class wide which might not be what you want.

[bill.burke]

I REALLY don't like the generic syntax, but understand it is needed to be able to snap on any type of handler, etc...

BTW, I think your example for per bean type is wrong. It should be:

<bean name="SimpleBean1"
 bean="org.jboss.proxy.Proxy">
 <attribute name="interfaces">org.jboss.test.SimpleBean</attribute>
 <attribute name="handler">
 <depends name="container:name=somecontainer"/>
 </attribute>
</bean>

[adrian.brock]

BTW, I think your example for per bean type is wrong. It should be:

Yes if we are talking about something like an EJB container that has a pooling
interceptor or a JMX singleton container.

But, for POJO level you will need a different handler instance to identify the instance
to the outside world even though they share interceptors.
You will notice I have Target as an attribute of the handler rather than the proxy.

I believe exposing the full the definition of the container this way enables
more configuration choices for the "user".

[starksm64]

Alexey has added support to the jbossxb layer so that you can specify the factory to use for a given namespace. See the following thread for an example:

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=57871

We need to get the xml processing unified in the pojo server.

[adrian.brock]

Under no circumstances should the micro container require XML.

XML is one option for configuring the server. All the XML parsing should do
is construct kernel metadata objects. It should not be attempting to construct the
real objects as dependencies will not be satisfied at this stage, e.g. classloading
dependencies.

[starksm64]

XML is not required, but where it shows up it should be processed consistently. The most flexible mechanism we have today is the jbossxb framework.

[ivelin.ivanov]

just nit-picking here on the syntax:

<bean name="XYZ" bean="org.something.ClassName">

1. What will be the naming convention for XYZ? Bill seems to be leaning towards JMX. Is each Bean going to show as an MBean if the JMX wrapper around the microcontainer is deployed?

2. Is the attribute bean=".." always going to refer to a class name? If so, why not call it "class"? class="..."