<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; "><div>The DU runtime name is computed <a 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 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=iso-8859-1"><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 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 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 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 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 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 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 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 href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br><a 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 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></body></html>