Features first. Currently the Assembler takes an exploded WAR and re-writes the web.xml, possibly copying it a new location (the entire exploded WAR is not copied). I would like to propose the following modes of function for the Assembler: -Re-writing the web.xml in an exploded WAR, either in place or writing the updated web.xml to a new location (exactly what it does now) -Re-writing the web.xml in a compressed WAR, either in place or writine the updated WAR to a new location
With those features in mind I'm trying to think of good names for the properties in AssemblerConfig and the AssembleTask, keeping in mind of course the existing property names should not change to maintain compatibility.
AssemblerConfig currently has the following properties: -portletDescriptor - The path & name of the portlet.xml -webappDescriptor - The path & name of the web.xml -destination - The destination of the re-written web.xml-dispatchServletClass - (optional) name of the servlet class to add to the web.xml
AssembleTask currently has the following properties: -portletxml - (ignored if webapp is set) Path & name of the portlet.xml -webxml - (ignored if webapp is set) Path & name of the web.xml-destfile - (optional, defaults to source web.xml) Destination of the re-written web.xml
For WAR file support I need warSource and warDestination properties on both the AssemblerConfig and AssembleTask.
Does this plan (and names) look workable? -Eric Elliot Metsger wrote:
Ditto, thanks Eric :-) David H. DeWolf wrote:Sounds good to me. Thanks for the contribution. Eric Dalquist wrote:I'm looking at using the Pluto assembler to deploy portlet webapps for uPortal 3. Our current deployer deals with WARs by extracting them to a temp directory, modifying the web.xml and re-packing them before copying them into tomcat.I'd like to provide a patch to the Pluto assembler code to move the web.xml re-writing logic into a utility class and add a WarAssembler in addition to the FileAssembler. The WarAssembler would extract a WAR, re-write the web.xml and repack the WAR to a new location. There wouldn't be any logic specific to tomcat or any other container.I've created a Jira issue for the enhancement as well: https://issues.apache.org/jira/browse/PLUTO-314All feedback is welcome, -Eric
smime.p7s
Description: S/MIME Cryptographic Signature
