[Design the new POJO MicroContainer] - Components
by adrian＠jboss.org
Components have been changed in two fundamental ways.
1) Deployers don't see components by default any more.
To get components, you need to do
| public MyDeployer()
| {
| setWantComponents(true);
| }
|
2) However if you are dealing with components, you probably don't want
to process the main context. So you are more likely to use
| public MyDeployer()
| {
| setComponentsOnly(true);
| }
|
The two current component deployers (JMX and POJO) both
only look at components now.
NOTE: On a related point you can also say that you are only interested in
the top level deployment, not subdeployments.
The other major change, (maybe you spotted it when I listed the DeployerStages or
the list of deployers for REAL), is that there is no longer a COMPONENT stage.
With the attachment flows, it is no longer necessary. The attachment ordering
will make sure it is invoked in the correct order.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058851#4058851
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058851
16 years, 11 months
[Design the new POJO MicroContainer] - Attachment Flow
by adrian＠jboss.org
The next form of dependency is something I described when I first wrote the
deployers.
i.e. it should be able to work out what order to process the deployers
from what information you input/output.
Most of this can be done automatically, e.g.
| public class MyDeployer extends AbstractSimpleRealDeployer<MyMetaData.class>
| {
| public MyDeployer()
| {
| super(MyMetaData.class);
| }
| }
|
Will automatically know that you want MyMetaData attachments.
As an aside, with those classes, it will also know that you don't want to be
invoked for deploy/undeploy if there is no such attachment.
i.e. no longer any need for the boiler place
| if (unit.getAttachment(MyMetaData.class) == null)
| return;
|
If you don't want this filtering, you can turn it off with
| public MyDeployer()
| {
| super(MyMetaData.class);
| setAllInputs(true);
| }
|
But back the attachment flow. You can also be explicit about
what other information you want. i.e. what deployers should be before/after you.
e.g.
| public MyDeployer()
| {
| super(MyMetaData.class);
| setInputs(SomeOtherMetaData1.class, SomeOtherMetaData2.class);
| setOutputs(MyOutput.class);
| }
|
You can see this in the DEBUG where it shows the calcualted ordering
and input/outputs, e.g.
| 2007-06-28 14:34:27,112 DEBUG [org.jboss.deployers.plugins.deployers.DeployersImpl] Added deployer org.jboss.deployment.ClientDeployer@39471b for stage Real
| org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer(a)121df2a{inputs=[org.jboss.beans.metadata.spi.BeanMetaData, org.jboss.kernel.spi.deployment.KernelDeplo
| yment] outputs=[org.jboss.beans.metadata.spi.BeanMetaData]}
| org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer(a)1e46a68{inputs=[org.jboss.beans.metadata.spi.BeanMetaData] outputs=[]}
| org.jboss.deployment.ClientDeployer@39471b{inputs=[] outputs=[org.jboss.metadata.ClientMetaData]}
| org.jboss.deployment.security.SecurityDeployer@18b4ccb{inputs=[] outputs=[jboss.jacc]}
| org.jboss.ejb.deployers.EjbDeployer(a)5e5c15{inputs=[org.jboss.metadata.ApplicationMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]}
| org.jboss.ejb3.deployers.AppClientScanningDeployer(a)1743ff4{inputs=[org.jboss.ejb3.metamodel.ApplicationClientDD] outputs=[org.jboss.ejb3.metamodel.ApplicationClientDD]
| }
| org.jboss.ejb3.deployers.EJBRegistrationDeployer@d1afd3{inputs=[] outputs=[org.jboss.ejb3.Ejb3Deployment]}
| org.jboss.ejb3.deployers.EJBStage2Deployer(a)1ee2ea8{inputs=[org.jboss.ejb3.Ejb3Deployment] outputs=[]}
| org.jboss.ejb3.deployers.Ejb3ClientDeployer(a)182b9b5{inputs=[org.jboss.ejb3.metamodel.ApplicationClientDD] outputs=[org.jboss.ejb3.clientmodule.ClientENCInjectionContai
| ner]}
| org.jboss.resource.deployers.RARDeployer(a)f04dae{inputs=[org.jboss.resource.metadata.ConnectorMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]}
| org.jboss.web.tomcat.service.deployers.TomcatDeployer(a)133926{inputs=[org.jboss.metadata.WebMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]}
| org.jboss.system.deployers.ServiceDeploymentDeployer(a)1b7c76{inputs=[org.jboss.system.metadata.ServiceMetaData, org.jboss.system.metadata.ServiceDeployment] outputs=[or
| g.jboss.system.metadata.ServiceMetaData]}
| org.jboss.system.deployers.ServiceDeployer(a)147e668{inputs=[org.jboss.system.metadata.ServiceMetaData] outputs=[]}
|
You'll notice the Service deployer is after many of the other deployers that create
ServiceMetaData (even though it was one of the first deployers deployed).
NOTE: The old relativeOrder still exists, but it is probably not as a good a way
to determine ordering.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058844#4058844
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058844
16 years, 11 months
[Design the new POJO MicroContainer] - Deployer Dependencies
by adrian＠jboss.org
The deployments can now have dependencies.
These are handled by the Microcontainer which calls back into the
MainDeployer/DeployersImpl when dependencies are satisfied.
The dependencies are based on stages like the old relative order:
PARSE - parsing deployers
DESCRIBE (new) - work out dependencies from metadata
CLASSLOADER - classloading construction
POST_CLASSLOADER - aop
REAL - others
While this works, there is still work to do to complete this.
1) It needs an api such that deployers can add dependencies (on the fly).
2) The actual mechanism in the DESCRIBE stage to visit metadata
and discover deployment dependencies does not yet exist.
The first prototype of this will be with the osgi bundle dependencies,
but this needs to be a more generic mechanism.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058837#4058837
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058837
16 years, 11 months
[Design the new POJO MicroContainer] - DeploymentContext
by adrian＠jboss.org
I've nearly got the DeploymentContext to be invisible.
It is still used in some places, e.g. the testsuite so I've got deprecated methods
that give access to it from the MainDeployer.
Another example is the "hack" in the bootstrap that takes the
classloader of the first deployed, the one for "server/xxx/conf/"
as the classloader to run the bootstrap with.
It is also still used by the ClassLoaderFactory api.
It should just be a matter time to work through where it is still used
and this class can finally be made into an implementation detail
that just consolidates deployment information in one place whereas
others provides facades over the portions relevant for what they are doing.
You can find methods on the [VFS]DeploymentUnit now that should give you
everything you need.
* DeploymentResource[Class]Loader
One part of this change was the re-introduction of what used to be
DeploymentInfo.localCL that was used to load resources during deployment.
This now has an equaivalent from VFSDeploymentUnit.getDeploymentResourceClassLoader().
You cannot use this for classloading but you can use it to load resources.
If you don't need the ClassLoader api (which is quite heavy and has
well known issues in the Sun JDK - e.g. locking/caching)
then just use VFSDeploymentUnit.getDeploymentResourceLoader()
api.
The classloader is actually implemented on top of this.
For simple use cases there is a convience method:
VirtualFile file = VFSDeploymentUnit.getFile(path);
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058834#4058834
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058834
16 years, 11 months
[Design the new POJO MicroContainer] - MainDeployer changes
by adrian＠jboss.org
As described above, the MainDeployer is an extension to the DeployerClient
and also implements MainDeployerStructure (deployment navigation).
Here I'll describe two other significant changes.
1) The configuration now uses the new install callbacks in the microcontainer.
That is there is no need to do:
| <install bean="MainDeployer" method="addDeployer">
| <parameter><this/></parameter>
| </install>
| <uninstall bean="MainDeployer" method="removeDeployer">
| <parameter><this/></parameter>
| </uninstall>
|
on every deployer.
Instead the MainDeployer (really the StructuralDeployers and DeployersImpl
say that they want to be called for all classes that implement the types
on their add/remove methods.
| <bean name="StructuralDeployers" class="org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl">
| <!-- Accept any implementor of structure deployer -->
| <incallback method="addDeployer"/>
| <uncallback method="removeDeployer"/>
| </bean>
|
2) DeployersImpl
Like what was done for the StructureDeployers, the real deployers
are now handled by a delegate class "Deployers", meaing the MainDeployer
actually just acts as a "Fat Interface" and delegates all its real work.
The new implementation DeployersImpl is also where the new deployment
dependencies (via the MicroContainer) and attachment flow are handled.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058831#4058831
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058831
16 years, 11 months
[Design the new POJO MicroContainer] - StructureDeployers
by adrian＠jboss.org
These haven't changed all that much (at least in princple). The changes are:
1) Factory for DeploymentContext
The StructuralDeployers implementation is now a factory for the DeploymentContext
so it can choose the implementation
2) StructureMetaData
The StructureMetaData can now handle StructureMetaData in subcontexts
so you can specify the structure at subdeployment level.
Previously this was only available at the top level deployment level
3) Root file and ClassPath
I tried to modify the StructureMetaData such that the paths are relative
to the current context (rather than the root).
But, I haven't suceeded for the ClassPath part.
The issue is that manifest references are actually equivalent to
| addClassPath("../some.jar");
|
and so are not really a part of the context.
To make this work consistently, all classpath references are relative
to the root of the top level file.
Part of this change required passing the root/top-level file and parent file
in the StructureDeployer api.
IF the VFS was changed such
| virtualFile.findChild("../some.jar");
|
worked, then we can remove this "cognitive dissonance".
All classpath references could be relative to the current context
with manifest references translated to add ../ in front them.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058828#4058828
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058828
16 years, 11 months
[Design the new POJO MicroContainer] - Client spi
by adrian＠jboss.org
The client api is new.
The aim is to remove the direct use of the DeploymentContext and MainDeployer
from the client side (including the clients running in the same JVM like the
profile service or embedded).
Its made up of two main components:
DeployerClient
This is intended as a client side front end to the main deployer.
The main deployer interface itself extends it to add functions that are
purely server side (currently this is only shutdown())
and are not relevant for client side usage.
NOTE 1) The incomplete deployment exception processing is now a method
on this api so we don't need to keep re-implementing in different callers
or figure out how to get a handle on the microcontainer
NOTE 2) There are methods to deploy a single deployment (think JSR88)
rather than the add, add, add, process() model of the url scanner.
However, this implementation of these is still pretty naive and needs completing,
particularly the incomplete checking for a single deployment.
Deployment
The deployment is a client side model of the deployment context.
It is NOT directly linked to the deployment context.
It is made up of two main components:
* predetermined attachments
* structure metadata
There are also deployment factories that help in making this task
simpler.
A typical usage would be something like:
| DeployerClient deployer = ...;
| VirtualFile vf = ...;
|
| // Create the deployment
| VFSDeploymentFactory factory = VFSDeploymentFactory.getInstance();
| VFSDeployment deployment = factory.createVFSDeployment(vf);
|
| // Add some metadata
| deployment.getPredeterminedManagedObjects().addAttachment(someMetaData);
|
| // Create a subcontext/sub deployment
| ContextInfo subcontext = factory.addContext(deployment, "sub.jar", "META-INF");
| // Add metadata to the subcontext
| subcontext.getPredeterminedManagedObjects().addAttachment(otherMetaData);
|
| // Deploy it
| deployer.addDeployment(deployment);
| deployer.process();
| deployer.checkIncomplete();
|
The main things missing from the Deployment over the DeploymentContext are:
1) The DeploymentState. To get this you can DeployerClient.getDeploymentState(name);
2) The deployment types. I don't have a replacement for this yet, see below on profile service changes
3) Deployment structure, i.e. the subdeployments and components
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058819#4058819
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058819
16 years, 11 months
[Design the new POJO MicroContainer] - New VFSDeployer Change Question
by bytor99999
In reading about the VFSDeployer change, I was wondering how this might affect what is needed to say create a Deployer for Seam
Seam has a class that deploys Seam applications based on a File class (see code below) and not using VFS. Will your change mean that it will be easier to wrap Seam's class into a simpler Depoyer class rather than having to create a new seperate deployment classes for Seam in MC.
Sorry for being so green on this stuff. :)
| try
| {
| log.info("scanning: " + urlPath);
| File file = new File(urlPath);
| if ( file.isDirectory() )
| {
| handleDirectory(file, null);
| }
| else
| {
| handleArchive(file);
| }
| }
| catch (IOException ioe)
| {
| log.warn("could not read entries", ioe);
| }
|
Thanks, if I made no sense, let me know and we can delete this thread and forget I said anything. :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058808#4058808
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058808
16 years, 11 months