Dear Sahoo, Hong, Tom
> The war to wab conversion is configurable. So, please evaluate how
>user can provide additional configuration.
About the above point, after investigating some frameworks with similar
functions, I have some ideas to discuss with you.
1. way of war to wab conversion
1) admin cli
using "deploy --type=osgi --properties XXX" command, and XXX can be the
following:
・Web-ContextPath
・Bundle-SymbolicName
・Bundle-Version
・Bundle-ClassPath
2) admin gui
I wish to deploy wab the same as using admin cli, thus will more
convenient for a user. So, maybe need to extend the current
deploy-related gui pages.
3) felix shell
Although user can telent to felix shell, just as saying on
GLASSFISH-16998 and GLASSFISH-13006, maybe turn off the shell for
production. So, the way is not a good way.
2 protocol of war to wab conversion
For a user, he/she maybe deploy a wab using the following protocol:
1)Local File
For example: asadmin deploy --type=osgi --properties
Web-ContextPath=/test_sample1 e:\test_sample1.war
2)http protocol
For example: asadmin deploy ...
http://repo1.maven.org/maven2/org/apache/wicket/wicket-examples/1.3.0/wicket-examples-1.3.0.war
3)mvn protocol
For example: asadmin deploy ...
mvn:org.apache.wicket/wicket-examples/1.3.0/war
4)using a instructions file(Normally a bnd file) to deploy a war using
user-defined metadata.
For example: asadmin deploy ...
E:/Data/Examples/wicket-examples-1.4.7.bnd
The above 2),3),4) are all implemented by Pax Web and some other
frameworks using pax web(such as Karaf, Paremus Service Fabric,...), so,
I think that whether glassfish can also support some of these protocols
or not.
In addition, if supporting some of 2),3),4), a small problem may be
considered. On executed method of DeployCommand class, there are some
codes as following:
if (!path.exists()) {
...
return;
}
if (!path.canRead()) {
...
return;
}
>Hong:
Obviously, the above codes assumed that path is a file.Then,if using
http protocol to deploy a wab, I will modify these codes. So, whether
this will violate a rule that :
>the code to interpret any container specific properties has to stay in
>the container specific code and not the generic deployment
>infrastructure code.
--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
>>>>>
>
>
>