On 10/26/12 09:21 , Raymond Auge wrote:
On Fri, Oct 26, 2012 at 8:52 AM, Felix Meschberger <fmesc...@adobe.com>wrote:
Hi,
Am 25.10.2012 um 17:15 schrieb Raymond Auge:
Hello All,
I'd like to bump this issue as it appears to be a problem not only with
Felix, but also with Equinox and I'd like to clarify the issue.
It appears that even though an OSGi framework can be embedded, it does
not
appear there is any protection from the case where it is embedded within
another OSGi container.
For instance, while Miguel has highlighted the issue down to a very
specific error, the problem just seems to be that an embedded framework
sees, and loads the extension bundles deployed to a higher level
container,
at least it does if the developer does not use very strict classloader
isolation such as themselves delegating to an isolated container.
We can certainly do that (and as of right now it looks like we have no
choice).
However, it wouldn't be a terribly difficult problem to solve.
I'd like to propose that a small feature be added which allows for the
extension mechanism to be defined as:
a) using a specific classpath (as a property, from which we could create
a
URLClassLoader)
b) pass an actual ClassLoader object during init as part of the
configuration map associated with a extension loader property.
In both cases (which would not be the default of course), the classLoader
in question would be used to load framework extensions.
That's exactly what we do in the Sling Launchpad Base module to
encapsulate the framework from the environment (our experience is deploying
the Sling's OSGi framework as a web application in an OSGi-based servlet
container).
Right, and we've created such a wrapper to work around the current issue
ourselves.
However, I'm just wondering if the intention of the Framework API was to
allow for this type of isolation (at least in theory)? And if so, perhaps
we could accommodate for it directly without having to write this extra
code.
No, the Framework API was not intended to address the case where you
embed frameworks inside of frameworks. It was explicitly NOT covering
that aspect of embedding. It is purely a launching and embedding [in
host] API, where the latter is purely a subset of the former...really it
just treats the host application as the framework launcher.
-> richard
The problem caused by such a wrapper, is that we can no longer directly
access the OSGI apis from within the current application (which is
emmbedding the framework). We'll end up having to front the APIs we want to
access using a reflection layer which is very sad.
Thank you for thoughts,
- Ray
Regards
Felix
If we (Miguel and I) implemented this, would it be acceptable/considered?
Note, that I will be proposing the same concept to the equinox project
and
making a similar offer to implement the addition.
Sincerely,
- Ray
On Tue, Oct 2, 2012 at 5:28 AM, Miguel Angel Pastor Olivar <
miguelinl...@gmail.com> wrote:
Karl,
I have created this ticket:
https://issues.apache.org/jira/browse/FELIX-3696
Let me know if I can help in some way.
Thx!!
On 2 October 2012 10:05, Karl Pauls <karlpa...@gmail.com> wrote:
On Tue, Oct 2, 2012 at 9:47 AM, Miguel Angel Pastor Olivar
<miguelinl...@gmail.com> wrote:
Ok,
First of all sorry for not being too explicit. I will try to give some
more
details:
- I am embedding Apache Felix (and Equinox because I would like to
switch depending on the application server I am running on).
-
- The xalan ExtensionHandler executes something like this:
ObjectFactory.findProviderClass(className,
ObjectFactory.findClassLoader(), true)
- The className has the format "java:....PortletBridge" ( I am
embedding
the OSGI container into Liferay portal :) )
- The extension manager have already added the extension loader to
the
classloader
Felix.m_secureAction.addURLToURLClassLoader(Felix.m_secureAction.createURL(Felix.m_secureAction.createURL(null,
"http:", extensionManager),"http://felix.extensions:9/";,
extensionManager),
Felix.class.getClassLoader());
- When resolving the "java:xxxxxx....PortletBridge" the previous
loader
added by the ExtensionManager cause an unhandled error.
Well, it shouldn't do that I guess - maybe you could create a jira
issue as a bug report against the framework and give me some more
information like stack trace of the error etc. and I can see whether
we can fix that.
In addition; when trying to embed the container inside JBoss 7+ the
extension manager fails to load because it is not being loaded by an
instance of the URLClassloader (it is not really a problem)
Yeah, that makes sense and is working as designed. If we can't add
ourself to a urlclassloader we just don't provide extension bundle
support but should continue to work correctly.
As I have said in the previous mail, isolating the the framework into
its
own classloader is working but it is trickier.
If you don't need extension bundle support you shouldn't have to do
that then. Your real problems seems to be a bug in the extension
manager that prevents it from working with your third-party library
even so it likely should. Please create a bug report and lets try to
fix the bug.
regards,
Karl
So this was the reason of asking you guys!
Thx a lot!
On 2 October 2012 09:20, Karl Pauls <karlpa...@gmail.com> wrote:
I am using Apache Felix as the internal OSGI container inside a
webapp.
The
extension bundle manager adds the extension loader to the
classloader
which
is causing me many headaches because some thirty-part libraries.
What is the problem exactly? If you don't have any extension bundles,
why would this cause problems (let alone with third-party libs)?
My first solution was to isolate the embedded container into its own
classloader but I think this approach adds too much complexity.
Should be possible to make the Extension Bundle manager to be
configurable?
I mean, disabling it could cause some other problems to the
framework?
Again, it might help if you let us know what your problem is with it
in the first place. That said, I'm not against adding a switch to
disable it but it is somewhat tricky....
regards,
Karl
Cheers,
Migue
--
Un saludo,
Migue
http://migue.github.com
--
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
--
Un saludo,
Migue
http://migue.github.com
--
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
--
Un saludo,
Migue
http://migue.github.com
--
*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>
