Dear Sahoo,
Thanks your reviewing for my prototype very much.
> b) Explore the possibilities of passing additional deployment
>properties or deployment plan to --type=osgi deployment.
I also think it is a good idea, and if having ideas, I will discuss with
you and Hong Zhang again.
> Admin team (Tom) can comment about #a, where as deployment team (Hong)
> can comment about #b.
I will wait for their suggestions.
--Tang
Sahoo 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.
>
> 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
>>>>>>>>>
>>>
>
>
>