-
1. Re: ENC Deployment
adrian.brock Sep 18, 2006 5:54 AM (in response to adrian.brock)The major work is how in the ENC is constructed.
Obviously there will be an ENC deployer.
This needs to collect all the metadata to populate the ENC structure:
1) From the spec defined xml
2) From override xml
3) From annotations on the class(es)
4) From the metadata itself (e.g. instance overrides)
In my opinion, it is best that the ENC Deployer just does step 4.
Steps 1-3 should be done by the earlier parsers that know
what to look at, e.g. the ejb, web and client deployers
If these populate the MetaData hierarchy (converting xml into
annotations) the ENC deployer just needs to know the ScopeKey
and collect all the annotations. -
2. Re: ENC Deployment
adrian.brock Sep 18, 2006 6:03 AM (in response to adrian.brock)The next step is what the ENC deployer does about the
dependencies.
e.g. If I want a DataSource, the DataSource should be deployed
before I start.
The way this should work is that the object that wants an ENC
should be deployed through the Controller, either as a POJO
or JMX with the relevant dependency:<bean name="MyEJB"> <property name="enc"> <inject bean="MyEJB,ENCFactory" property="enc"/> </property> etc.
The ENC deployer creates the ENCFactory using the metadata
from the scope it was provided with. -
3. Re: ENC Deployment
adrian.brock Sep 18, 2006 6:21 AM (in response to adrian.brock)Which leaves the final piece of the puzzle.
When the ENCFactory is constructed it could have dependencies like:<bean name="ENCFactory.MyEJB"> <property name="beans"> <map> <key>jdbc/DataSource</key> <value><inject bean="SomeDataSource"/></value> etc.
The SomeDataSource will come from the annotations.
But what if it is just a jndi binding?<bean name="ENCFactory.MyEJB"> <property name="bindngs"> <map> <key>jdbc/DataSource</key> <value>java:/MyDataSource</value>
The way to solve this is to remove the jndi binding from the services
themselves, so we can create a "registry" of bindings.
(This also means services don't need to know the jndi population
mechanism as well).
Using a use case configuration:<bean name="SomeDataSource"> <property name="JNDIBinding"> <jndibinding xmlns="urn:jboss:naming:1.0" binding="java:/MyDataSource" bean="SomeDataSoure"/> etc.
The jndibinding creates a bean that has a contract like:public interface JNDIBinding { public void setObject(Object object); }
When setObject is invoked with a value, the binding
is added to jndi when it is null it is removed.
It also gives a bean to depend upon for the "bindings" above.
e.g. the use case config would really be something like:<bean name="java:/MyDataSource" whenRequired="constructed"> <factory><inject bean="JNDIBindingFactory"/></factory> <depends>SomeDataSource</depends> </bean>
i.e. The binding is injected into once it is constructed,
but it doesn't "start" (bind into jndi) until the bean itself is installed.
What it binds is determined by the setObject().
Obviously there are additional complications/configuration options
for when:
1) The object is not serializable/referencable
2) The "bindings" above reference an external jndi and so
cannot form a real dependency
etc. -
4. Re: ENC Deployment
adrian.brock Sep 18, 2006 6:24 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
Using a use case configuration:<bean name="SomeDataSource"> <property name="JNDIBinding"> <jndibinding xmlns="urn:jboss:naming:1.0" binding="java:/MyDataSource" bean="SomeDataSource"/> etc.
We probably need to make this error prone so we can remove
the bean="SomeDataSoure" and allow it depend on the parent.
Something like:<bean name="java:/MyDataSource" whenRequired="constructed"> <factory><inject bean="JNDIBindingFactory"/></factory> <depends><parent/></depends> </bean>
-
5. Re: ENC Deployment
bill.burke Sep 18, 2006 8:23 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
The major work is how in the ENC is constructed.
Obviously there will be an ENC deployer.
This needs to collect all the metadata to populate the ENC structure:
1) From the spec defined xml
2) From override xml
3) From annotations on the class(es)
4) From the metadata itself (e.g. instance overrides)
In my opinion, it is best that the ENC Deployer just does step 4.
Steps 1-3 should be done by the earlier parsers that know
what to look at, e.g. the ejb, web and client deployers
If these populate the MetaData hierarchy (converting xml into
annotations) the ENC deployer just needs to know the ScopeKey
and collect all the annotations.
I think we talked about this before...
These need to be the steps:
1) A registration phase for all deployments
2) Analyzation of XMLs, annotations and metadata to determine dependencies.
This step is partially complex as bindings can be determined by both the classtype of the component and position in the deployment (is the referenced component in the EJB-JAR? No? The EAR? No? Globally?)
3) Register dependencies with controller
4) Start and populate ENC and do any injections.
I do this in the current J2EE injection/XML processing. Within this phase I create two different objects. One object is an ENCInjector object. This object gets registered with Container and executed at component startup. If there are any injections to be done, these are registered with the container using a different object, an Injector. Injectors inject into object instances and are keyed based on classtype.
For EJB Containers there can be multiple class types that have injectors. The BeanClass itself, and any interceptor classes.
For Web Containers, you have servlet classes, filter classes, context listener classes, and I believe, taglib classes. The Web tier has the additional problem of JSP classes which are not available at deployment time or may be changed on the fly.
I have created an abstraction so that the ENC/Injection Handlers are shared between the EJB and Web tiers -
6. Re: ENC Deployment
bill.burke Sep 18, 2006 8:33 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
The next step is what the ENC deployer does about the
dependencies.
e.g. If I want a DataSource, the DataSource should be deployed
before I start.
The way this should work is that the object that wants an ENC
should be deployed through the Controller, either as a POJO
or JMX with the relevant dependency:<bean name="MyEJB"> <property name="enc"> <inject bean="MyEJB,ENCFactory" property="enc"/> </property> etc.
The ENC deployer creates the ENCFactory using the metadata
from the scope it was provided with.
That's nice for basic beans, but as I showed before, it is just not so simple for Java EE land where the ENC -> Global JNDI binding cannot be determine by the available metadata. To put it in other terms, the available metadata may not be enough to construct a Kernel identity or exact JNDI binding. The referenced component will need to be searched for based on the position of the component in the deployment and based on the little of metadata that was made available by the application developer. -
7. Re: ENC Deployment
adrian.brock Sep 18, 2006 8:35 AM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
I have created an abstraction so that the ENC/Injection Handlers are shared between the EJB and Web tiers
So this needs moving into the new deployment layer. -
8. Re: ENC Deployment
adrian.brock Sep 18, 2006 8:44 AM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
That's nice for basic beans, but as I showed before, it is just not so simple for Java EE land where the ENC -> Global JNDI binding cannot be determine by the available metadata. To put it in other terms, the available metadata may not be enough to construct a Kernel identity or exact JNDI binding. The referenced component will need to be searched for based on the position of the component in the deployment and based on the little of metadata that was made available by the application developer.
Whatever mechanism is used needs to be validatable via a "dry run"
through the deployers.
i.e. It should be possible to create a profile (list of deployments)
and then say "does it make sense?", "what is missing/unresolved?", etc.
If that is not possible then the modal is broken.
Implicit rules like "position in the file" are supportable but
inherently prone to error/breakage when the file is changed.
e.g. a conflicting definition is interpolated
or the order is changed by some user/tool/ide that doesn't understand
the importance.
But that's not my problem. :-)
I've always hated such "scripting" as being brittle. -
9. Re: ENC Deployment
starksm64 Sep 18, 2006 11:03 AM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
That's nice for basic beans, but as I showed before, it is just not so simple for Java EE land where the ENC -> Global JNDI binding cannot be determine by the available metadata. To put it in other terms, the available metadata may not be enough to construct a Kernel identity or exact JNDI binding. The referenced component will need to be searched for based on the position of the component in the deployment and based on the little of metadata that was made available by the application developer.
The rules for completing the metadata need to be a pluggable aspect of the deployment layer so that when deployment processing is complete, the enc deployer and runtime aspect have nothing to do but create the context and install the correct one. A merge of the org.jboss.ejb.EjbUtil link resolution and whatever new rules have been added should be the starting point.