Dear Sahoo,
> asadmin deploy --type osgi --properties uriScheme=wab
>queryParams="comma separated name=value pairs"
> then you can just create a new URI inside OSGiArchiveHandler.expand().
> You can then obtain an InputStream from the new URI and use the same.
>
Thanks your suggestion very much! I will adopt it.
However, about coupling, I have a problem.
> you take properties like the following, you can avoid the decoupling:
Firstly, I want to know that "decoupling" is whether the coupling
between the osgi-container module and osgi-web-container module.
If yes, then, the coupling must exist in the following:
for (ServiceReference r : urlhandlers) {
urlhandler = (URLStreamHandlerService) osgicontext.getService(r);
if (urlhandler instanceof WebBundleURLStreamHandlerService) {
break;
}
}
The reason using WebBundleURLStreamHandlerService as filter is that
on the point of executing expand method, osgi registry has other
URLStreamHandlerService implementations besides
WebBundleURLStreamHandlerService. So, I added a filter.
--Best Regard!
--Tang
Sahoo wrote:
> On Tuesday 10 July 2012 06:25 PM, Tang Yong wrote:
>> Dear Hong, sahoo,
>>
>> I have modified the prototype and removed the container-related logic on
>> DeployCommand and DeploymentContextImpl.
>>
>> 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
>>
> Very cool. I browsed your code and here are some comments:
>
> OSGiArchiveHandler cannot not know about WAB - WAB support is provided
> by osgi-web-container, so the dependency needs to be broken. I think if
> you take properties like the following, you can avoid the decoupling:
>
> asadmin deploy --type osgi --properties uriScheme=wab queryParams="comma
> separated name=value pairs"
>
> then you can just create a new URI inside OSGiArchiveHandler.expand().
> You can then obtain an InputStream from the new URI and use the same.
>
>
>> 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.
>>
> You should file a bug.
>
> Sahoo
>
>