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