[Design the new POJO MicroContainer] - Re: Scoped Kernels
by adrian＠jboss.org
"alesj" wrote : I'm quite done with scoping, but I have encountered a few problems:
|
| 1) When a bean that represents the classloader for other beans is deployed in some scope, other dependent beans (from same scope) are unable to find him - since they are not described yet == no scope knowlegde.
|
You can't use a classloader in a scope if the scope requires
that classloader to exist before it is constructed.
It's like trying to have a deployment depend upon a classloader
in that deployment. In that case, you fix it by doing:
| <classloader><null/></classloader>
|
So it doesn't depend upon itself.
anonymous wrote :
| 2) If I deploy bean with the same name and the same class in 2 different scopes, KernelControllerContext scope lacks some differentiation between different context instances - fullScope with INSTANCE and CLASS is the same for both context instances. I currently added context's hash under WORK level, to be able to test this.
|
I don't understand this. 2 contexts in different scopes should not have
the same ScopeKey.
anonymous wrote :
| 3) While testing, how to get the actual bean / context from bootstrapping kernel / controller, since the real bean / context is present in some scoped child controller.
There are a number of apis that need updating to understand Scope.
i.e. passing in the ScopeKey as an additional parameter.
The old api should invoke the new api with the default scope.
Retrieving the context is one of them.
There are other apis that need to be able to retrieve all contexts in all scopes
and include the scope in the identity.
The checking of incomplete contexts in the kernel deployer
or the repository service is one of the latter.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021174#4021174
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021174
19 years, 1 month
[Design the new POJO MicroContainer] - Need cleanup of the attachments api
by scott.stark＠jboss.org
As I have more metadata being stored off, its clear that the DeploymentUnit api is not sufficient/confusing. There are non-managed, non-serializable attachments showing up in the only used attachments contents. The current attachments api breakdown is:
DeploymentUnit
.addAttachment
.getTransientManagedObjects().addAttachment
.getAttachment
.getTransientManagedObjects().getAttachment
DeploymentContext
.getPredeterminedManagedObjects().addAttachment/getAttachment
.getTransientManagedObjects().addAttachment/getAttachment
.getTransientAttachments().addAttachment/getAttachment
Right now when one does a DeploymentUnit.addAttachment this is going into the DeploymentContext.getTransientAttachments() contents. When one does a DeploymentUnit.getAttachment the DeploymentContext attachments are checked for a match in the order: getPredeterminedManagedObjects(), getTransientManagedObjects(), and getTransientAttachments().
The notion of the various attachments as I understand it and discussed elsewhere is:
getPredeterminedManagedObjects() - attachment overrides for use by things like the profileservice.
getTransientManagedObjects() - attachment overrides for use by things like the runtime aspects.
getTransientAttachments() - the general runtime attachments bucket for use by deployers, aspects.
The TransientManagedObjects is currently unused, and everything is going into TransientAttachments. This is not a sufficient separation of what is managed metadata that should be persisted vs metadata that is used for inter deployer/aspect communication.
I suggest the following change to cleanup the usage and allow for true transient/non-managed attachments:
1. Remove the Attachments interface from DeploymentUnit.
2. Mirror the Attachments api in DeploymentUnit with an enum that indicates what bucket is being accessed. The non-enum version of getAttachment follows the existing order of accessing the PredeterminedManagedObjects, TransientManagedObjects and TransientAttachments. The non-enum version of addAttachment would populate the TransientManagedObjects contents.
3. To populate a non-managed attachment, one would have to use the call that takes the enum targetting the TransientAttachments list.
4. Drop the getTransientManagedObjects access from DeploymentUnit.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021169#4021169
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021169
19 years, 1 month
[Design of JCA on JBoss] - Re: JCA antipattern? Or not?
by bill.burke＠jboss.com
"adrian(a)jboss.org" wrote : "bill.burke(a)jboss.com" wrote : JCA may not know anything about MDBs, but isn't MDB the only *standard* way of using inflow? I thought there was no standard way of registering an activation spec and MEF, etc....
|
| There is nothing to stop somebody writing their own MEF (POJO based)
| and activating their own endpoint if they can get a link to the ResourceAdapter.
|
| 1) There is an example of this in the new jca prototype
| where the MEF is actually implemented via AOP interceptors.
|
| 2) This is one of the purposes of the RAR (MetaData) Repository
|
| My preference is to have an abstract MEF implemented by JCA
| that EJB2, EJB3, POJO can extend to provide the three pieces of metadata
| that change.
|
| isMethodTransactional(Method);
| getClassLoader();
| The hypothetical and non-spec getTransactionTimeout(Method);
Yes, this possible in *our* JCA implementation, but the only portable way of leveraging inflow is through MDB. Which was my point.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021152#4021152
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021152
19 years, 1 month
[Design of JCA on JBoss] - Re: JCA antipattern? Or not?
by adrian＠jboss.org
"bill.burke(a)jboss.com" wrote : JCA may not know anything about MDBs, but isn't MDB the only *standard* way of using inflow? I thought there was no standard way of registering an activation spec and MEF, etc....
There is nothing to stop somebody writing their own MEF (POJO based)
and activating their own endpoint if they can get a link to the ResourceAdapter.
1) There is an example of this in the new jca prototype
where the MEF is actually implemented via AOP interceptors.
2) This is one of the purposes of the RAR (MetaData) Repository
My preference is to have an abstract MEF implemented by JCA
that EJB2, EJB3, POJO can extend to provide the three pieces of metadata
that change.
isMethodTransactional(Method);
getClassLoader();
The hypothetical and non-spec getTransactionTimeout(Method);
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021149#4021149
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021149
19 years, 1 month
[Design of JBoss Web Services] - Re: WSContractConsumer API in a seam app
by maeste
Hi Jason,
your hints helped me a lot in finding and solving problem in dynamic class generation.
Now it seems ok and all the apps seems to work not bad (well we still have some point open, but it basically works).
One of the opened points is about class loading when we use jaxws generated class to call webservices.
Generated class is always loaded correctly and also library (putted in ear and loaded as java module in application.xml using an isolated classloader in jboss-app) works perfectly after a fresh startup of the server.
The problem is on finding class in library's jars after an hot deployment. It doesn't work and we get a ClassNotFoundException (not always the same calss) when we invoke the endpoint operation.
Our class loading related code is:
| classLoader = new URLClassLoader(new URL[]{outputDir.toURL()}, Thread.currentThread().getContextClassLoader());
| URLClassLoader classLoader = new URLClassLoader(new URL[]{outputDir.toURL()}, Thread.currentThread().getContextClassLoader());
| Thread.currentThread().setContextClassLoader(classLoader);
|
| serviceClass = JavaUtils.loadJavaType("it.javalinux.ws." + className , classLoader);
| service = serviceClass.newInstance();
|
The use of loaded class and other classes generated by wsConctractConsumer is in other methods of our utility class created and used by a Seam' Stateful bean.
We tried also to be more rude:
| Properties prop = new Properties();
| // BEGIN
| SecurityAssociation.setPrincipal(new SimplePrincipal("admin"));
| SecurityAssociation.setCredential("admin".toCharArray());
| // END
| prop.put( "java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory" );
| prop.put( "java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces" );
| prop.put( "java.naming.provider.url", "jnp://localhost:1099");
| InitialContext ctx = new InitialContext(prop);
| RMIAdaptor rmiserver = (RMIAdaptor) ctx.lookup("jmx/invoker/RMIAdaptor");
| ObjectName onameBean = new ObjectName("seam.jboss.org:loader=Wise");
| rmiserver.invoke(onameBean, "newClassLoader" , new Object[]{outputDir.toURL(),true}, new String[]{"java.net.URL","boolean"});
|
|
But we get the same error.
Any other useful hint?
Thanks in advance
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021145#4021145
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021145
19 years, 1 month