> if (properties != null) {
> deploymentContext.getAppProps().putAll(properties);
> validateDeploymentProperties(properties, deploymentContext);
> }
>
> So you could look a little further on this.
Thanks , I will look a little further again.
--Best Regard!
--Tang
hong.hz.zhang_at_oracle.com wrote:
> Hi Tang
>> Dear Hong, sahoo,
>>
>> I have modified the prototype and removed the container-related logic on
>> DeployCommand and DeploymentContextImpl.
> Great thanks.
>> Now, using the following way can deploy a wab:
>>
>> 1)asadmin deploy --type=osgi --properties Web-ContextPath=/test_sample1
>> e:\test_sample1.war
>>
>> 2)asadmin deploy --type=osgi e:\test_sample2.war
>>
>> In addition, about
>>> DeploymentContext.getAppProps through the deployment lifecycle
>> I have confirmed that when using "--properties
>> Web-ContextPath=/test_sample1", "DeploymentContext.getAppProps" can not
>> get the value of "Web-ContextPath" option. However, using
>> "context.getCommandParameters(DeployCommandParameters.class).properties.getProperty("Web-ContextPath")"
>> can get the value of "Web-ContextPath" option. So, I think that a bug
>> may be exist in DeploymentContextImpl class.
>
> I just tried a simple deployment
> asadmin deploy --properties foo=bar hello.war
>
> I could see the foo=bar got stored in the DeploymentContext properly
> (the code below is in the DeployCommand.java):
>
> if (properties != null) {
> deploymentContext.getAppProps().putAll(properties);
> validateDeploymentProperties(properties, deploymentContext);
> }
>
> So you could look a little further on this.
>
> Thanks,
>
> - Hong
>
>> hong.hz.zhang_at_oracle.com wrote:
>>>> I briefly looked at the patch and found following issues:
>>>>
>>>> a) DeployCommand has been changed to know about WAB. That's not allowed,
>>>> because DeployCommand does not know anything about actual containers.
>>>>
>>>> b) Same with DeploymentContextImpl.
>>> Agree! The deployment infrastructure code has to stay generic and does
>>> not contain any container specific logic.
>>>
>>> If you want to use properties, you could use the generic properties
>>> option of the deploy command:
>>>
>>> asadmin deploy --properties foo=bar:foo2=bar2 ... [path to archive]
>>>
>>> And the values of the properties will be available in
>>> DeploymentContext.getAppProps through the deployment lifecycle. But the
>>> code to interpret any container specific properties has to stay in the
>>> container specific code and not the generic deployment infrastructure code.
>>>
>>> Thanks,
>>>
>>> - Hong
>>>
>>>
>>>
>>>> I think there are two possible approaches:
>>>> a) Allow deploy cli to accept a URI that's resolved in server side in
>>>> addition to an actual path to a file in local file system as it is
>>>> taking today.
>>>>
>>>> b) Explore the possibilities of passing additional deployment properties
>>>> or deployment plan to --type=osgi deployment.
>>>>
>>>> Admin team (Tom) can comment about #a, where as deployment team (Hong)
>>>> can comment about #b.
>>>>
>>>> Sahoo
>>>>
>>>> On Sunday 08 July 2012 02:04 PM, Tang Yong wrote:
>>>>> Dear Sahoo,Hong Zhang,
>>>>>
>>>>> Now, about using way of "--type=osgi",I have changed my prototype and
>>>>> reflected modified files into
>>>>> https://github.com/tangyong/GLASSFISH-16651. (I have reused the
>>>>> OSGiArchiveHandler.java)
>>>>>
>>>>> On the current prototype implementation, user can using the following
>>>>> way to deploy a wab and launch the wab successfully:
>>>>>
>>>>> 1 asadmin deploy --type=osgi
>>>>> e:\test_sample1.war?Web-ContextPath=/test_sample1
>>>>>
>>>>> In the original test_sample1.war's Manifest.MF, not containing any
>>>>> osgi-related metadata.
>>>>>
>>>>> 2 asadmin deploy --type=osgi e:\test_sample2.war
>>>>>
>>>>> In the original test_sample2.war's Manifest.MF, not containing any
>>>>> osgi-related metadata other than "Web-ContextPath" metadata.
>>>>>
>>>>> 3 asadmin deploy --type=osgi
>>>>> e:\test_sample3.war?Web-ContextPath=/test_sample4
>>>>>
>>>>> In the original test_sample3.war's Manifest.MF, only containing
>>>>> "Web-ContextPath: /test_sample3" metadata. However, /test_sample4 will
>>>>> rewrite /test_sample3.
>>>>>
>>>>> About the following
>>>>>
>>>>>> The war to wab conversion is configurable. So, please evaluate how
>>>>>> user can provide additional configuration.
>>>>> I want to investigate the other frameworks which have implemented RFC#66
>>>>> firstly on next week.
>>>>>
>>>>> In addition, I also want to investigate how to add "load" wab bundle on
>>>>> admin-gui, because nowaday, once wab is deployed, on admin-gui, the wab
>>>>> can not be launched directly.
>>>>>
>>>>> --Best Regard!
>>>>> --Tang
>>>>>
>>>>> Sahoo wrote:
>>>>>> No. FighterFish modules are backward compatible with GlassFish 3.1.x, so
>>>>>> they depend on older artifacts.
>>>>>>
>>>>>> On Saturday 07 July 2012 12:17 PM, Tang Yong wrote:
>>>>>>> Dear Sahoo,
>>>>>>>
>>>>>>> OK, I will investigate and contribute much!
>>>>>>>
>>>>>>> In addtion, the pom files of fighterfish\module
>>>>>>> seem not to keep consistent with GFv4 main/pom.xml, such as:
>>>>>>>
>>>>>>> <dependency>
>>>>>>> <groupId>org.glassfish.web</groupId>
>>>>>>> <artifactId>web-glue</artifactId>
>>>>>>> </dependency>
>>>>>>>
>>>>>>> In GFv4, the groupId of web-glue has changed into org.glassfish.main.web.
>>>>>>>
>>>>>>> need to update them?
>>>>>>>
>>>>>>> --Best Regard!
>>>>>>> --Tang
>>>>>>>
>>>>>>> Sahoo wrote:
>>>>>>>> The war to wab conversion is configurable. So, please evaluate how user
>>>>>>>> can provide additional configuration.
>>>>>>>>
>>>>>>>> Thank you for your effort,
>>>>>>>> Sahoo
>>>>>>>> On Saturday 07 July 2012 11:46 AM, Tang Yong wrote:
>>>>>>>>> Dear Sahoo,Hong Zhang
>>>>>>>>>
>>>>>>>>> Thanks your suggestions very much!
>>>>>>>>>
>>>>>>>>>> Hong is right. No, we don't want --type=wab. Instead, we should let
>>>>>>>>>> user use --type=osgi and we automatically wrap it if user has given us
>>>>>>>>>> a war file.
>>>>>>>>>>
>>>>>>>>>>> For step 2, did you mean --type osgi instead of --type wab? I >
>>>>>>>>>> don't think we want to introduce another type here..
>>>>>>>>> OK, I have understood and will modify my prototype.
>>>>>>>>>
>>>>>>>>>>> I think we already have an archive handler for OSGI today
>>>>>>>>>>>
>>>>>>>>> (main/appserver/extras/osgi-container/src/main/java/org/glassfish/extras/osgicontainer/OSGIArchiveHandler),
>>>>>>>>>
>>>>>>>>>>> maybe we could re-use that class instead of adding a new class, but
>>>>>>>>>>> Sahoo is the expert in this area so I will let him comment on it.
>>>>>>>>> If using --type=osgi, indeedly,OSGIArchiveHandler could be reused.
>>>>>>>>>
>>>>>>>>> I will continue to finish my prototype according to your suggestions.
>>>>>>>>>
>>>>>>>>> --Best Regard!
>>>>>>>>> --Tang
>>>>>>>>>
>>>>>>>>> Sahoo wrote:
>>>>>>>>>> Hong is right. No, we don't want --type=wab. Instead, we should let
>>>>>>>>>> user use --type=osgi and we automatically wrap it if user has given us a
>>>>>>>>>> war file.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Sahoo
>>>>>>>>>> On Friday 06 July 2012 07:48 PM, hong.hz.zhang_at_oracle.com wrote:
>>>>>>>>>>> Hi, Tang
>>>>>>>>>>> Thanks for contributing to the GlassFish!
>>>>>>>>>>>
>>>>>>>>>>> For step 2, did you mean --type osgi instead of --type wab? I don't
>>>>>>>>>>> think we want to introduce another type here..
>>>>>>>>>>>
>>>>>>>>>>> I think we already have an archive handler for OSGI today
>>>>>>>>>>> (main/appserver/extras/osgi-container/src/main/java/org/glassfish/extras/osgicontainer/OSGIArchiveHandler),
>>>>>>>>>>> maybe we could re-use that class instead of adding a new class, but
>>>>>>>>>>> Sahoo is the expert in this area so I will let him comment on it.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> - Hong
>>>>>>>>>>>
>>>>>>>>>>> On 7/6/2012 3:05 AM, Tang Yong wrote:
>>>>>>>>>>>> Dear Sahoo
>>>>>>>>>>>> CC: Hong Zhang
>>>>>>>>>>>>
>>>>>>>>>>>> I have made a prototype of GLASSFISH-16651 and put the modified files
>>>>>>>>>>>> into https://github.com/tangyong/GLASSFISH-16651 .
>>>>>>>>>>>>
>>>>>>>>>>>> Currently, the prototype can work for me. If using the following way,
>>>>>>>>>>>> plain vanilla WAR can be wraped WAB(osgi rfc#66) and can be accessed
>>>>>>>>>>>> from Brawser.
>>>>>>>>>>>>
>>>>>>>>>>>> 1 asadmin start-domain
>>>>>>>>>>>>
>>>>>>>>>>>> 2 asadmin deploy --type=wab
>>>>>>>>>>>> e:\test_sample1.war?Web-ContextPath=/test_sample1"
>>>>>>>>>>>>
>>>>>>>>>>>> 3 access "http://localhost:8080/test_sample1/" and "Hello! Servlet3.0
>>>>>>>>>>>> Sample1111111111" appeared!
>>>>>>>>>>>>
>>>>>>>>>>>> In addtion, after teleneting localhost 6666, executing "lb" on shell,
>>>>>>>>>>>> and will find the following bundle info:
>>>>>>>>>>>>
>>>>>>>>>>>> " 274|Active | 1|org.glassfish.fighterfish.autogenerated_0 (0.0.0)"
>>>>>>>>>>>>
>>>>>>>>>>>> [My Design Idea]
>>>>>>>>>>>> The critical point is to find the integration point between the deploy
>>>>>>>>>>>> moudle and fighterfish\module\osgi-web-container moudle. So, I made a
>>>>>>>>>>>> new subclass of GenericHandler called(OSGiWABArchiveHandler) in
>>>>>>>>>>>> org\glassfish\extras\osgicontainer. Then, in the "expand" method, add
>>>>>>>>>>>> the following logic:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) getting WebBundleURLStreamHandlerService service from osgi registry
>>>>>>>>>>>> 2) while the deploy process is expanding war, rewrite the war's Manifest
>>>>>>>>>>>>
>>>>>>>>>>>> If having time, wish you can see it and I will continue to contribute it
>>>>>>>>>>>> according your suggestions.
>>>>>>>>>>>>
>>>>>>>>>>>> BTW: when I made the prototype, I found that some dependency declarings
>>>>>>>>>>>> of pom file in the fighterfish\module(etc.osgi-web-container) did not
>>>>>>>>>>>> keep consistent with GFv4 main/pom.xml, such as:
>>>>>>>>>>>>
>>>>>>>>>>>> <dependency>
>>>>>>>>>>>> <groupId>org.glassfish.web</groupId>
>>>>>>>>>>>> <artifactId>web-glue</artifactId>
>>>>>>>>>>>> </dependency>
>>>>>>>>>>>>
>>>>>>>>>>>> In GFv4, the groupId of web-glue has changed into org.glassfish.main.web.
>>>>>>>>>>>>
>>>>>>>>>>>> --Best Regard!
>>>>>>>>>>>> --Tang
>>>>>>>>>>>>
>
>