karaf community, we decided to not maintain it here anymore and to move it over karaf. No big love until today AFAIK but tomee community shouldn't take it back I think since it would just make it lost in the middle of nowhere today.
Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-08-13 13:32 GMT+02:00 dsh <[email protected]>: > An SPI solution was something I thought of in the first place but then my > intention while providing feedback was to provide some pointers how the > existing patch could be enhanced. > > Speaking of moving the OSGi stuff to Karaf - Does the current OSGi stuff > for TomEE has a maintainer? > > Cheers > Daniel > > > On Wed, Aug 13, 2014 at 1:19 PM, Romain Manni-Bucau <[email protected]> > wrote: > >> No reflection but a spi in system instance component >> >> Also forgot to mention we decided to move osgi stuff to karaf project >> months ago and forget it in tomee itself so clearly a spi solution imho >> Le 13 août 2014 12:02, "Kasun Gajasinghe" <[email protected]> a écrit : >> >> > Hi Daniel, >> > >> > Please see my comments in-line. >> > >> > >> > On Wed, Aug 13, 2014 at 1:47 PM, dsh <[email protected]> wrote: >> > >> > > Hi Kasun, >> > > >> > > thanks for providing this patch, appreciated! I am pondering a bit >> around >> > > the fact that it seems the patch would only work if running inside an >> > > Equinox environment. Is my understanding correct that the patch >> actually >> > > isn't OSGi runtime agnostic but only works together with Eclipse >> Equinox >> > > and not for instance with Apache Felix due to the explicite dependency >> on >> > > BundleURLConnection? >> > > >> > > >> > Yes, this will only work in Eclipse Equinox. I did not dig around much on >> > Felix, but my next goal is that. So, I will update this thread on that >> > soon. >> > >> > >> > > Also note that BundleURLConnection is part of an internal package. My >> > > understanding here is that using classes from an internal package >> should >> > be >> > > avoided where possible (see: [1] x-internal Directive) cause these are >> > > actually implementation specific classes. >> > > >> > > >> > I did look around what other approach I can take, but could not find one >> > that do not change the TomEE design. Since TomEE needs to convert the >> URLs >> > to actual file paths I had to follow this approach. >> > >> > >> > > Also I was wondering whether accessing the BundleURLConnection class >> like >> > > it is shown below, would remove the explicit dependency: >> > > >> > > final URLConnection conn = url.openConnection(); >> > > if (conn.getClass().getName().equals( >> > > "org.eclipse.osgi.framework.internal.core.BundleURLConnection")) { >> > > final Method method = conn.getClass().getMethod("getLocalURL", null); >> > > method.setAccessible(true); >> > > >> > > if (null != method) { >> > > toFile((URL) method.invoke(conn, null);); >> > > } >> > > } >> > > >> > > What do you think? If there would be a way to make this OSGi framework >> > > independent, that would be great I'd suppose. >> > > >> > > >> > Absolutely, +1. Thanks for clarifying this. I was inclined to know >> whether >> > TomEE devs prefer a Java reflection based approach. >> > >> > I will also adapt the use of FRAMEWORK_VENDOR because the url-to-file >> > conversion is vendor specific. >> > >> > Thanks, >> > KasunG >> > >> > >> > > [1] >> > > >> > > >> > >> http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html >> > > >> > > Cheers >> > > Daniel >> > > >> > > >> > > On Wed, Aug 13, 2014 at 9:33 AM, Kasun Gajasinghe <[email protected]> >> > > wrote: >> > > >> > > > Hi folks, >> > > > >> > > > Currently, when TomEE scans it's libraries for TLDs etc. via the >> > > > URLClassLoader, it gets a list of URLs pointing to jar files. To >> > process >> > > > these TomEE converts these URLs to actual file paths. As seen in this >> > > code >> > > > segment [1], TomEE only processes URLs that have jar:/ or file:/ >> > > protocol. >> > > > This works fine in a non-OSGi environment. >> > > > >> > > > But in OSGi environments, they have OSGi bundles instead of jars. So, >> > > what >> > > > the URLClassloader returns is a set of URLs with bundleresource:/ >> > > protocol >> > > > pointing to the bundles. We can in fact get the actual file path from >> > the >> > > > bundleresource:/ protocol as well. >> > > > >> > > > So, I'm writing this mail to the kind folks at TomEE to consider >> > > supporting >> > > > bundleresource:/ protocol as well. I have attached a patch for this >> in >> > > this >> > > > jira [2]. The patch worked fine in my OSGi enabled runtime based on >> > > > Equinox. One caveat of this patch is that it adds Equinox as a >> > > compile-time >> > > > dependency. But the TomEE runtime can function without this >> dependency. >> > > > >> > > > I hope this is the proper channel to talk about this. I'd value your >> > > > feedback very much! >> > > > >> > > > [1] >> > > > >> > > > >> > > >> > >> https://github.com/apache/tomee/blob/trunk/container/openejb-loader/src/main/java/org/apache/openejb/loader/Files.java#L391 >> > > > >> > > > [2] https://issues.apache.org/jira/browse/TOMEE-1292 >> > > > >> > > > Thanks, >> > > > KasunG >> > > > >> > > > -- >> > > > ~~~*******'''''''''''''*******~~~ >> > > > *Kasun Gajasinghe* >> > > > Software Engineer; WSO2 Inc.; http://wso2.com, >> > > > *linked-in: *http://lk.linkedin.com/in/gajasinghe >> > > > *blog: **http://blog.kasunbg.org* <http://blog.kasunbg.org/> >> > > > >> > > > >> > > > *twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg> >> > > > >> > > >> > >> > >> > >> > -- >> > ~~~*******'''''''''''''*******~~~ >> > *Kasun Gajasinghe* >> > Software Engineer; WSO2 Inc.; http://wso2.com, >> > *linked-in: *http://lk.linkedin.com/in/gajasinghe >> > *blog: **http://blog.kasunbg.org* <http://blog.kasunbg.org/> >> > >> > >> > *twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg> >> > >>
