Hi Gianny, Have you made any progress with this? Are you targeting this for the 2.2 release (whenever that happens to be)?
Thanks! On Fri, Oct 17, 2008 at 8:11 PM, Gianny Damour < [EMAIL PROTECTED]> wrote: > Hi, > > I am proposing the following implementation to start with: > > 1. In the META-INF folder of a config, we scan for files matching the > patterns "dependencies-(.*).groovy" and "extentions-(.*).groovy". > > 2. We execute the scripts "dependencies-(.*).groovy" which modify > dependencies. For instance, such scripts may look like: > > configurationData + dependency(groupId: 'group', artifactId: 'artifact', > version: '1.1', type: 'jar', importType: importType) -- add the declared > dependency > configurationData - dependency(groupId: 'group', artifactId: 'artifact', > version: '1.0', type: 'jar') -- remove the declared dependency > > This gives us the final classloader of the config. > > 3. We execute the scripts "extentions-(.*).groovy" which update the GBeans, > For instance, such scripts may look like: > > gBeanBuilder.configure { > addGBean(BasicNodeInfo) { -- add a GBean > attribute(name: 'node1') > attribute(extendedJMXConnectorInfo: new > BasicExtendedJMXConnectorInfo(...)) > reference(referenceName) { > pattern('aPattern') > pattern('aSecondPattern') > } > } > removeGBeansMatching('aPattern') > } > > gBeanBuilder.updatedConfigurationData > > The implementation of such scripts should be as simple as the modification > of config.xml. > > The fact that they are collocated with the configuration they modify > increases cohesion. It would be neat to have such scripts instead of the > native or XStream serializations of config.ser. > > Let me know your thoughts? > > Thanks, > Gianny > > > > On 16/10/2008, at 11:17 PM, Jason Warner wrote: > > While David is more interested in the philosophy, I'd prefer to know a >> little bit more about your thoughts on implementation. Specifically what do >> you imagine would be involved in defining this configuration? Would it be >> as simple as a definition in config.xml? >> >> On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour < >> [EMAIL PROTECTED]> wrote: >> 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 >> >> >> >> >> >> >> -- >> ~Jason Warner >> > > -- ~Jason Warner