On Wed, Oct 15, 2008 at 7:59 PM, David Jencks <[EMAIL PROTECTED]>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. > I think, from a user perspective, the best of all possible worlds is to have both options available. Thinking in the context of the original custom valve scenario, since we seem to have expanded the scope a little, it shouldn't be necessary for a straight user to delve into the world of plugins to deploy a valve. Regardless of how simple we make deploying a plugin, that's still an added level of complexity that we shouldn't require of a user who is working solely in the realm of a webapp. I realize I made this argument earlier, but after tinkering with your proposed approach and thinking about it some more, I've come back around to my original line of thinking, though hopefully better informed this time. I understand the objections to the original proposal of using an attribute, but if sufficiently simple to define, Gianny's approach might be the right way to accomplish the same goal. At the same time, I'm still all for improving and simplifying the method in which we deploy plugins. > > 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 >>> >>> > -- ~Jason Warner
