Hi Tang
> Dear Hong, sahoo,
>
> I have modified the prototype and removed the container-related logic on
> DeployCommand and DeploymentContextImpl.
Great thanks.
>
> Now, using the following way can deploy a wab:
>
> 1)asadmin deploy --type=osgi --properties Web-ContextPath=/test_sample1
> e:\test_sample1.war
>
> 2)asadmin deploy --type=osgi e:\test_sample2.war
>
> In addition, about
>> DeploymentContext.getAppProps through the deployment lifecycle
> I have confirmed that when using "--properties
> Web-ContextPath=/test_sample1", "DeploymentContext.getAppProps" can not
> get the value of "Web-ContextPath" option. However, using
> "context.getCommandParameters(DeployCommandParameters.class).properties.getProperty("Web-ContextPath")"
> can get the value of "Web-ContextPath" option. So, I think that a bug
> may be exist in DeploymentContextImpl class.
I just tried a simple deployment
asadmin deploy --properties foo=bar hello.war
I could see the foo=bar got stored in the DeploymentContext properly
(the code below is in the DeployCommand.java):
if (properties != null) {
deploymentContext.getAppProps().putAll(properties);
validateDeploymentProperties(properties, deploymentContext);
}
So you could look a little further on this.
Thanks,
- Hong
> 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
>>>>>>>>>>>
>