October 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Update on metadata progress

by wmprice

Once I figure out what the hell you are talking about, I can pick up the RAR work or take anything off your plate you want to give me (note, this doesn't mean 4-5 words of broken English, the Queen's or otherwise). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978156#3978156 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978156

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Update on metadata progress

by adrian＠jboss.org

This is going a lot slower than I expected, I've not got very far into the problem despite working on it all week (including a couple of all nighters :-) It is very laborious work. At least, I've got a parser that can parse javaee_5.xsd, ejb-jar_2_1.xsd and ejb-jar_3.0.xsd and I can prove it works for all element (well except the webservices stuff. ;-) I'm basically in stage 2 of the following roadmap with (1) still incomplete for the jboss.xml stuff. 1) Create a new set of more rational metadata classes that can be shared by javaee based deployers. 2) Map the old the metadata classes as a facade over these classes. 3) Rework the EJB2.1 deployer to use new metadata and expose the old metadata via the container for backwards compatibility (meaning the only part of the container I need to rewrite is the getBeanMetaData() hooks). 4) Rework the metadata classes to share the same model as the javaee/ejb3 annotations allowing the org.jboss.metadata hierarchy to provide the mixing/overriding of class annotations and deployment/instance metadata (the model from 1) This will give hardwired deployment, class, instance contexts. 5) Deal with the metadata collection merging for things like resource-refs. 6) Plugin Bill's injector stuff, as discussed elsewhere. (Actually the current stuff is wrong, since it only copes with one injection target per Ref) 7) Properly plugin in the metadata repository such that the metadata hierarchy is extensible and configurable. 8) Write the code to expose the metadata context(s) via the ManagedObject abstraction to the profile service. Both the combined runtime view and the individual contexts. It was originally (8) that got me started on this, but trying to write a mapping for all the JavaEE metadata when * each deployer does it differently * the details needed are embedded in an arbitrary metadata object * there are even different models for EJB2 and EJB3 But, with this approach, it will just be a case of creating the ManagedObject from the annotations/metadata of the metadata context, a much simpler task. Obviously, it is not quite that simple, but at least it will be a tractable problem. :-) There's also further steps: 9) Do this for the other JavaEE deployers (rar, war, car, ejb3, etc.) 10) Work out how to expose the managed object model for JMX and MC Issues still to work out: * What Bill is talking about when he says annotation fail as a metadata model * Which parts of the model should be promoted to annotations * The merging/hiding issue * A simple mechansim to populate deployment vs instance metadata e.g. assembly-descriptor stuff can be generic to the deployment or ejb specific View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978153#3978153 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978153

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: AbstractDeploymentUnit.getMetaDataFiles()

by adrian＠jboss.org

There is a FIXME in the VFS to revisit the jar url stuff. For the top level url of the jar, it would make sense to just use the real url, not the jar: url. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978148#3978148 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978148

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status of web console enhancements

by tom.baeyens＠jboss.com

now i just messed up again :-( one last try: i had some kids pulling my sleeve while typing the previous message. just to stress the brainstorm nature and non-decicive character of the previous message, this is what i intended: my current idea with BAM vs BI is the following: ... does that make sense to you ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978147#3978147 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978147

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status of web console enhancements

by tom.baeyens＠jboss.com

i had some kids pulling my sleeve while typing the previous message. just to stress the brainstorm nature and non-decicive character of the previous message, this is what i intended: my current idea with BAM vs BI is the following: does that make sense to you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978145#3978145 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978145

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Ordering of nested deployments

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : The war deployers contained in a jbossweb-tomcat6.deployer package also contains a ROOT.war. The structural pase phase identifies the jbossweb-tomcat6.deployer and jbossweb-tomcat6.deployer/ROOT.war as deployment contexts, but the deployer list is fixed going into the deploy loop. | This is case where deployer and container are incorrectly mixed together. ROOT.war is a runtime component that shouldn't be part of the deployer deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978143#3978143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978143

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Aspectized JACC deployment layer

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : | It feels almost a little hacky, why? The JaccInitializationDeployer takes a set a set of attachment names. If the deploymentContext contains that transient attachment, then it will add PolicyConfiguration. The idea being that you can trigger JACC based on whether or not a given DU is a certain type of deployment (is it an EAR WAR or EJB JAR?) Why is that hacky? That is whole point of aspectized deployers. You can create the deployment aspect for all deployment types (based on whether the metadata exists). Whether it actually makes sense in all cases is a different issue, :-) See my critique of "orthogonality" in the overview post at the top of the forum. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978142#3978142 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978142

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Aspectized JACC deployment layer

by adrian＠jboss.org

Why would a real deployer create anything like this? Surely it should be creating the metadata for an MBean or POJO that can take part in dependencies? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978141#3978141 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978141

19 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: SIgnaficane of the ControllerMode ....

by adrian＠jboss.org

I've started some docbook for the container project a while ago, but I haven't got very far (not enough cycles). The main reason it doesn't already exist is because this api has been very fluid. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978140#3978140 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978140

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: To merge or not to merge?

by adrian＠jboss.org

But I think we are talking about different things, at least from my understanding of your original post. There is a need to merge/hide/override at runtime and this depends upon the type of metadata (it also includes having the ability to query where the data came from). The full normalized view should be maintained elsewhere. When I talk about merging I'm talking about giving the runtime view, e.g. getting all the resource-refs for a bean (from all levels). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978139#3978139 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978139

19 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2006