June 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Too much implicity

by bill.burke＠jboss.com

"adrian(a)jboss.org" wrote : 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); | | } | | | IMO, there's just too much implicity in both the old and new deployment architecture. My experience writing the first deployer in this new architecture was that I had to dive through a lot of internal code to figure out what the hell was going on. It seems like this is getting worse with the new refactoring you did. I honestly don't care about saving one line of if attachment exists code. It actually makes the code more readable and more importantly, more understandable for people using your deployer as an example for writing their own. 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=4058932#4058932 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058932

16 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: dataflow integration

by msandoz

I've put together some classes, plugin.xml and exsd changes. im working on the jira ticket now... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058931#4058931 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058931

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New Deployer changes - overview

by bill.burke＠jboss.com

How do you define precedence rules for deployer ordering? For example, let's take a hypothetical Seam deployer that needs to augment an EJB deployment based on additional metadata within the deployment unit. It needs to happen after EJB XML and Annotation processing, but before component processing. I liked the install/uninstall approach (see below if you dont' know what I'm talking about) because we could have added precedence metadata to the addDeployer method. Precendence metadata like, I have to come before the EJB component processing, but after the XML/annotation processing. | <install bean="MainDeployer" method="addDeployer"> | <parameter><this/></parameter> | </install> | <uninstall bean="MainDeployer" method="removeDeployer"> | <parameter><this/></parameter> | </uninstall> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058924#4058924 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058924

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MainDeployer changes

by bill.burke＠jboss.com

| <bean name="StructuralDeployers" class="org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl"> |  | <incallback method="addDeployer"/> | <uncallback method="removeDeployer"/> | </bean> | So the incallback means that any bean that implements the interfaces of VFSStructuralDeployersImpl will automatically incur an addDeployer(this) call on the StructuralDeployer's bean? Or the parameter type of the addDeployer method? incallback is a HORRIBLE name for this. Please define something that is easier to understand. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058921#4058921 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058921

16 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml

by bill.burke＠jboss.com

IIRC, can't you just programmatically define your own order? Also, an annotation parsing deployer does not necessarily need to happen after classloader deployment so long as you have access to the .class file resources. (Javaassist). Also I don't see why it matters what order you process meta-data. Why does annotation processing have to happen first? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058916#4058916 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058916

16 years, 10 months

1
0
0 / 0

[JBoss Portal Documentation] - Re: Quickstart Guide 2.6 update

by cdelashmutt

Yes please. Can you give me commit access? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058869#4058869 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058869

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New Deployer changes - overview

by adrian＠jboss.org

The other thing I need to do is go through the TODOs that i found (not necessarily really changes that I made - a lot already existed) and make sure they have JIRA issues. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058866#4058866 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058866

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New VFSDeployer Change Question

by adrian＠jboss.org

A deployer for seam should just be a case of something that modifies the WebMetaData to add the seam servlet context listener (or whatever mechanism it uses). | public MySeamDeployer extends AbstractSimpleVFSRealDeployer<WebMetaData> | | public MySeamDeployer() | { | super(WebMetaData.class); | // We modify the web metadata - i.e. we are filter that inputs/outputs WebMetaData | setOutputs(WebMetaData.class); | } | | public void deploy(VFSDeploymentUnit unit, WebMetaData webMetaData) throws DeploymentException | { | if (isSeamDeployment(unit)) | modifyWebMetaDataToAddSeamIfNotAlreadyPresent(webMetaData); | } | WebMetaData is the object model for [jboss-]web.xml Once that is done, you can just deploy a normal war with seam metadata (or annotated classes) and it will automatically make the necessary configuration changes to web.xml View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058864#4058864 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058864

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New Deployer changes - overview

by adrian＠jboss.org

Finally, besides what I said above about things needing completing, the new classloader still needs to be integrated. I have some code for this, but I'm not really happy with the metadata model yet. Besides that it needs some other fixes where the RepositoryClassLoader is assumed. I decided not to commit this work yet. The other major work is in tidying up the testsuite. There are a number of failures due attachments (e.g. the ear metadata) not being serializable and also the VFS urls not being usable on the client side. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058862#4058862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058862

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Parsing Deployers

by adrian＠jboss.org

The parsing deployers are now almost entirely declaritive. In many cases, you could consider that we don't need seperate classes and the whole thing could be done with xml. You no longer need to do | public void deploy(...) | { | createMetaData(unit, null, "-ds.xml"); | } | Instead you can do | public MyParsingDeployer | { | setSuffix("-ds.xml"); | } | The only reason for a class is if you need to do "after" processing. Many deployers had overridden "random" parts of the api without spotting that this callback already existed in init() and it already does the "null" checking. | public class BeanDeployer extends SchemaResolverDeployer<KernelDeployment> | { | /** | * Create a new BeanDeployer. | */ | public BeanDeployer() | { | super(KernelDeployment.class); | setSuffix("-beans.xml"); | } | | @Override | protected void init(VFSDeploymentUnit unit, KernelDeployment metaData, VirtualFile file) throws Exception | { | String name = file.toURI().toString(); | metaData.setName(name); | } | Some other deployers were also doing other checks besides the metadata file existed. IMHO most of these are HACKs that should be fixed. But to make this easier, I added the accepts() callback to the parsing deployers so each deployer doesn't have to put this wiring in themselves. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058861#4058861 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058861

16 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2007