[Design the new POJO MicroContainer] - Re: Scoped beans deployment
by adrian＠jboss.org
anonymous wrote : What is meant here by bindings?
Name->Object
e.g. This would map to the implementation (remove for undeploy)
| // Get a link to the scoped metadata
| KernelMetaDataRepository kmdr = kernel.getMetaDataRepository();
| MutableMetaDataRepository mmdr = kmdr.getMutableMetaDataRepository();
| ScopeKey scope = from the <scope/>;
| MutableMetaData mmd = (MutableMetaData) mmdr.getMetaDataRetrieval(scope);
|
| // Not found create it
| if (mmd != null)
| {
| mmd = ...;
| mmdr.addMetaDataRetrieval(mmd);
| }
|
| for (iterate)
| mmd.addMetaData(name, object, object.getClass());
|
If the scope wants to define its own kernel then you would also have something like:
| // Get our scope
| KernelMetaDataRepository kmdr = kernel.getMetaDataRepository();
| MutableMetaDataRepository mmdr = kmdr.getMutableMetaDataRepository();
| ScopeKey scope = from the <scope/>;
| MutalbeMetaData mmd = (MutableMetaData) mmdr.getMetaDataRetrieval(scope);
|
| // Get the parent scope
| ScopeKey parent = scope.getParent();
| MutalbeMetaData pmmd = (MutableMetaData) mmdr.getMetaDataRetrieval(parent);
| MetaDataItem<Kernel> item = pmmd.retrieveMetaData(Kernel.class);
| Kernel kernel = null;
| if (item != null)
| kernel = item.getValue();
| else
| kernel = // use default - or more probably this current kernel?
|
| // Create a scoped kernel
| Kernel scopedKernel = new ScopedKernel(kernel);
| mmd.addMetaData(scopedKernel);
|
There is also work to do on how ScopeKeys get constructed
This is very environment specific.
See my comments on the metadata integration thread in the last couple of months.
Also note that there are two notions of scope (configuration time and runtime).
This is important in the code above where the parent kernel needs to come
from the parent runtime scope, but it is added to local configuration time scope.
Again, this difference is explained in the metadata integration thread.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009454#4009454
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009454
17 years, 3 months
[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by adrian＠jboss.org
"weston.price(a)jboss.com" wrote :
|
| | <recovery-security-domain>Recovery</recovery-security-domain>
| |
|
| is defined in login-config, so we have yet another piece of external information to 'kludge' this together it just happens to be in a 'comfortable' place that you are familiar with.
|
No, it is the standard mechanism within the appserver for external security
configuration.
Personally, I think JCA should have a SubjectFactory integration point
which for the appserver uses JBoss-JAAS, but whatever you still need
to name the factory to use and the security-domain config is as good an
identifier as any.
e.g. In a standalone use case it could be a name for the SubjectFactory
in the microcontainer.
| <property name="subjectFactory"><inject bean="Recovery"/></property>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009443#4009443
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009443
17 years, 3 months
[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by adrian＠jboss.org
"weston.price(a)jboss.com" wrote :
| Ok, let's take a simple scenario:
|
| JDBC based deployment using a security domain with a login config of CallerIdentityLoginModule. Just because the TxManager is deployed, doesn't mean the XAResource gets created. This comes off the underlying Connection which is only created when the pool is first used. So, what goes in the repository in this case? What do I iterate over during recovery?
|
| How about a JDBC deployment that only support application-managed security? What if this is required information and can only be done via
| getConnection(username,password)?
|
|
The cases we are talking about is where the security is already externally
configured. There is no default user name or password or it is the wrong one.
It is either application-managed-security or security domain based.
In the case where there is no default and one is required, you need to
configure it somewhere.
In the case where it is the wrong one (the normal runtime user doesn't have
authority to invoke recover()) you also need a seperate configuration.
These are the 1% use cases for completeness.
In 99% of uses cases the default user (either no user/password
or the one form the security domain) will suffice for recovery to create the connection.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009434#4009434
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009434
17 years, 3 months