<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I was thinking about this a little more …<div><br></div><div>We need to distinguish between two cases</div><div><br></div><div>#1 Deployment through CLI, Console, Management API</div><div>#2 Deployment through BundleContext.install(…)</div><div><br></div><div>Re #1: In this case the webbundle URI needs to be passed through the mgmnt layer. What happens when you try this in CLI/Console? In both UIs there must be a way to pass in a URI that is then accessible from a DUP. </div><div>Given that we can see the URI in a DUP, it can be parsed after <span style="font-family: Monaco; font-size: 11px; ">OSGiBundleInfoParseProcessor</span> but before <span style="font-family: Monaco; font-size: 11px; ">BundleDeploymentProcessor.</span><span style="font-family: Monaco; font-size: 11px; "> The </span><span style="font-family: Monaco; font-size: 11px; ">BundleDeploymentProcessor</span> would see valid OSGiMetaData and everything after would proceed as normal.</div><div><br></div><div>Re #2: In this case the Framework already provides the <font face="Monaco" style="font-size: 11px;">Deployment</font> object that is then passed to the <span style="font-family: Monaco; font-size: 11px; ">BundleLifecycleIntegration.</span> By that time the metadata is already parsed and part of the Deployment. This happens in <span style="font-family: Monaco; font-size: 11px; ">AbstractBundleContext</span></div><div><br></div><div><div style="margin: 0px; font-size: 11px; font-family: Monaco; "> DeploymentFactoryPlugin deploymentPlugin = frameworkState.getDeploymentFactoryPlugin();</div><div style="margin: 0px; font-size: 11px; font-family: Monaco; "> dep = deploymentPlugin.createDeployment(location, rootFile);</div></div><div><br></div><div>Fortunately the <span style="font-family: Monaco; font-size: 11px; ">DeploymentFactoryPlugin </span>is an integration point that exits in anticipation of a requirement like this. You would need to provide a "<span style="font-family: Monaco; font-size: 11px; ">DeploymentFactoryIntegration</span>" that parses the webbundle URI in <span style="font-family: Monaco; font-size: 11px; ">createDeployment. </span>The returned Deployment is already a valid OSGi deployment. No additional work is needed in the DUPs.</div><div><br></div><div>cheers</div><div>--thomas</div><div><br></div><div><br></div><div><div><div>On Nov 30, 2012, at 3:35 PM, Thomas Diesler <<a href="mailto:thomas.diesler@jboss.com">thomas.diesler@jboss.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Good progress <div><br></div><div>> I can get the Deployment object back, given its DU.name</div><div><br></div><div>You don't need to do that. Your DUP should be placed after the BundleDeploymentProcessor, in which case the Deployment is readily available from the DU.</div><div><br></div><div>Re the Bundle.location to DU.name mapping … </div><div>The runtime name must be unique and at the same time simple enough to be usable as bundle key on the CLI. How about using the something like this</div><div><br></div><div>String toRuntimeName(String location) {</div><div> - if location is valid URI: return URI path (i.e. strip protocol & params)</div><div> - else if location has a suffix .???: return location without suffix</div><div> - else return location</div><div>}<br><div><br></div><div><br><div><div>On Nov 30, 2012, at 3:24 PM, David Bosschaert <<a href="mailto:david@redhat.com">david@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Ah, yes. Via a static method on
BundleLifecycleIntegration I can get the Deployment object back,
given its DU.name. Once I have the Deployment object I can indeed
find out the original URL and read the parameters off that.<br>
<br>
The getRuntimeName() simply returns the thing after the last "/"
in the installation location. This may be alright for things that
come from the filesystem, but if you install something from a URL
the results can be a bit random, as people can have '/'-es in
their parameters, e.g. <br>
<a class="moz-txt-link-freetext" href="http://myhost/mybundle?param1=/whatever">http://myhost/mybundle?param1=/whatever</a><br>
I will have a look at making that a bit better in that context.<br>
<br>
I noticed that the DeploymentPlanBuilder.add() has an overload
where you can provide a name and a common name. This might be
useful for OSGi in that for the common name we could pass in the
name we currently do, but for the name we could pass in the
original Bundle.location argument. I haven't fully tested this but
it seems to me that that could ensure that even in the case that
getRuntimeName() returns the same thing for two different bundles
things will still continue to work.<br>
<br>
Cheers,<br>
<br>
David<br>
<br>
On 30/11/2012 10:55, Thomas Diesler wrote:<br>
</div>
<blockquote cite="mid:D276F6E0-21BD-4D53-978E-13787E41C2B4@jboss.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>The DU runtime name is computed <a moz-do-not-send="true" href="https://github.com/jbosgi/jboss-as/blob/master/osgi/service/src/main/java/org/jboss/as/osgi/service/BundleLifecycleIntegration.java#L284">here</a></div>
<div><br>
</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
<span style="color: #0326cc">LOGGER</span>.debugf(<span style="color: #3933ff">"Install deployment: %s"</span>, dep);</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
String runtimeName = getRuntimeName(dep);</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
putDeployment(runtimeName, dep);</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
<span style="color: #931a68">try</span> {</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
InputStream input =
dep.getRoot().openStream();</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
<span style="color: #931a68">try</span> {</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
ServerDeploymentHelper server = <span style="color: #931a68">new</span> ServerDeploymentHelper(<span style="color: #0326cc">deploymentManager</span>);</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
server.deploy(runtimeName, input);</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
} <span style="color: #931a68">finally</span>
{</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
VFSUtils.safeClose(input);</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
}</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
} <span style="color: #931a68">catch</span>
(RuntimeException rte) {</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
<span style="color: #931a68">throw</span>
rte;</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
} <span style="color: #931a68">catch</span>
(Exception ex) {</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
<span style="color: #931a68">throw</span> <span style="color: #0326cc">MESSAGES</span>.cannotDeployBundle(ex,
dep);</div>
<div style="margin: 0px; font-size: 11px; font-family: Monaco; ">
}</div>
<div><br>
</div>
<div>That mapping from the Bundle.location to the DU.name is
historical and I'm not sure what the limitations currently are.
Perhaps you could find out while you're doing this and document
why <font face="Monaco"><span style="font-size: 11px;">getRuntimeName(dep)
is doing what its doing. That name also has to feed through
the management layer as the deployment's runtimeName.
Perhaps there are some limitations at that level. Have a
look at the variations of DeploymentPlanBuilder.add(…) </span></font></div>
<div><font face="Monaco"><span style="font-size: 11px;"><br>
</span></font></div>
<div><font face="Monaco"><span style="font-size: 11px;">Ideally,
we would like to pass the Bundle.location directly to the </span></font><span style="font-family: Monaco; font-size: 11px; ">DeploymentPlanBuilder</span><font face="Monaco"><span style="font-size: 11px;"> API so that it
becomes DU.name unchanged.</span></font></div>
<div><br>
<div>
<div>
<pre class="moz-signature" cols="72">xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx </pre>
<div><br>
</div>
</div>
<br class="Apple-interchange-newline">
</div>
<br>
<div>
<div>On Nov 30, 2012, at 11:29 AM, Thomas Diesler <<a moz-do-not-send="true" href="mailto:thomas.diesler@jboss.com">thomas.diesler@jboss.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space; ">> DeploymentUnit.getName()
only returns the bare name of the item being deployed
<div><br>
</div>
<div>Is this really true? What is the DU.name when you do
BundleContext.install("<a moz-do-not-send="true" href="webbundle://foo?key=value">webbundle://foo?key=value</a>",
input) ?</div>
<div><br>
</div>
<div>> I could not find the Deployment.location</div>
<div><br>
</div>
<div>
<div style="margin: 0px; font-size: 11px; font-family:
Monaco; ">Have a look at the <a moz-do-not-send="true" href="https://github.com/jbosgi/jboss-as/blob/master/osgi/service/src/main/java/org/jboss/as/osgi/deployment/BundleDeploymentProcessor.java">BundleDeploymentProcessor</a> </div>
</div>
<div><br>
<div>
<div>
<pre class="moz-signature" cols="72">xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx </pre>
<div><br>
</div>
</div>
<br class="Apple-interchange-newline">
</div>
<br>
<div>
<div>On Nov 29, 2012, at 10:11 PM, David Bosschaert
<<a moz-do-not-send="true" href="mailto:david@redhat.com">david@redhat.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Hi Thomas,<br>
<br>
If I can get the original location/URI back in the
DeploymentUnitProcessor.deploy() so I can associate
them with each other that would work for me too.
DeploymentUnit.getName() only returns the bare name
of the item being deployed (e.g. just "mywebapp"),
which isn't really precise enough. I could not find
the Deployment.location that you're referring to
from the deploy() method, is it available as an
attachment of some sort?<br>
<br>
Cheers,<br>
<br>
David<br>
<br>
On 29/11/2012 19:22, Thomas Diesler wrote:<br>
<blockquote type="cite">Hi David,<br>
<br>
The <a moz-do-not-send="true" href="webbundle://foo?key=value">webbundle://foo?key=value</a>
URL is mainly a transport vehicle for meta data. I
don't think it is intended to give access to the
bytes of the war (however, we could do this too -
see below). That URL spec (as a string) is the
Bundle.location that is given in
BundleContext(location, input). That location
identifier was originally meant to be a URL that
could give access to the Bundle's bytes. This is
no longer the case and any string (in most cases
an URI) can be given as the location. Internally,
I think the location becomes the DU name. If not,
it is definitely the Deployment.location.<br>
<br>
So a DUP does have access to that web bundle
location. The URL handler is mainly a URI parser
that is supposed to give access to the OSGi
metadata that need to be put in the manifest (in
our case the OSGiMetaData not the Manifest).
AFAIK, the Framework tries to construct a URL from
the location only if no input bytes are given.
When we talk about an URLHandler we are mainly
talking about a simple URI parser. A URLHandler
would need to be implemented for
BundleContext(location) to work.<br>
<br>
Given that the URI parsing works and that we can
generate OSGiMetaData from it, the bytes that make
up the WAR are maintained by the
DeploymentRepository and available through the DU
roots.<br>
<br>
In the unlikely case that the TCK does something
like this:<br>
<br>
<span class="Apple-tab-span" style="white-space:pre"> </span>Manifest
manifest = new Manifest(new URL("<a moz-do-not-send="true" href="webbundle://foo?key=value">webbundle://foo?key=value</a>").openStream());<br>
validateGeneratedManifest(manifest)<br>
<br>
we would need to feed back the generated
OSGiMetaData to a byte buffer. In any case that
would have to access the DU root content and amend
it by a generated Manifest.<br>
I'd have to check if the above is really required.<br>
<br>
If this does not help either, give me a shout and
I put together a quick prototype.<br>
<br>
cheers<br>
--thomas<br>
<br>
<br>
On Nov 29, 2012, at 12:29 PM, David Bosschaert
<<a moz-do-not-send="true" href="mailto:david@redhat.com">david@redhat.com</a>>
wrote:<br>
<br>
<blockquote type="cite">Hi Thomas,<br>
<br>
I have the following issues with your
suggestion.<br>
<br>
1. I don't fully see how the information
available to the URL handler can be associated
with the information available to the
DeploymentUnitProcessor. The URL handler has the
URL, that's all, while AFAICS the original URL
(or whatever was inside the webbundle: url) is
no longer available when the deploy() method is
called.<br>
2. If we find a way to fix 1. this will only
work if people use BundleContext.install(String
location). It will fail when people call
url.openStream() on the webbundle: url and does
not work with BundleContext.install(String,
InputStream).<br>
<br>
Another approach would be to simply let the URL
handler do all the work, i.e. modify the stream
being passed through. Then those URLs will work
in any context.<br>
<br>
Cheers,<br>
<br>
David<br>
<br>
On 26/11/2012 17:25, Thomas Diesler wrote:<br>
<blockquote type="cite">Hi David,<br>
<br>
here a quick summary of what I suggested
today:<br>
<br>
The first thing that sees the URL coming from
BundleContext.install(...) is the Framework,
which has a notion of pluggable URL handlers.<br>
In AS7 the URL handler should be an
integration plugin and a DUP at the same time.
The DUP would do nothing as long as the plugin<br>
is not activated (i.e. the framework is down).
When the Framework activates the URL handler
gets registered with the framework and the DUP
becomes active.<br>
<br>
The DUP would then need to provide
OSGiMetaData with a Bunde-SymbolicName and
Bundle-Classpath. The Bundle-Classpath should
point to WEB-INF/classes and<br>
the collection of stuff in WEB-INF/lib. For
completeness it could generate Package-Import
requirements on the javax.servlet.* APIs. The
DUP should be placed after<br>
the DUP that normally provides OSGiMetaData
and should do nothing if the OSGiMetaData is
already there.<br>
<br>
Hope that helps, cheers<br>
--thomas<br>
<br>
<br>
On 11/21/2012 05:58 PM, David Bosschaert
wrote:<br>
<blockquote type="cite">Hi all,<br>
<br>
As part of making the JBoss OSGi Web
Application Support compliant with<br>
the spec I have started running it through
the OSGi TCK.<br>
I noticed that the TCK depends heavily on
the webbundle: URL protocol<br>
which is specified in section 128.4 of the
specification - it is not an<br>
optional piece. So in order to support this
we need to provide such a<br>
URL handler.<br>
<br>
As the webbundle: handler is never part of
runtime operation (it only<br>
converts a WAR file into a WAB file on the
fly) I was looking into<br>
possibly using existing implementations of
the URL handler instead.<br>
However the ones that I found are quite
heavy on the dependencies. The<br>
implementation in Aries depends on Blueprint
being present and the one<br>
in Pax has about 10 other dependencies
(including junit) - they drag in<br>
too much baggage IMHO.<br>
<br>
So I'm starting to come to the conclusion
that we need to provide such<br>
an implementation as part of the OSGi
webbundle support in AS7. The JIRA<br>
is <a moz-do-not-send="true" href="https://issues.jboss.org/browse/AS7-6006">https://issues.jboss.org/browse/AS7-6006</a><br>
<br>
Any other ideas?<br>
<br>
Cheers,<br>
<br>
David<br>
_______________________________________________<br>
jboss-as7-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a><br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
jboss-as7-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br><div>
<div><pre class="moz-signature" cols="72">xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx </pre><div><br></div></div><br class="Apple-interchange-newline">
</div>
<br></div></div></div>_______________________________________________<br>jboss-as7-dev mailing list<br><a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br></blockquote></div><br><div>
<div><pre class="moz-signature" cols="72">xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx </pre><div><br></div></div><br class="Apple-interchange-newline">
</div>
<br></div></body></html>