Re: Should we let users override context-root for wars in an ear?
David, I agree that it is not confusing to allow a plan to override context path in application.xml Generally speaking, I think it is valuable to have override mechanisms for much of the configuration in the deployment bundles. This goes for context path in application.xml and things like init parameters in web.xml. It is a pain and also a management issue to have to open up a deployment bundle (possible delivered by a third party and checksumed and controlled as a versioned deliverable) to change configuration. Ideally I would like us to be able to never need crack open and modify a war or ear in order to perform assembly and the ability to do this is a strength of the geronimo ability to have an external plan. cheers David Jencks wrote: > I was irc-ing today with someone who suggested it would be useful to > make it possible for our plans to override the context-root in an ear's > application.xml with a different value in our plan somewhere.One > obvious choice is the context-root in a web plan. After thinking about > this a bit I think it would be a nice convenience for our users, and I > personally don't see how it would introduce confusion. My impression > of the spec's discussion of application.xml is that it tends to > describe it as a bunch of hints from the person doing the assembly role > to the person doing the deployment role. > > Jeff Genender and I tried to do a little survey of what the other app > servers do and think it is as follows: > > weblogic -- app.xml setting overrides any web plan context root. > jboss - app.xml setting overrides > jonas -- there appears to be no way to set the context root other than > the application.xml: a standalone war uses its file name. > orion - appears to allow the application plan to override application.xml > websphere -- can't tell, the administrative tools certainly allow > changing context root but it is not clear if that results in a change > to application.xml or a plan > trifork - can't tell > > See also http://issues.apache.org/jira/browse/GERONIMO-1470 > > thanks > david jencks > >
Re: Should we let users override context-root for wars in an ear?
This is an interesting subject. The question is, do we do things consistently? My concern at the moment is to have the application.xml be the deciding factor for one reason. People can go into the config.store and look at it and determine, that the context-root is set to a value and assume that is the context. It also makes it consistent with 2 other application servers that may be our biggest flood of Geronimo converts (Weblogic and JBoss). As is stands we have no way to obtain the plan...so it can be confusing as to what the context-root is. Granted, this is a situation with the geronimo-web.xml as well, but in a normal web.xml, there is no way to set this...so its kind of different. The only true way to see it from the config.store is the application.xml. For this reason I would say it should be the overall deciding factor...at least for now. However, I think if we can retrieve readable plans from the config.store (or console or whatever), then it may be fine to say its the plan. I guess what I am looking for is a way to get the context and know its consistent. Maybe a future idea...perhaps the ability to look in the console or a command line tool that can tell you the context, and why (plan, application.xml, geronimo-web.xml, config-id, war name). Just my .05. Jeff David Jencks wrote: > I was irc-ing today with someone who suggested it would be useful to > make it possible for our plans to override the context-root in an ear's > application.xml with a different value in our plan somewhere. One > obvious choice is the context-root in a web plan. After thinking about > this a bit I think it would be a nice convenience for our users, and I > personally don't see how it would introduce confusion. My impression of > the spec's discussion of application.xml is that it tends to describe it > as a bunch of hints from the person doing the assembly role to the > person doing the deployment role. > > Jeff Genender and I tried to do a little survey of what the other app > servers do and think it is as follows: > > weblogic -- app.xml setting overrides any web plan context root. > jboss - app.xml setting overrides > jonas -- there appears to be no way to set the context root other than > the application.xml: a standalone war uses its file name. > orion - appears to allow the application plan to override application.xml > websphere -- can't tell, the administrative tools certainly allow > changing context root but it is not clear if that results in a change to > application.xml or a plan > trifork - can't tell > > See also http://issues.apache.org/jira/browse/GERONIMO-1470 > > thanks > david jencks
Should we let users override context-root for wars in an ear?
I was irc-ing today with someone who suggested it would be useful to make it possible for our plans to override the context-root in an ear's application.xml with a different value in our plan somewhere. One obvious choice is the context-root in a web plan. After thinking about this a bit I think it would be a nice convenience for our users, and I personally don't see how it would introduce confusion. My impression of the spec's discussion of application.xml is that it tends to describe it as a bunch of hints from the person doing the assembly role to the person doing the deployment role. Jeff Genender and I tried to do a little survey of what the other app servers do and think it is as follows: weblogic -- app.xml setting overrides any web plan context root. jboss - app.xml setting overrides jonas -- there appears to be no way to set the context root other than the application.xml: a standalone war uses its file name. orion - appears to allow the application plan to override application.xml websphere -- can't tell, the administrative tools certainly allow changing context root but it is not clear if that results in a change to application.xml or a plan trifork - can't tell See also http://issues.apache.org/jira/browse/GERONIMO-1470 thanks david jencks
