[Design of POJO Server] - Re: ENC Deployment
by adrian＠jboss.org
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972244#3972244
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972244
19 years, 6 months
[Design of POJO Server] - Re: MetaData - replacement for MetaDataRepository
by adrian＠jboss.org
The basic idea of the MetaData implementation is to provide
overrides and additions to the annotations and objects
for a given scope.
There are two identities that are related. The identity
is defined by the scope and how you use it.
The first identity is the context you are working with
and is most likely a mutable metadata, the exception being
when the metadata source is immutable like a class file
(except via aop which is irrelevant for this discussion).
Examples contexts would be a deployment, a server, a cluster,
a subsystem (jca, ejb), a component (an ejb container), a class
or an object instance.
Other examples which I'll come to later are threads and transactions.
For each of these there is a MutableMetaData that lets you
modify just that context. This will update all the full metadata
hierarchies that it is a part of see below.
Example:
| ScopeKey key = new ScopeKey(CommonLevels.DEPLOYMENT_NAME, "mywar.war");
| MutableMetaData mutable = // create it
| mutable.addAnnotation(someAnnotation);
| mutable.addMetaData("someName", someObject);
| repository.addMetaData(key, mutable);
|
The second form is the hierarchical metadata.
This is made up of the mutables but with a read only view (MetaData).
This is what will actually be used at runtime.
You select the hierarchy using a ScopeKey.
Example:
| Scope[] scopes = new Scope[]
| {
| new Scope(CommonLevels.INSTANCE_NAME, "MyServlet");
| new Scope(CommonLevels.CLASS_NAME, servletClass.getClass().getName());
| new Scope(CommonLevels.DEPLOYMENT_NAME, "mywar.war");
| new Scope(CommonLevels.APPLICATION_NAME, "myapp.ear");
| // etc.
| }
| ScopeKey key = new ScopeKey(scopes);
| MetaData metaData = repository.getMetaData(key);
|
Finally, in the later example you will get two extra scopes
(well actually it should depend upon repository configuration).
The first is a thread local metadata object, the second
a transaction metadata object. Both are mutable using
a private api.
You can aop adding a "request scope" as well, but that
it is going to take a while to persuade to Bill and Kabir to do. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972233#3972233
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972233
19 years, 6 months