You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Remo Liechti <re...@swisslog.com> on 2016/08/17 13:58:39 UTC
Classcast when accessing services, different classloader issue?
Hi guys
I use weblogic that ships felix to wrap osgi applications in a j2ee webapplication.
An example application I found (http://buttso.blogspot.ch/2013/09/weblogic-server-using-osgi-bundles-with.html) works well, I can access a deployed service.
What they do, is quite normal:
@Resource(lookup = "java:app/osgi/Bundle")
Bundle bundle;
BundleContext bc = bundle.getBundleContext();
ServiceReference dictionaryServiceRef =
bc.getServiceReference(DictionaryService.class);
DictionaryService dictionaryService =
(DictionaryService) bc.getService(dictionaryServiceRef);
However, when I do this within my wrapped osgi application:
activatorBundle.getBundleContext().getService(
activatorBundle.getBundleContext().getServiceReference(IExtendedTaskManager.class)
)
I do get a get a (com.kuka.task.osgi.TaskManagerComponent) com.kuka.task.osgi.TaskManagerComponent@1575e8f).
So far, all perfectly fine. The TaskManagerComponent implements the IExtendedTaskManager.
Now, things start to get odd. I now want to cast this to a TaskManagerComponent so that I can start using the methods on it. When I do this, I get:
ClassCastException: Cannot cast com.kuka.task.osgi.TaskManagerComponent (id=434) to com.kuka.task.osgi.TaskManagerComponent
Since the classnames are identical, I assume to run into a classloader issue.
My guess is: My Servlet runs in a weblogic web classloader and the osgi stuff runs in a felix classloader. How can I resolve this issue?
The TaskManagerComponent is in one jar only, which is deployed with the wrapper osgi application and the servlet uses the same jar file.
Thanks,
Remo
This message may contain legally privileged or confidential information and is therefore addressed to the named persons only. The recipient should inform the sender and delete this message, if he/she is not named as addressee. The sender disclaims any and all liability for the integrity and punctuality of this message. The sender has activated an automatic virus scanning, but does not guarantee the virus free transmission of this message.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Classcast when accessing services, different classloader issue?
Posted by Remo Liechti <re...@swisslog.com>.
In my main bundle activator I had to re-register the services:
ref = context.getServiceReference(IResourceManager.class);
if (ref != null) {
IResourceManager service = (IResourceManager) context.getService(ref);
context.registerService(IResourceManager.class.getName(),service,new Hashtable<String, Object>());
}
I guess like this I create a bridge between WebApp classloader of weblogic to felix main classloader that then redirects to the specific bundles classloader.
Any better way?
-----Original Message-----
From: Remo Liechti [mailto:remo.liechti@swisslog.com]
Sent: Mittwoch, 17. August 2016 15:59
To: users@felix.apache.org
Subject: Classcast when accessing services, different classloader issue?
Hi guys
I use weblogic that ships felix to wrap osgi applications in a j2ee webapplication.
An example application I found (http://buttso.blogspot.ch/2013/09/weblogic-server-using-osgi-bundles-with.html) works well, I can access a deployed service.
What they do, is quite normal:
@Resource(lookup = "java:app/osgi/Bundle") Bundle bundle;
BundleContext bc = bundle.getBundleContext(); ServiceReference dictionaryServiceRef =
bc.getServiceReference(DictionaryService.class);
DictionaryService dictionaryService =
(DictionaryService) bc.getService(dictionaryServiceRef);
However, when I do this within my wrapped osgi application:
activatorBundle.getBundleContext().getService(
activatorBundle.getBundleContext().getServiceReference(IExtendedTaskManager.class)
)
I do get a get a (com.kuka.task.osgi.TaskManagerComponent) com.kuka.task.osgi.TaskManagerComponent@1575e8f).
So far, all perfectly fine. The TaskManagerComponent implements the IExtendedTaskManager.
Now, things start to get odd. I now want to cast this to a TaskManagerComponent so that I can start using the methods on it. When I do this, I get:
ClassCastException: Cannot cast com.kuka.task.osgi.TaskManagerComponent (id=434) to com.kuka.task.osgi.TaskManagerComponent
Since the classnames are identical, I assume to run into a classloader issue.
My guess is: My Servlet runs in a weblogic web classloader and the osgi stuff runs in a felix classloader. How can I resolve this issue?
The TaskManagerComponent is in one jar only, which is deployed with the wrapper osgi application and the servlet uses the same jar file.
Thanks,
Remo
This message may contain legally privileged or confidential information and is therefore addressed to the named persons only. The recipient should inform the sender and delete this message, if he/she is not named as addressee. The sender disclaims any and all liability for the integrity and punctuality of this message. The sender has activated an automatic virus scanning, but does not guarantee the virus free transmission of this message.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
This message may contain legally privileged or confidential information and is therefore addressed to the named persons only. The recipient should inform the sender and delete this message, if he/she is not named as addressee. The sender disclaims any and all liability for the integrity and punctuality of this message. The sender has activated an automatic virus scanning, but does not guarantee the virus free transmission of this message.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org