[jira] [Updated] (FELIX-2985) ClassLoading issue involving java.lang.reflect.Proxy in OSGi
[
https://issues.apache.org/jira/browse/FELIX-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall updated FELIX-2985:
---
Fix Version/s: framework-4.0.0
> ClassLoading issue involving java.lang.reflect.Proxy in OSGi
>
>
> Key: FELIX-2985
> URL: https://issues.apache.org/jira/browse/FELIX-2985
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-3.0.8
>Reporter: Sahoo
> Fix For: framework-4.0.0
>
> Attachments: proxy-class-loading.zip
>
>
> I am filing this bug after it was determined in the users forum
> (http://markmail.org/thread/k33oiw3iazfdohj7) that this is a bug that we
> should track. If there already exists a similar issue, we should merge them
> into one. The fix may not necessarily be in our domain though.
> JVM requires us to to import more classes than required to define a Proxy
> class. A simple scenario is shown below:
> module 1:
> package p1;
> public interface A1 extends javax.sql.PooledConnection {
> }
> Export-Package: p1
> Import-Package: javax.sql
> module 2:
> package p2;
> public interface A2 extends javax.naming.Context, p1.A1 {
> }
> Export-Package: p2
> Import-Package: javax.naming, p1
> module 3:
> Bundle-Activator: p3.Activator
> Import-Package: p2, org.osgi.framework
> public class Activator implements BundleActivator {
>public void start(BundleContext ctx) throws Exception {
> for (ClassLoader cl : new ClassLoader[]{getClass().getClassLoader(),
> p2.A2.class.getClassLoader()}) {
> try {
> System.out.println(cl);
> Object obj = Proxy.newProxyInstance(cl, new Class[]{p2.A2.class},
> new InvocationHandler() {
> public Object invoke(Object proxy, Method method,
> Object[] args) throws Throwable {return null;}
> });
> System.out.println(obj);
> } catch(Throwable e) {
> e.printStackTrace();
> }
> } // for
>}
>public void stop(BundleContext ctx) throws Exception {}
> }
> It fails like this:
> 3.0
> java.lang.NoClassDefFoundError: javax.naming.Name not found by m3 [3]
> at $Proxy0.(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:588)
> at p3.Activator.start(Activator.java:11)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1822)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1739)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1143)
> at
> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
> at java.lang.Thread.run(Thread.java:619)
> 2.0
> java.lang.NoClassDefFoundError: javax.sql.StatementEventListener not
> found by m2 [2]
> at $Proxy1.(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:588)
> at p3.Activator.start(Activator.java:11)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1822)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1739)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1143)
> at
> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
> at java.lang.Thread.run(Thread.java:619)
> It seems to me that JVM is assuming that the defining loader of the
> proxy class can load every class that appear in the signature of methods
> that can be invoked using the proxy class. Anybody interested to debug
> can use the attached sample. Just unzip and run run.sh after editing
> path to Felix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: iPOJO vs SCR vs Blueprint
I guess you'd rather have someone write your app as well? :-) The beauty of it all is that you you could actually write your perfect manager and it would work seamlessly with all the others. Kind regards, Peter Kriens On 10 jun 2011, at 22:27, Andrei Pozolotin wrote: > in my experience: > 1) blueprint is a disaster > 2) ipojo is over-kill > 3) ds is under-kill :-) > and yes, I would like to see some features of ipojo in scr > > Original Message > Subject: Re: iPOJO vs SCR vs Blueprint > From: Richard S. Hall > To: dev@felix.apache.org > Date: Wed 08 Jun 2011 08:24:02 AM CDT >> On 6/8/11 9:13, Peter Kriens wrote: >>> The summary for me is that DS is limited to simplifying being a >>> service and depending on other services while iPOJO and Blueprint add >>> a programming language (XML/Annotations) that support services among >>> many, many other features. >>> >>> In my experience DS is the simplest and least intrusive, especially >>> with the SCR or bnd annotations. Blueprint is not my favorite because >>> I consider XML among the worst programming languages one can imagine. >>> I do not have a lot of experience with iPOJO; it is clearly the most >>> powerful but it somehow lacks a compelling reason to switch as none >>> of its additional functions seem worth the effort to switch. >> >> Yeah, who needs things like automatic concurrency handling for >> services or byte-code generated smart service references that >> eliminate the need to turn everything into a component in order to >> pass around services throughout your component? It's better to do all >> that stuff by hand with DS... ;-) >> >> -> richard >> >> p.s. Sorry, I couldn't resist... :-P >> >>> Anyway, who cares. They all interact very nicely and switching from >>> one to the other is not so hard as long as you could in POJOs. >>> >>> Kind regards, >>> >>>Peter Kriens >>> >>> >>> On 30 mei 2011, at 13:25, Felix Meschberger wrote: >>> Hi, Just stating an incompletely informed opinion here .. If you want something simple, light-weight and easy to use, go for Declarative Services. If you want elaborate functionality or need something Declarative Services does not provide, consider iPojo (I understand it is an evolution of Declarative Services, right ?) If you have a Spring background go for blueprint. Regards Felix, whose loves and sticks with Declarative Services ;-) Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan: > On Thu, May 26, 2011 at 6:02 AM, Alasdair > Nottingham wrote: > >> >> Alasdair Nottingham >> >> On 25 May 2011, at 22:16, "Richard S. Hall" >> wrote: >> >>> On 5/25/11 16:26, Alasdair Nottingham wrote: Hi, This is good I might link to it, or pinch it for the aries webpage too if that is ok. When doing that thought I would put some changes into the blueprint column. The Aries blueprint implementation provides some value add that would change some of the No's into Yes's. >>> Sure. >>> One thing though in component lifecycle control you have a Partial down for blueprint I was wondering what you meant by this. >>> I'd have to review the chapter, I don't really claim to be any >>> Blueprint >> expert...other than knowing it sucks... ;-) >> >> Of course if you were an expert you would know how much better it >> is than >> anything else ;) let the religious flame war begin, or not. >> > In fact, casual users wish for an almighty expert who knows all > solutions > in-depth and exposes them to all. > > If there's no such expert, the second best method is, experts of > different > solutions advertise themself and compare with each other. > > Maybe that can be called religious flame war, but it's valuable. > What we > really need in open community is simple and perfect product in > technology, > but not many repeat manufacturing wheels like some outside companies. > > Regards, > drhades > >>> -> richard >>> Thanks Alasdair On 25 May 2011 15:29, Richard S. Hall wrote: > On 5/25/11 9:19, Richard S. Hall wrote: >> We actually have a table in our book (OSGi in Action) that >> tries to >> compare the features...perhaps I could re-create that table on >> a web >> page... > Ok, I added the table to the iPOJO FAQ on wiki: > > > >> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F >> > It's not perfect, but it is better than nothing. It should > eventually > propagate to our static pages. > >>>
[jira] [Resolved] (FELIX-2995) The service properties are updated despite there is no changes
[ https://issues.apache.org/jira/browse/FELIX-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-2995. -- Resolution: Fixed Fixed in trunk > The service properties are updated despite there is no changes > -- > > Key: FELIX-2995 > URL: https://issues.apache.org/jira/browse/FELIX-2995 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: ipojo-core-1.8.2 > > > The service registration is updated with new properties despite there is no > real changes in the properties to publish. We need to take care that the > properties have changed before triggering the update. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2995) The service properties are updated despite there is no changes
The service properties are updated despite there is no changes -- Key: FELIX-2995 URL: https://issues.apache.org/jira/browse/FELIX-2995 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.8.0 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-core-1.8.2 The service registration is updated with new properties despite there is no real changes in the properties to publish. We need to take care that the properties have changed before triggering the update. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
