Hi David,
You are correct: the underpinning philosophy of these approaches is
to make it easier to modify pre-canned plugins through extension points.
This may be a good approach to improve further the packaging model of
dependencies and services. Let's say that an end-user wants to add a
connector to the tomcat6 plugin. Instead of using the admin console
or updating his config.xml, he can simply deploy a cumulative plan.
This notion of cumulative plan is the key differentiator as users can
share their cumulative plans "as-is" - i.e. w/o knowing what the
plugin to be modified looks like. To some extent, providing a plan
ready to be deployed instead of deployment instructions is better for
novices.
I will work on the Groovy builder approach and post back more details
as I go.
Thanks,
Gianny
On 16/10/2008, at 10:59 AM, David Jencks wrote:
Hi Gianny,
First, I'd like to make sure I understand the philosophy behind
your proposals. IIUC they both involve the idea of making it easy
to modify an existing plugin rather than making it easy to replace
an existing plugin with a similar one.
Why is this a good idea? My idea has been that we should make it
easier to replace a plugin with a similar one than modify an
existing one, and then we will have the best of all worlds.
All this being said, I think your ideas are both quite
interesting. I'm especially interested in the groovy builder
approach.
I'll be fairly unavailable until next week but might keep thinking
about this anyway.
thanks!
david jencks
On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
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
