On 15/10/2008, at 4:16 AM, David Jencks wrote:
That's one of the main missing bits of functionality. Right now
the only way to get the g-p.xml is to use c-m-p or to export the
plugin from a server it's been deployed into, or to do something by
hand with jar packing and unpacking.
The biggest problem here, in my mind, is that jsr88 only wants you
to have one "plan": to deploy something you get to specify the
artifact and one "plan". Our deployment system is built around
jsr88 so we either have to condense the g-p.xml and plan into one
"plan" or abandon jsr88.
At the moment I'm thinking that one satisfactory solution might be
to more or less embed the plan into g-p.xml. Perhaps we could
avoid duplicating most of the dependency info by adding the
<import> element to the dependencies in g-p.xml. I guess we'd
expect a more or less empty <environment> element in the plan and
fill in the dependencies from the g-p.xml when deploying.
I guess another possibility might be to include the info from g-
p.xml in the environment element of the plan.
I've been thinking about this on and off for a long time and don't
have any solution I'm entirely happy with so discussion and more
ideas are more than welcome :-)
Hi,
Another possible solution would be to allow the extension of a given
configuration by other configurations. This could work like the
web.xml fragment mechanism of the upcoming servlet specs which allows
framework libraries to transparently install Web components to the
baseline components defined by the web.xml DD.
When a configuration starts it looks for complementing configurations
whose responsibility is to alter the baseline configuration. The
identification of complementing configurations could be based on a
simple naming convention scheme, e.g. if the base configuration is
org/tomcat6//car then all the configurations matching the pattern org/
tomcat6-transform-DiscriminatorName//car are identified as
complementing configurations.
If there are complementing configurations, then the baseline
ConfigurationData could be passed to them for arbitrary
transformation, e.g. add, update or remove dependencies. An updated
ConfigurationData is passed back and actually loaded by the kernel.
The main drawback of this approach is the added configuration
complexity. The main benefits is that it provides application server
configuration traceability and a mean to perform very simple changes
to a baseline configuration w/o having to redefine in its entirety
the configuration to be slightly changed.
In another thread about scripting language integration, I suggested
an even simpler approach whereby a script is executed to perform
ConfigurationData transformations.
If any of these two options are plausible solutions, then I am happy
to move forward with an implementation.
Thanks,
Gianny
thanks
david jencks
