Dear Hong
>
> 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
Thanks your suggestions very much. You and Sahoo are right!
> code to interpret any container specific properties has to stay in the
> container specific code and not the generic deployment infrastructure
>code.
I will modify my prototype.
--Best Regard!
--Tang
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
>>>>>>>>>>
>>>>