Hong Zhang wrote on 06/29/10 07:16 AM:
> Hi, Ludo
>>>>>>> 3. The support for autodeploy/JSR88. In the asarch review of the
>>>>>>> deployment one pager, we talked about it will be too much work to
>>>>>>> support every single command line option in the deployment
>>>>>>> descriptors
>>>>>>> so we will treat them case by case. Is this option worth the work to
>>>>>>> support in the deployment descriptors?
>>>>>> Don't know.
>>>>> Ok, let's have the option supported only through the command line
>>>>> in this release and decide whether to add it in the deployment
>>>>> descriptor in next release based on the user feedback.
>>>> or could be easier and very generic to add a single field in the DD
>>>> that would contain a string which value would be the content of the
>>>> cli command params?
>>> Could you expand on this? Like a property element with a name (option
>>> name) and a value (option value)?
>>>
>>> Thanks,
>>>
>>> - Hong
>> For example:
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD GlassFish
>> Application Server 3.1 Servlet 3.0//EN"
>> "http://www.sun.com/software/appserver/dtds/sun-web-app_3_1-0.dtd">
>> <sun-web-app error-url="">
>> <context-root>/WebApplication4</context-root>
>> <class-loader delegate="true"/>
>> ....
>> * <deployment-params> --foo=bar --keeptable =true etc etc
>> </deployment-params>*
>> </sun-web-app>
> I see what you are saying. A few thoughts on the implementation side:
> 1. This element will need to be parsed very early in the deployment
> lifecycle before the regular DOL processing happens. Some of the
> information like name needs to be obtained very early. And we will need
> to look at all level of the glassfish-*.xml for this element (I assume
> the top level should override the module level in case of ear). This
> part will not be trivial to implement.
> 2. We will need to parse the String to obtain various option values, but
> this should not be too bad.
> 3. I assume the precedence will be real command line options, the
> deployment-params element values, and other element values which specify
> similar thing (like the context-root element). The overriding logic will
> not be trivial to implement, and this means all the current Boolean
> value command line options need to have tri-value (true/false/null) for
> the deployment descriptor to correctly override.
>
> While I agree this could be a potential generic solution to address all
> the deployment options for autodeploy/JSR88, I am reluctant to commit to
> this for this release due to time constraint. We could file a RFE for
> this with the proposed solution and revisit in next release.
Rather than creating another place that has to parse a command line,
wouldn't it be more appropriate to have a general way to specify
option names and values as XML?
<deployment-params>
<param><name>foo</name><value>bar</value></param>
<param><name>keepstate</name><value>true</value></param>
</deployment-params>