[jboss-dev-forums] [Design of POJO Server] - Re: JBossAppParsingDeployer issue

[scott.stark@jboss.org]

"adrian at 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 at 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 at 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#4068856

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068856