well, no - this is actually a real problem that isn't related to being more robust. The point is, we detect that there already is a felix that provided a handler and don't register.
Now, the real fix would be to get a release and have glassfish update to that one. However, that isn't going to help with older versions of glassfish and no matter what would take some time. I have to think about it. One way might be to just swap it out regardless but that might have other side-effects - I'd have to think about it. Feel free to create a new issue as an improvement or something. regards, Karl On Tue, Nov 13, 2012 at 11:07 PM, Raymond Auge <[email protected]>wrote: > Thank you Karl, > > The fix got me further. > > However, I have now encountered a subsequent issue related to the > URLHandlers. which is due to the error which is caught and ignored, we have > not in fact replaced the original handler with a new one, or in fact, even > registered one for the new framework. > > The result is that later during URL handling, the detection of the > framework, which is falling now to the parent (glassfish) version of Felix > using it's own version of > > URLHandlers.getFrameworkFromContext() > > which fails to recognize and load a framework by classloader class called: > > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader* > > When I manipulate the targetClass to assign a class from the stack of the > belonging to the valid classLoader, it works. > > I think the original fix maybe need to be a little more robust. I'll do > what I can to try and solve it myself in the meantime. > > > On Tue, Nov 13, 2012 at 10:51 AM, Karl Pauls <[email protected]> wrote: > > > Thanks. I'm catching the exception now and I resolved the issue. Please > > close it if it works for you, otherwise, reopen :-) > > > > regards, > > > > Karl > > > > > > On Tue, Nov 13, 2012 at 4:39 PM, Raymond Auge <[email protected] > > >wrote: > > > > > Here is the issue https://issues.apache.org/jira/browse/FELIX-3753 > > > > > > Unfortunately I wasn't allowed to assign it. > > > > > > Thank you Karl, > > > - Ray > > > > > > > > > On Mon, Nov 12, 2012 at 5:50 PM, Karl Pauls <[email protected]> > wrote: > > > > > > > On Mon, Nov 12, 2012 at 8:35 PM, Raymond Auge < > > [email protected] > > > > >wrote: > > > > > > > > > Hello All, > > > > > > > > > > Does anyone have a reference or know the details of solving the > > > Protocol > > > > > handler initialization issues when Felix is run embedded (isolated > or > > > > not) > > > > > within an Felix based app server? Of all the app server > combinations > > > > we've > > > > > tested, with both equinox and felix embedded (so far we support > both > > > > > equality well) Felix based Glassfish and Jonas are giving us the > > > problem > > > > > mentioned. > > > > > > > > > > I've looked through the source code and debugged through it. > > Disabling > > > > > protocol initialization (even though it's possible) does not appear > > to > > > > be a > > > > > valid option because then the embedded framework can't even handled > > > > > bundles. > > > > > > > > > > It really just seems like possibly incorrect error handling roughly > > > > around > > > > > lines 176-183 of URLHandlers class. > > > > > The URL.setURLStreamHandlerFactory(currentFactory) invocation > throws > > an > > > > > Error, not an Exception (due to the fact that there is already an > > > factory > > > > > configured), and this throws the entire runtime into self destruct > > > mode. > > > > > > > > > > > > > Yeah, I agree - that looks like a bug. Can you create an issue and > > assign > > > > it to me? I'll fix it asap. > > > > > > > > regards, > > > > > > > > Karl > > > > > > > > > > > > > Thoughts? > > > > > -- > > > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > > > > <http://twitter.com/#!/rotty3000> | Senior Software Architect | > > > > *Liferay, > > > > > Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> > > > > > > > > > > --- > > > > > > > > > > 24-25 October 2012 |* Liferay **Spain Symposium* | > > > > > liferay.com/spain2012<http://www.liferay.com/spain2012> > > > > > > > > > > 16 November 2012 |* Liferay **Italy Symposium* | > > > > > liferay.com/italy2012<http://www.liferay.com/italy2012> > > > > > > > > > > > > > > > > > > > > > -- > > > > Karl Pauls > > > > [email protected] > > > > http://twitter.com/karlpauls > > > > http://www.linkedin.com/in/karlpauls > > > > https://profiles.google.com/karlpauls > > > > > > > > > > > > > > > > -- > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > > <http://twitter.com/#!/rotty3000> | Senior Software Architect | > > *Liferay, > > > Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> > > > > > > --- > > > > > > 24-25 October 2012 |* Liferay **Spain Symposium* | > > > liferay.com/spain2012<http://www.liferay.com/spain2012> > > > > > > 16 November 2012 |* Liferay **Italy Symposium* | > > > liferay.com/italy2012<http://www.liferay.com/italy2012> > > > > > > > > > > > -- > > Karl Pauls > > [email protected] > > http://twitter.com/karlpauls > > http://www.linkedin.com/in/karlpauls > > https://profiles.google.com/karlpauls > > > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, > Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> > > --- > > 24-25 October 2012 |* Liferay **Spain Symposium* | > liferay.com/spain2012<http://www.liferay.com/spain2012> > > 16 November 2012 |* Liferay **Italy Symposium* | > liferay.com/italy2012<http://www.liferay.com/italy2012> > -- Karl Pauls [email protected] http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
