"adrian(a)jboss.org" wrote : This is wrong.
|
| e.g. What if I want to deploy an EAR programatically where I tell it upfront
| what the structure and metadata is.
|
| i.e. it doesn't go through either the structure or the parsing deployer,
| it uses the structure and metadata I've told it to use when I did the programmtic
| deployment.
|
Then the deployer processing has to support complete vs incomplete inputs. I can have a
complete programmatic specification, or multiple partial sources as is the case where
javaee naming conventions along with a jboss-app.xml is used to define the contents of an
ear. I don't see how allowing the structural parse to introduce deployment metadata
has any affect on a programmatic deployment.
"adrian(a)jboss.org" wrote :
| I'm I supposed to know to add the transient managed object that represents
| the context root to the war context I create manually, or should I expect it to
| pick it from the J2eeApplicationMetaData where I defined it?
|
| The correct solution is to have a seperate deployer that looks
| for application level metadata when processing subdeployments.
|
| In principle there is not just the context-root that can defined at the ear
| level, one could also provide things like a default "call-by-value" in
jboss-app.xml, etc.
|
| The creator of the deployment (including the profile service) should not
| be expected to know what transient managed objects need to be created.
| That is just an implementation detail of one way the deployers can "talk to each
other".
|
Right, there are multiple types of component level data that can be specified at the ear
level. There are two level of metadata for the javaee components, ear and component. I
don't see how introducing another deployer that maps from J2eeApplicationMetaData to
the component specific value is better than having the component deployer look in two
places. Something produces the J2eeApplicationMetaData (the EARStructure or another
implicit AppParsingDeployer that runs when there is no application.xml, or programmatic
definition), and component deployers look to the component level source and then to the
ear level if needed. Nothing needs to know what the component level piece of metadata for
the context-root is.
"adrian(a)jboss.org" wrote :
| Also to make this work at all, the transient managed objects would
| have to be serialized such that a remote caller can add this information
| and the profile service can remember what they were when re-creating the deployment,
| this doesn't sound correct to me.
A remote caller is passing in the ear and having the structure/regular deployers process
it. A profile service impl may only be storing the raw ear with just the
META-INF/jboss-app.xml and running through the full deployment processing every time, or
it may be saving off all metadata as predetermined overrides. I don't see where there
is an intermediate situation where a remote caller is providing transient managed
objects.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068856#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...