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.
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
>>>>>>>>
>>
>>
>