You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2011/06/03 08:53:20 UTC
Yet another proxy/weaving problem
another day another problem....
org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : Name:null, WebBeans Type:DECORATOR, API Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate attribute must implement all of the decorator decorated types, but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not assignable from delegate type of interface org.jboss.jsr299.tck.tests.context.dependent.Interior
I believe the story here is that decorator classes must not implement interfaces that the delegate doesn't implement, but aries is adding the org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
OWB is already excluding Serializable and I can modify the code to also exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is going to involve making the list of ignored interfaces configurable and may not be acceptable to OWB.
Is there any way to make the weaving/proxying code not add this interface? I don't think the jdk proxying code needs to add interfaces....
thanks
david jencks
Re: OWB with Java 1.5 and Servlet 2.4
Posted by Gerhard Petracek <ge...@gmail.com>.
hi mark,
i know (if you mean OpenWebBeansPlugin) - we don't need that one here.
i had the PropertyLoader in mind.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/6/8 Mark Struberg <st...@yahoo.de>
> problem is that our plugin concept is currently based on
> java.util.ServiceLoader :)
>
> This is somehow similar to David Jencks initial ConfigService problem I
> think.
>
> LieGrue,
> strub
>
> --- On Wed, 6/8/11, Gerhard Petracek <ge...@gmail.com> wrote:
>
> > From: Gerhard Petracek <ge...@gmail.com>
> > Subject: Re: OWB with Java 1.5 and Servlet 2.4
> > To: dev@openwebbeans.apache.org
> > Date: Wednesday, June 8, 2011, 1:05 PM
> > hi udo,
> >
> > #2-#4 are ok for me.
> > +1 for #3
> >
> > we have a plug-in concept (which is great) and we shouldn't
> > start with
> > introducing exceptions. we can host such a plug-in for java
> > 1.5 at
> > apache-extras and we can release it in an apache-extras
> > maven
> > repository.
> >
> > furthermore, most google code projects don't have a maven
> > repository
> > and we would have source-code which isn't testable because
> > the
> > ci-server wouldn't find the dependency and users have to
> > check out the
> > external project and have to build it manually. moreover,
> > if the
> > repository disappears, we also have a problem.
> >
> > regards,
> > gerhard
> >
> > 2011/6/8, Udo Schnurpfeil <ud...@schnurpfeil.de>:
> > > I like a solution, when the same artifact (of app or
> > lib) will work in
> > > both environments.
> > >
> > > Regards,
> > >
> > > Udo
> > >
> > >
> > > Am 08.06.11 13:28, schrieb Arne Limburg:
> > >> +1 for the Java-5-Webbeans-Plugin
> > >> --
> > >>
> > >> Arne Limburg - Enterprise Developer
> > >> open knowledge GmbH, Oldenburg
> > >> Bismarckstraße 13, 26122 Oldenburg
> > >> Mobil: +49 (0) 151 108 22 942
> > >> Tel: +49 (0) 441 - 4082-0
> > >> Fax: +49 (0) 441 - 4082-111
> > >> arne.limburg@openknowledge.de
> > >> http://www.openknowledge.de
> > >>
> > >> Registergericht: Amtsgericht Oldenburg, HRB 4670
> > >> Geschäftsführer: Lars Röwekamp, Jens Schumann
> > >> ________________________________________
> > >> Von: Udo Schnurpfeil [udo@schnurpfeil.de]
> > >> Gesendet: Mittwoch, 8. Juni 2011 13:23
> > >> An: dev@openwebbeans.apache.org
> > >> Betreff: Re: OWB with Java 1.5 and Servlet 2.4
> > >>
> > >> Hi Gerhard,
> > >>
> > >> I don't know what the problem is, with the direct
> > dependency. I've
> > >> marked it as optional in the pom.xml. A Java 1.6
> > application will run
> > >> without changes (and not having googlecode in the
> > jar). But I can
> > >> understand, that there are reasons on principal to
> > have no dependencies
> > >> to other project.
> > >>
> > >> Did I understand you correctly in your first
> > solution approach?
> > >> Compile the Sources of java.util.ServiceLoader
> > with Java 1.5 and put it
> > >> into a single JAR File.
> > >> This might be also not very nice, as a general
> > solution: OWB works with
> > >> Java 1.5, when you compile some JDK classes.
> > >>
> > >> Sadly I don't know the plugin mechanism of OWB, so
> > I can't write an easy
> > >> patch for that solution.
> > >>
> > >> An other solution might be implementing a
> > >> org.apache.webbeans.util.ServiceLoader and using
> > this instead of the
> > >> com.googlecode one. This might be the cleanest
> > solution.
> > >>
> > >> So we have 4 possibilities:
> > >> 1) googlecode
> > >> 2) jdk 1.6 code self
> > compiled in the project
> > >> 3) plugin
> > >> 4) writing own
> > service-loader
> > >>
> > >> Regards,
> > >>
> > >> Udo
> > >>
> > >>
> > >> Am 08.06.11 11:25, schrieb Gerhard Petracek:
> > >>> hi udo,
> > >>>
> > >>> @OWB-582:
> > >>> using com.googlecode.* directly in owb is imo
> > no good idea.
> > >>> since the service-loader isn't available in a
> > java 1.5 environment,
> > >>> you can repackage the service-loader in your
> > project. so we don't have
> > >>> to change owb itself - you just have an
> > additional jar in your
> > >>> project. if there is any issue with such an
> > approach, we could create
> > >>> an owb-plugin for it and you write your own
> > plugin-implementation.
> > >>>
> > >>> @OWB-583:
> > >>> looks fine to me (just had a quick look).
> > >>>
> > >>> regards,
> > >>> gerhard
> > >>>
> > >>> 2011/6/8, Udo Schnurpfeil<ud...@schnurpfeil.de>:
> > >>>> Hi,
> > >>>>
> > >>>> I would like to use OWB on WebSphere 6.1
> > (similar to Tomcat 5.5) which
> > >>>> requires Java 1.5 and supports Servlet API
> > 2.4.
> > >>>> OWB needs Java 1.6 and Servlet API 2.5.
> > >>>>
> > >>>> Part 1: Java 1.6
> > >>>>
> > >>>> After a close look into the sources I see,
> > there is one basic dependency
> > >>>> to Java 1.6: java.util.ServiceLoader
> > >>>> To solve this problem, I've added a
> > utility class in my local copy and
> > >>>> delegate calls to ServiceLoader to this
> > utility.
> > >>>>
> > >>>> The utility class itself calls
> > ServiceLoader, if the class is available
> > >>>> (Java 1.6) or uses
> > com.googlecode.bspi.ServiceLoader (Java 1.5).
> > >>>> So the application needs one new
> > dependency (only in the case of Java
> > >>>> 1.5).
> > >>>>
> > >>>> I've also changed the
> > maven-compiler-plugin to generate Java 1.5
> > >>>> compatible byte code.
> > >>>>
> > >>>> Jira: https://issues.apache.org/jira/browse/OWB-582
> > >>>>
> > >>>> Part 2: Servet API 2.5
> > >>>>
> > >>>> Some classes uses the new function
> > ServletContext.getContextPath() for
> > >>>> logging and giving a thread a useful
> > name.
> > >>>>
> > >>>> Here, I also added a utility class, and
> > call
> > >>>> servletContext.getServletContextName() in
> > the case of Servlet API 2.4
> > >>>>
> > >>>> Jira: https://issues.apache.org/jira/browse/OWB-583
> > >>>>
> > >>>> Conclusion:
> > >>>>
> > >>>> There are not many dependencies to the new
> > APIs and there are simple
> > >>>> workarounds. With this changes (and a
> > similar patch for the
> > >>>> ServiceLoader in CODI) I'm able to run OWB
> > on WebSpere 6.1 and Tomcat
> > >>>> 5.5 with Java 1.5.
> > >>>>
> > >>>> Any suggestions?
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>> Udo
> > >>>>
> > >>>>
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
Re: OWB with Java 1.5 and Servlet 2.4
Posted by Mark Struberg <st...@yahoo.de>.
problem is that our plugin concept is currently based on java.util.ServiceLoader :)
This is somehow similar to David Jencks initial ConfigService problem I think.
LieGrue,
strub
--- On Wed, 6/8/11, Gerhard Petracek <ge...@gmail.com> wrote:
> From: Gerhard Petracek <ge...@gmail.com>
> Subject: Re: OWB with Java 1.5 and Servlet 2.4
> To: dev@openwebbeans.apache.org
> Date: Wednesday, June 8, 2011, 1:05 PM
> hi udo,
>
> #2-#4 are ok for me.
> +1 for #3
>
> we have a plug-in concept (which is great) and we shouldn't
> start with
> introducing exceptions. we can host such a plug-in for java
> 1.5 at
> apache-extras and we can release it in an apache-extras
> maven
> repository.
>
> furthermore, most google code projects don't have a maven
> repository
> and we would have source-code which isn't testable because
> the
> ci-server wouldn't find the dependency and users have to
> check out the
> external project and have to build it manually. moreover,
> if the
> repository disappears, we also have a problem.
>
> regards,
> gerhard
>
> 2011/6/8, Udo Schnurpfeil <ud...@schnurpfeil.de>:
> > I like a solution, when the same artifact (of app or
> lib) will work in
> > both environments.
> >
> > Regards,
> >
> > Udo
> >
> >
> > Am 08.06.11 13:28, schrieb Arne Limburg:
> >> +1 for the Java-5-Webbeans-Plugin
> >> --
> >>
> >> Arne Limburg - Enterprise Developer
> >> open knowledge GmbH, Oldenburg
> >> Bismarckstraße 13, 26122 Oldenburg
> >> Mobil: +49 (0) 151 108 22 942
> >> Tel: +49 (0) 441 - 4082-0
> >> Fax: +49 (0) 441 - 4082-111
> >> arne.limburg@openknowledge.de
> >> http://www.openknowledge.de
> >>
> >> Registergericht: Amtsgericht Oldenburg, HRB 4670
> >> Geschäftsführer: Lars Röwekamp, Jens Schumann
> >> ________________________________________
> >> Von: Udo Schnurpfeil [udo@schnurpfeil.de]
> >> Gesendet: Mittwoch, 8. Juni 2011 13:23
> >> An: dev@openwebbeans.apache.org
> >> Betreff: Re: OWB with Java 1.5 and Servlet 2.4
> >>
> >> Hi Gerhard,
> >>
> >> I don't know what the problem is, with the direct
> dependency. I've
> >> marked it as optional in the pom.xml. A Java 1.6
> application will run
> >> without changes (and not having googlecode in the
> jar). But I can
> >> understand, that there are reasons on principal to
> have no dependencies
> >> to other project.
> >>
> >> Did I understand you correctly in your first
> solution approach?
> >> Compile the Sources of java.util.ServiceLoader
> with Java 1.5 and put it
> >> into a single JAR File.
> >> This might be also not very nice, as a general
> solution: OWB works with
> >> Java 1.5, when you compile some JDK classes.
> >>
> >> Sadly I don't know the plugin mechanism of OWB, so
> I can't write an easy
> >> patch for that solution.
> >>
> >> An other solution might be implementing a
> >> org.apache.webbeans.util.ServiceLoader and using
> this instead of the
> >> com.googlecode one. This might be the cleanest
> solution.
> >>
> >> So we have 4 possibilities:
> >> 1) googlecode
> >> 2) jdk 1.6 code self
> compiled in the project
> >> 3) plugin
> >> 4) writing own
> service-loader
> >>
> >> Regards,
> >>
> >> Udo
> >>
> >>
> >> Am 08.06.11 11:25, schrieb Gerhard Petracek:
> >>> hi udo,
> >>>
> >>> @OWB-582:
> >>> using com.googlecode.* directly in owb is imo
> no good idea.
> >>> since the service-loader isn't available in a
> java 1.5 environment,
> >>> you can repackage the service-loader in your
> project. so we don't have
> >>> to change owb itself - you just have an
> additional jar in your
> >>> project. if there is any issue with such an
> approach, we could create
> >>> an owb-plugin for it and you write your own
> plugin-implementation.
> >>>
> >>> @OWB-583:
> >>> looks fine to me (just had a quick look).
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>> 2011/6/8, Udo Schnurpfeil<ud...@schnurpfeil.de>:
> >>>> Hi,
> >>>>
> >>>> I would like to use OWB on WebSphere 6.1
> (similar to Tomcat 5.5) which
> >>>> requires Java 1.5 and supports Servlet API
> 2.4.
> >>>> OWB needs Java 1.6 and Servlet API 2.5.
> >>>>
> >>>> Part 1: Java 1.6
> >>>>
> >>>> After a close look into the sources I see,
> there is one basic dependency
> >>>> to Java 1.6: java.util.ServiceLoader
> >>>> To solve this problem, I've added a
> utility class in my local copy and
> >>>> delegate calls to ServiceLoader to this
> utility.
> >>>>
> >>>> The utility class itself calls
> ServiceLoader, if the class is available
> >>>> (Java 1.6) or uses
> com.googlecode.bspi.ServiceLoader (Java 1.5).
> >>>> So the application needs one new
> dependency (only in the case of Java
> >>>> 1.5).
> >>>>
> >>>> I've also changed the
> maven-compiler-plugin to generate Java 1.5
> >>>> compatible byte code.
> >>>>
> >>>> Jira: https://issues.apache.org/jira/browse/OWB-582
> >>>>
> >>>> Part 2: Servet API 2.5
> >>>>
> >>>> Some classes uses the new function
> ServletContext.getContextPath() for
> >>>> logging and giving a thread a useful
> name.
> >>>>
> >>>> Here, I also added a utility class, and
> call
> >>>> servletContext.getServletContextName() in
> the case of Servlet API 2.4
> >>>>
> >>>> Jira: https://issues.apache.org/jira/browse/OWB-583
> >>>>
> >>>> Conclusion:
> >>>>
> >>>> There are not many dependencies to the new
> APIs and there are simple
> >>>> workarounds. With this changes (and a
> similar patch for the
> >>>> ServiceLoader in CODI) I'm able to run OWB
> on WebSpere 6.1 and Tomcat
> >>>> 5.5 with Java 1.5.
> >>>>
> >>>> Any suggestions?
> >>>>
> >>>> Regards,
> >>>>
> >>>> Udo
> >>>>
> >>>>
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: OWB with Java 1.5 and Servlet 2.4
Posted by Gerhard Petracek <ge...@gmail.com>.
hi udo,
#2-#4 are ok for me.
+1 for #3
we have a plug-in concept (which is great) and we shouldn't start with
introducing exceptions. we can host such a plug-in for java 1.5 at
apache-extras and we can release it in an apache-extras maven
repository.
furthermore, most google code projects don't have a maven repository
and we would have source-code which isn't testable because the
ci-server wouldn't find the dependency and users have to check out the
external project and have to build it manually. moreover, if the
repository disappears, we also have a problem.
regards,
gerhard
2011/6/8, Udo Schnurpfeil <ud...@schnurpfeil.de>:
> I like a solution, when the same artifact (of app or lib) will work in
> both environments.
>
> Regards,
>
> Udo
>
>
> Am 08.06.11 13:28, schrieb Arne Limburg:
>> +1 for the Java-5-Webbeans-Plugin
>> --
>>
>> Arne Limburg - Enterprise Developer
>> open knowledge GmbH, Oldenburg
>> Bismarckstraße 13, 26122 Oldenburg
>> Mobil: +49 (0) 151 108 22 942
>> Tel: +49 (0) 441 - 4082-0
>> Fax: +49 (0) 441 - 4082-111
>> arne.limburg@openknowledge.de
>> http://www.openknowledge.de
>>
>> Registergericht: Amtsgericht Oldenburg, HRB 4670
>> Geschäftsführer: Lars Röwekamp, Jens Schumann
>> ________________________________________
>> Von: Udo Schnurpfeil [udo@schnurpfeil.de]
>> Gesendet: Mittwoch, 8. Juni 2011 13:23
>> An: dev@openwebbeans.apache.org
>> Betreff: Re: OWB with Java 1.5 and Servlet 2.4
>>
>> Hi Gerhard,
>>
>> I don't know what the problem is, with the direct dependency. I've
>> marked it as optional in the pom.xml. A Java 1.6 application will run
>> without changes (and not having googlecode in the jar). But I can
>> understand, that there are reasons on principal to have no dependencies
>> to other project.
>>
>> Did I understand you correctly in your first solution approach?
>> Compile the Sources of java.util.ServiceLoader with Java 1.5 and put it
>> into a single JAR File.
>> This might be also not very nice, as a general solution: OWB works with
>> Java 1.5, when you compile some JDK classes.
>>
>> Sadly I don't know the plugin mechanism of OWB, so I can't write an easy
>> patch for that solution.
>>
>> An other solution might be implementing a
>> org.apache.webbeans.util.ServiceLoader and using this instead of the
>> com.googlecode one. This might be the cleanest solution.
>>
>> So we have 4 possibilities:
>> 1) googlecode
>> 2) jdk 1.6 code self compiled in the project
>> 3) plugin
>> 4) writing own service-loader
>>
>> Regards,
>>
>> Udo
>>
>>
>> Am 08.06.11 11:25, schrieb Gerhard Petracek:
>>> hi udo,
>>>
>>> @OWB-582:
>>> using com.googlecode.* directly in owb is imo no good idea.
>>> since the service-loader isn't available in a java 1.5 environment,
>>> you can repackage the service-loader in your project. so we don't have
>>> to change owb itself - you just have an additional jar in your
>>> project. if there is any issue with such an approach, we could create
>>> an owb-plugin for it and you write your own plugin-implementation.
>>>
>>> @OWB-583:
>>> looks fine to me (just had a quick look).
>>>
>>> regards,
>>> gerhard
>>>
>>> 2011/6/8, Udo Schnurpfeil<ud...@schnurpfeil.de>:
>>>> Hi,
>>>>
>>>> I would like to use OWB on WebSphere 6.1 (similar to Tomcat 5.5) which
>>>> requires Java 1.5 and supports Servlet API 2.4.
>>>> OWB needs Java 1.6 and Servlet API 2.5.
>>>>
>>>> Part 1: Java 1.6
>>>>
>>>> After a close look into the sources I see, there is one basic dependency
>>>> to Java 1.6: java.util.ServiceLoader
>>>> To solve this problem, I've added a utility class in my local copy and
>>>> delegate calls to ServiceLoader to this utility.
>>>>
>>>> The utility class itself calls ServiceLoader, if the class is available
>>>> (Java 1.6) or uses com.googlecode.bspi.ServiceLoader (Java 1.5).
>>>> So the application needs one new dependency (only in the case of Java
>>>> 1.5).
>>>>
>>>> I've also changed the maven-compiler-plugin to generate Java 1.5
>>>> compatible byte code.
>>>>
>>>> Jira: https://issues.apache.org/jira/browse/OWB-582
>>>>
>>>> Part 2: Servet API 2.5
>>>>
>>>> Some classes uses the new function ServletContext.getContextPath() for
>>>> logging and giving a thread a useful name.
>>>>
>>>> Here, I also added a utility class, and call
>>>> servletContext.getServletContextName() in the case of Servlet API 2.4
>>>>
>>>> Jira: https://issues.apache.org/jira/browse/OWB-583
>>>>
>>>> Conclusion:
>>>>
>>>> There are not many dependencies to the new APIs and there are simple
>>>> workarounds. With this changes (and a similar patch for the
>>>> ServiceLoader in CODI) I'm able to run OWB on WebSpere 6.1 and Tomcat
>>>> 5.5 with Java 1.5.
>>>>
>>>> Any suggestions?
>>>>
>>>> Regards,
>>>>
>>>> Udo
>>>>
>>>>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: OWB with Java 1.5 and Servlet 2.4
Posted by Udo Schnurpfeil <ud...@schnurpfeil.de>.
I like a solution, when the same artifact (of app or lib) will work in
both environments.
Regards,
Udo
Am 08.06.11 13:28, schrieb Arne Limburg:
> +1 for the Java-5-Webbeans-Plugin
> --
>
> Arne Limburg - Enterprise Developer
> open knowledge GmbH, Oldenburg
> Bismarckstraße 13, 26122 Oldenburg
> Mobil: +49 (0) 151 108 22 942
> Tel: +49 (0) 441 - 4082-0
> Fax: +49 (0) 441 - 4082-111
> arne.limburg@openknowledge.de
> http://www.openknowledge.de
>
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
> ________________________________________
> Von: Udo Schnurpfeil [udo@schnurpfeil.de]
> Gesendet: Mittwoch, 8. Juni 2011 13:23
> An: dev@openwebbeans.apache.org
> Betreff: Re: OWB with Java 1.5 and Servlet 2.4
>
> Hi Gerhard,
>
> I don't know what the problem is, with the direct dependency. I've
> marked it as optional in the pom.xml. A Java 1.6 application will run
> without changes (and not having googlecode in the jar). But I can
> understand, that there are reasons on principal to have no dependencies
> to other project.
>
> Did I understand you correctly in your first solution approach?
> Compile the Sources of java.util.ServiceLoader with Java 1.5 and put it
> into a single JAR File.
> This might be also not very nice, as a general solution: OWB works with
> Java 1.5, when you compile some JDK classes.
>
> Sadly I don't know the plugin mechanism of OWB, so I can't write an easy
> patch for that solution.
>
> An other solution might be implementing a
> org.apache.webbeans.util.ServiceLoader and using this instead of the
> com.googlecode one. This might be the cleanest solution.
>
> So we have 4 possibilities:
> 1) googlecode
> 2) jdk 1.6 code self compiled in the project
> 3) plugin
> 4) writing own service-loader
>
> Regards,
>
> Udo
>
>
> Am 08.06.11 11:25, schrieb Gerhard Petracek:
>> hi udo,
>>
>> @OWB-582:
>> using com.googlecode.* directly in owb is imo no good idea.
>> since the service-loader isn't available in a java 1.5 environment,
>> you can repackage the service-loader in your project. so we don't have
>> to change owb itself - you just have an additional jar in your
>> project. if there is any issue with such an approach, we could create
>> an owb-plugin for it and you write your own plugin-implementation.
>>
>> @OWB-583:
>> looks fine to me (just had a quick look).
>>
>> regards,
>> gerhard
>>
>> 2011/6/8, Udo Schnurpfeil<ud...@schnurpfeil.de>:
>>> Hi,
>>>
>>> I would like to use OWB on WebSphere 6.1 (similar to Tomcat 5.5) which
>>> requires Java 1.5 and supports Servlet API 2.4.
>>> OWB needs Java 1.6 and Servlet API 2.5.
>>>
>>> Part 1: Java 1.6
>>>
>>> After a close look into the sources I see, there is one basic dependency
>>> to Java 1.6: java.util.ServiceLoader
>>> To solve this problem, I've added a utility class in my local copy and
>>> delegate calls to ServiceLoader to this utility.
>>>
>>> The utility class itself calls ServiceLoader, if the class is available
>>> (Java 1.6) or uses com.googlecode.bspi.ServiceLoader (Java 1.5).
>>> So the application needs one new dependency (only in the case of Java 1.5).
>>>
>>> I've also changed the maven-compiler-plugin to generate Java 1.5
>>> compatible byte code.
>>>
>>> Jira: https://issues.apache.org/jira/browse/OWB-582
>>>
>>> Part 2: Servet API 2.5
>>>
>>> Some classes uses the new function ServletContext.getContextPath() for
>>> logging and giving a thread a useful name.
>>>
>>> Here, I also added a utility class, and call
>>> servletContext.getServletContextName() in the case of Servlet API 2.4
>>>
>>> Jira: https://issues.apache.org/jira/browse/OWB-583
>>>
>>> Conclusion:
>>>
>>> There are not many dependencies to the new APIs and there are simple
>>> workarounds. With this changes (and a similar patch for the
>>> ServiceLoader in CODI) I'm able to run OWB on WebSpere 6.1 and Tomcat
>>> 5.5 with Java 1.5.
>>>
>>> Any suggestions?
>>>
>>> Regards,
>>>
>>> Udo
>>>
>>>
AW: OWB with Java 1.5 and Servlet 2.4
Posted by Arne Limburg <ar...@openknowledge.de>.
+1 for the Java-5-Webbeans-Plugin
--
Arne Limburg - Enterprise Developer
open knowledge GmbH, Oldenburg
Bismarckstraße 13, 26122 Oldenburg
Mobil: +49 (0) 151 108 22 942
Tel: +49 (0) 441 - 4082-0
Fax: +49 (0) 441 - 4082-111
arne.limburg@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
________________________________________
Von: Udo Schnurpfeil [udo@schnurpfeil.de]
Gesendet: Mittwoch, 8. Juni 2011 13:23
An: dev@openwebbeans.apache.org
Betreff: Re: OWB with Java 1.5 and Servlet 2.4
Hi Gerhard,
I don't know what the problem is, with the direct dependency. I've
marked it as optional in the pom.xml. A Java 1.6 application will run
without changes (and not having googlecode in the jar). But I can
understand, that there are reasons on principal to have no dependencies
to other project.
Did I understand you correctly in your first solution approach?
Compile the Sources of java.util.ServiceLoader with Java 1.5 and put it
into a single JAR File.
This might be also not very nice, as a general solution: OWB works with
Java 1.5, when you compile some JDK classes.
Sadly I don't know the plugin mechanism of OWB, so I can't write an easy
patch for that solution.
An other solution might be implementing a
org.apache.webbeans.util.ServiceLoader and using this instead of the
com.googlecode one. This might be the cleanest solution.
So we have 4 possibilities:
1) googlecode
2) jdk 1.6 code self compiled in the project
3) plugin
4) writing own service-loader
Regards,
Udo
Am 08.06.11 11:25, schrieb Gerhard Petracek:
> hi udo,
>
> @OWB-582:
> using com.googlecode.* directly in owb is imo no good idea.
> since the service-loader isn't available in a java 1.5 environment,
> you can repackage the service-loader in your project. so we don't have
> to change owb itself - you just have an additional jar in your
> project. if there is any issue with such an approach, we could create
> an owb-plugin for it and you write your own plugin-implementation.
>
> @OWB-583:
> looks fine to me (just had a quick look).
>
> regards,
> gerhard
>
> 2011/6/8, Udo Schnurpfeil<ud...@schnurpfeil.de>:
>> Hi,
>>
>> I would like to use OWB on WebSphere 6.1 (similar to Tomcat 5.5) which
>> requires Java 1.5 and supports Servlet API 2.4.
>> OWB needs Java 1.6 and Servlet API 2.5.
>>
>> Part 1: Java 1.6
>>
>> After a close look into the sources I see, there is one basic dependency
>> to Java 1.6: java.util.ServiceLoader
>> To solve this problem, I've added a utility class in my local copy and
>> delegate calls to ServiceLoader to this utility.
>>
>> The utility class itself calls ServiceLoader, if the class is available
>> (Java 1.6) or uses com.googlecode.bspi.ServiceLoader (Java 1.5).
>> So the application needs one new dependency (only in the case of Java 1.5).
>>
>> I've also changed the maven-compiler-plugin to generate Java 1.5
>> compatible byte code.
>>
>> Jira: https://issues.apache.org/jira/browse/OWB-582
>>
>> Part 2: Servet API 2.5
>>
>> Some classes uses the new function ServletContext.getContextPath() for
>> logging and giving a thread a useful name.
>>
>> Here, I also added a utility class, and call
>> servletContext.getServletContextName() in the case of Servlet API 2.4
>>
>> Jira: https://issues.apache.org/jira/browse/OWB-583
>>
>> Conclusion:
>>
>> There are not many dependencies to the new APIs and there are simple
>> workarounds. With this changes (and a similar patch for the
>> ServiceLoader in CODI) I'm able to run OWB on WebSpere 6.1 and Tomcat
>> 5.5 with Java 1.5.
>>
>> Any suggestions?
>>
>> Regards,
>>
>> Udo
>>
>>
>
Re: OWB with Java 1.5 and Servlet 2.4
Posted by Udo Schnurpfeil <ud...@schnurpfeil.de>.
Hi Gerhard,
I don't know what the problem is, with the direct dependency. I've
marked it as optional in the pom.xml. A Java 1.6 application will run
without changes (and not having googlecode in the jar). But I can
understand, that there are reasons on principal to have no dependencies
to other project.
Did I understand you correctly in your first solution approach?
Compile the Sources of java.util.ServiceLoader with Java 1.5 and put it
into a single JAR File.
This might be also not very nice, as a general solution: OWB works with
Java 1.5, when you compile some JDK classes.
Sadly I don't know the plugin mechanism of OWB, so I can't write an easy
patch for that solution.
An other solution might be implementing a
org.apache.webbeans.util.ServiceLoader and using this instead of the
com.googlecode one. This might be the cleanest solution.
So we have 4 possibilities:
1) googlecode
2) jdk 1.6 code self compiled in the project
3) plugin
4) writing own service-loader
Regards,
Udo
Am 08.06.11 11:25, schrieb Gerhard Petracek:
> hi udo,
>
> @OWB-582:
> using com.googlecode.* directly in owb is imo no good idea.
> since the service-loader isn't available in a java 1.5 environment,
> you can repackage the service-loader in your project. so we don't have
> to change owb itself - you just have an additional jar in your
> project. if there is any issue with such an approach, we could create
> an owb-plugin for it and you write your own plugin-implementation.
>
> @OWB-583:
> looks fine to me (just had a quick look).
>
> regards,
> gerhard
>
> 2011/6/8, Udo Schnurpfeil<ud...@schnurpfeil.de>:
>> Hi,
>>
>> I would like to use OWB on WebSphere 6.1 (similar to Tomcat 5.5) which
>> requires Java 1.5 and supports Servlet API 2.4.
>> OWB needs Java 1.6 and Servlet API 2.5.
>>
>> Part 1: Java 1.6
>>
>> After a close look into the sources I see, there is one basic dependency
>> to Java 1.6: java.util.ServiceLoader
>> To solve this problem, I've added a utility class in my local copy and
>> delegate calls to ServiceLoader to this utility.
>>
>> The utility class itself calls ServiceLoader, if the class is available
>> (Java 1.6) or uses com.googlecode.bspi.ServiceLoader (Java 1.5).
>> So the application needs one new dependency (only in the case of Java 1.5).
>>
>> I've also changed the maven-compiler-plugin to generate Java 1.5
>> compatible byte code.
>>
>> Jira: https://issues.apache.org/jira/browse/OWB-582
>>
>> Part 2: Servet API 2.5
>>
>> Some classes uses the new function ServletContext.getContextPath() for
>> logging and giving a thread a useful name.
>>
>> Here, I also added a utility class, and call
>> servletContext.getServletContextName() in the case of Servlet API 2.4
>>
>> Jira: https://issues.apache.org/jira/browse/OWB-583
>>
>> Conclusion:
>>
>> There are not many dependencies to the new APIs and there are simple
>> workarounds. With this changes (and a similar patch for the
>> ServiceLoader in CODI) I'm able to run OWB on WebSpere 6.1 and Tomcat
>> 5.5 with Java 1.5.
>>
>> Any suggestions?
>>
>> Regards,
>>
>> Udo
>>
>>
>
Re: OWB with Java 1.5 and Servlet 2.4
Posted by Gerhard Petracek <ge...@gmail.com>.
hi udo,
@OWB-582:
using com.googlecode.* directly in owb is imo no good idea.
since the service-loader isn't available in a java 1.5 environment,
you can repackage the service-loader in your project. so we don't have
to change owb itself - you just have an additional jar in your
project. if there is any issue with such an approach, we could create
an owb-plugin for it and you write your own plugin-implementation.
@OWB-583:
looks fine to me (just had a quick look).
regards,
gerhard
2011/6/8, Udo Schnurpfeil <ud...@schnurpfeil.de>:
> Hi,
>
> I would like to use OWB on WebSphere 6.1 (similar to Tomcat 5.5) which
> requires Java 1.5 and supports Servlet API 2.4.
> OWB needs Java 1.6 and Servlet API 2.5.
>
> Part 1: Java 1.6
>
> After a close look into the sources I see, there is one basic dependency
> to Java 1.6: java.util.ServiceLoader
> To solve this problem, I've added a utility class in my local copy and
> delegate calls to ServiceLoader to this utility.
>
> The utility class itself calls ServiceLoader, if the class is available
> (Java 1.6) or uses com.googlecode.bspi.ServiceLoader (Java 1.5).
> So the application needs one new dependency (only in the case of Java 1.5).
>
> I've also changed the maven-compiler-plugin to generate Java 1.5
> compatible byte code.
>
> Jira: https://issues.apache.org/jira/browse/OWB-582
>
> Part 2: Servet API 2.5
>
> Some classes uses the new function ServletContext.getContextPath() for
> logging and giving a thread a useful name.
>
> Here, I also added a utility class, and call
> servletContext.getServletContextName() in the case of Servlet API 2.4
>
> Jira: https://issues.apache.org/jira/browse/OWB-583
>
> Conclusion:
>
> There are not many dependencies to the new APIs and there are simple
> workarounds. With this changes (and a similar patch for the
> ServiceLoader in CODI) I'm able to run OWB on WebSpere 6.1 and Tomcat
> 5.5 with Java 1.5.
>
> Any suggestions?
>
> Regards,
>
> Udo
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: OWB with Java 1.5 and Servlet 2.4
Posted by Mark Struberg <st...@yahoo.de>.
Hi Udo!
This looks really good!
I'm currently at a customer, but I'll have a close look at it in the evening (or tomorrow).
LieGrue,
strub
--- On Wed, 6/8/11, Udo Schnurpfeil <ud...@schnurpfeil.de> wrote:
> From: Udo Schnurpfeil <ud...@schnurpfeil.de>
> Subject: OWB with Java 1.5 and Servlet 2.4
> To: dev@openwebbeans.apache.org
> Date: Wednesday, June 8, 2011, 8:23 AM
> Hi,
>
> I would like to use OWB on WebSphere 6.1 (similar to Tomcat
> 5.5) which requires Java 1.5 and supports Servlet API 2.4.
> OWB needs Java 1.6 and Servlet API 2.5.
>
> Part 1: Java 1.6
>
> After a close look into the sources I see, there is one
> basic dependency to Java 1.6: java.util.ServiceLoader
> To solve this problem, I've added a utility class in my
> local copy and delegate calls to ServiceLoader to this
> utility.
>
> The utility class itself calls ServiceLoader, if the class
> is available (Java 1.6) or uses
> com.googlecode.bspi.ServiceLoader (Java 1.5).
> So the application needs one new dependency (only in the
> case of Java 1.5).
>
> I've also changed the maven-compiler-plugin to generate
> Java 1.5 compatible byte code.
>
> Jira: https://issues.apache.org/jira/browse/OWB-582
>
> Part 2: Servet API 2.5
>
> Some classes uses the new function
> ServletContext.getContextPath() for logging and giving a
> thread a useful name.
>
> Here, I also added a utility class, and call
> servletContext.getServletContextName() in the case of
> Servlet API 2.4
>
> Jira: https://issues.apache.org/jira/browse/OWB-583
>
> Conclusion:
>
> There are not many dependencies to the new APIs and there
> are simple workarounds. With this changes (and a similar
> patch for the ServiceLoader in CODI) I'm able to run OWB on
> WebSpere 6.1 and Tomcat 5.5 with Java 1.5.
>
> Any suggestions?
>
> Regards,
>
> Udo
>
>
OWB with Java 1.5 and Servlet 2.4
Posted by Udo Schnurpfeil <ud...@schnurpfeil.de>.
Hi,
I would like to use OWB on WebSphere 6.1 (similar to Tomcat 5.5) which
requires Java 1.5 and supports Servlet API 2.4.
OWB needs Java 1.6 and Servlet API 2.5.
Part 1: Java 1.6
After a close look into the sources I see, there is one basic dependency
to Java 1.6: java.util.ServiceLoader
To solve this problem, I've added a utility class in my local copy and
delegate calls to ServiceLoader to this utility.
The utility class itself calls ServiceLoader, if the class is available
(Java 1.6) or uses com.googlecode.bspi.ServiceLoader (Java 1.5).
So the application needs one new dependency (only in the case of Java 1.5).
I've also changed the maven-compiler-plugin to generate Java 1.5
compatible byte code.
Jira: https://issues.apache.org/jira/browse/OWB-582
Part 2: Servet API 2.5
Some classes uses the new function ServletContext.getContextPath() for
logging and giving a thread a useful name.
Here, I also added a utility class, and call
servletContext.getServletContextName() in the case of Servlet API 2.4
Jira: https://issues.apache.org/jira/browse/OWB-583
Conclusion:
There are not many dependencies to the new APIs and there are simple
workarounds. With this changes (and a similar patch for the
ServiceLoader in CODI) I'm able to run OWB on WebSpere 6.1 and Tomcat
5.5 with Java 1.5.
Any suggestions?
Regards,
Udo
RE: Yet another proxy/weaving problem
Posted by Timothy Ward <ti...@apache.org>.
Hi,
Some quick answers. I hope they help
Regards,
Tim
----------------------------------------
> Date: Sun, 5 Jun 2011 10:40:46 +0100
> From: struberg@yahoo.de
> Subject: Re: Yet another proxy/weaving problem
> To: dev@aries.apache.org
> CC: dev@openwebbeans.apache.org; dev@geronimo.apache.org
>
> I'm now generally wondering:
>
> 1.) Does aries proxy ALL classes?
All classes that can be woven become "proxyable" and implement the WovenProxy interface. Those that can't be woven can be subclass proxied if necessary.
> 2.) are there only certain methods being proxied? Which one in this case?
All non-private, non-abstract, non-static, non-synthetic, non-bridge instance methods
> 3.) What proxying technology is Aries using?
We use the weaving hook service defined by OSGi 4.3 and ASM for bytecode processing
> 4.) finally: How big is the performance impact?
We saw roughly a 400% improvement in throughput on proxied instances :). Non proxy classes saw a negligible degredation (within the measurement error) of about 0-3 clock cycles per method call. This was only really visible for no-op methods.
>
> LieGrue,
> strub
>
> --- On Sat, 6/4/11, David Jencks wrote:
>
> > From: David Jencks
> > Subject: Re: Yet another proxy/weaving problem
> > To: dev@aries.apache.org
> > Cc: dev@openwebbeans.apache.org, "Geronimo Dev List (JIRA)"
> > Date: Saturday, June 4, 2011, 4:02 PM
> > I've now found another place where
> > the added WovenProxy interface breaks
> > OpenWebBeans. The lack of response on the
> > aries list to my first post makes me think that perhaps this
> > interface can't be removed. I notice that there's an
> > isSynthetic() method on Class. I'm not sure what this
> > means but I'm wondering if it would be possible to mark this
> > interface synthetic and have the relevant parts of OWB
> > ignore synthetic interfaces rather than explicitly
> > configuring it to ignore this particular interface?
> >
> > thanks
> > david jencks
> >
> > On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
> >
> > > another day another problem....
> > >
> > >
> > org.apache.webbeans.exception.WebBeansConfigurationException:
> > Decorator : Name:null, WebBeans Type:DECORATOR, API
> > Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
> > Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
> > delegate attribute must implement all of the decorator
> > decorated types, but decorator type interface
> > org.apache.aries.proxy.weaving.WovenProxy is not assignable
> > from delegate type of interface
> > org.jboss.jsr299.tck.tests.context.dependent.Interior
> > >
> > >
> > > I believe the story here is that decorator classes
> > must not implement interfaces that the delegate doesn't
> > implement, but aries is adding the
> > org.apache.aries.proxy.weaving.WovenProxy to the decorator
> > class.
> > >
> > > OWB is already excluding Serializable and I can modify
> > the code to also exclude
> > org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests
> > pass but this is going to involve making the list of ignored
> > interfaces configurable and may not be acceptable to OWB.
> > >
> > > Is there any way to make the weaving/proxying code not
> > add this interface? I don't think the jdk proxying
> > code needs to add interfaces....
> > >
> > > thanks
> > > david jencks
> >
> >
RE: Yet another proxy/weaving problem
Posted by Timothy Ward <ti...@apache.org>.
Hi,
Some quick answers. I hope they help
Regards,
Tim
----------------------------------------
> Date: Sun, 5 Jun 2011 10:40:46 +0100
> From: struberg@yahoo.de
> Subject: Re: Yet another proxy/weaving problem
> To: dev@aries.apache.org
> CC: dev@openwebbeans.apache.org; dev@geronimo.apache.org
>
> I'm now generally wondering:
>
> 1.) Does aries proxy ALL classes?
All classes that can be woven become "proxyable" and implement the WovenProxy interface. Those that can't be woven can be subclass proxied if necessary.
> 2.) are there only certain methods being proxied? Which one in this case?
All non-private, non-abstract, non-static, non-synthetic, non-bridge instance methods
> 3.) What proxying technology is Aries using?
We use the weaving hook service defined by OSGi 4.3 and ASM for bytecode processing
> 4.) finally: How big is the performance impact?
We saw roughly a 400% improvement in throughput on proxied instances :). Non proxy classes saw a negligible degredation (within the measurement error) of about 0-3 clock cycles per method call. This was only really visible for no-op methods.
>
> LieGrue,
> strub
>
> --- On Sat, 6/4/11, David Jencks wrote:
>
> > From: David Jencks
> > Subject: Re: Yet another proxy/weaving problem
> > To: dev@aries.apache.org
> > Cc: dev@openwebbeans.apache.org, "Geronimo Dev List (JIRA)"
> > Date: Saturday, June 4, 2011, 4:02 PM
> > I've now found another place where
> > the added WovenProxy interface breaks
> > OpenWebBeans. The lack of response on the
> > aries list to my first post makes me think that perhaps this
> > interface can't be removed. I notice that there's an
> > isSynthetic() method on Class. I'm not sure what this
> > means but I'm wondering if it would be possible to mark this
> > interface synthetic and have the relevant parts of OWB
> > ignore synthetic interfaces rather than explicitly
> > configuring it to ignore this particular interface?
> >
> > thanks
> > david jencks
> >
> > On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
> >
> > > another day another problem....
> > >
> > >
> > org.apache.webbeans.exception.WebBeansConfigurationException:
> > Decorator : Name:null, WebBeans Type:DECORATOR, API
> > Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
> > Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
> > delegate attribute must implement all of the decorator
> > decorated types, but decorator type interface
> > org.apache.aries.proxy.weaving.WovenProxy is not assignable
> > from delegate type of interface
> > org.jboss.jsr299.tck.tests.context.dependent.Interior
> > >
> > >
> > > I believe the story here is that decorator classes
> > must not implement interfaces that the delegate doesn't
> > implement, but aries is adding the
> > org.apache.aries.proxy.weaving.WovenProxy to the decorator
> > class.
> > >
> > > OWB is already excluding Serializable and I can modify
> > the code to also exclude
> > org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests
> > pass but this is going to involve making the list of ignored
> > interfaces configurable and may not be acceptable to OWB.
> > >
> > > Is there any way to make the weaving/proxying code not
> > add this interface? I don't think the jdk proxying
> > code needs to add interfaces....
> > >
> > > thanks
> > > david jencks
> >
> >
RE: Yet another proxy/weaving problem
Posted by Timothy Ward <ti...@apache.org>.
Hi,
Some quick answers. I hope they help
Regards,
Tim
----------------------------------------
> Date: Sun, 5 Jun 2011 10:40:46 +0100
> From: struberg@yahoo.de
> Subject: Re: Yet another proxy/weaving problem
> To: dev@aries.apache.org
> CC: dev@openwebbeans.apache.org; dev@geronimo.apache.org
>
> I'm now generally wondering:
>
> 1.) Does aries proxy ALL classes?
All classes that can be woven become "proxyable" and implement the WovenProxy interface. Those that can't be woven can be subclass proxied if necessary.
> 2.) are there only certain methods being proxied? Which one in this case?
All non-private, non-abstract, non-static, non-synthetic, non-bridge instance methods
> 3.) What proxying technology is Aries using?
We use the weaving hook service defined by OSGi 4.3 and ASM for bytecode processing
> 4.) finally: How big is the performance impact?
We saw roughly a 400% improvement in throughput on proxied instances :). Non proxy classes saw a negligible degredation (within the measurement error) of about 0-3 clock cycles per method call. This was only really visible for no-op methods.
>
> LieGrue,
> strub
>
> --- On Sat, 6/4/11, David Jencks wrote:
>
> > From: David Jencks
> > Subject: Re: Yet another proxy/weaving problem
> > To: dev@aries.apache.org
> > Cc: dev@openwebbeans.apache.org, "Geronimo Dev List (JIRA)"
> > Date: Saturday, June 4, 2011, 4:02 PM
> > I've now found another place where
> > the added WovenProxy interface breaks
> > OpenWebBeans. The lack of response on the
> > aries list to my first post makes me think that perhaps this
> > interface can't be removed. I notice that there's an
> > isSynthetic() method on Class. I'm not sure what this
> > means but I'm wondering if it would be possible to mark this
> > interface synthetic and have the relevant parts of OWB
> > ignore synthetic interfaces rather than explicitly
> > configuring it to ignore this particular interface?
> >
> > thanks
> > david jencks
> >
> > On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
> >
> > > another day another problem....
> > >
> > >
> > org.apache.webbeans.exception.WebBeansConfigurationException:
> > Decorator : Name:null, WebBeans Type:DECORATOR, API
> > Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
> > Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
> > delegate attribute must implement all of the decorator
> > decorated types, but decorator type interface
> > org.apache.aries.proxy.weaving.WovenProxy is not assignable
> > from delegate type of interface
> > org.jboss.jsr299.tck.tests.context.dependent.Interior
> > >
> > >
> > > I believe the story here is that decorator classes
> > must not implement interfaces that the delegate doesn't
> > implement, but aries is adding the
> > org.apache.aries.proxy.weaving.WovenProxy to the decorator
> > class.
> > >
> > > OWB is already excluding Serializable and I can modify
> > the code to also exclude
> > org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests
> > pass but this is going to involve making the list of ignored
> > interfaces configurable and may not be acceptable to OWB.
> > >
> > > Is there any way to make the weaving/proxying code not
> > add this interface? I don't think the jdk proxying
> > code needs to add interfaces....
> > >
> > > thanks
> > > david jencks
> >
> >
RE: Yet another proxy/weaving problem
Posted by Timothy Ward <ti...@apache.org>.
Sorry,
Aparently I responded on the wrong fork of this message list
>From June 2nd
----------------------
I would like to quickly point out that the method java.lang.reflect.Method#isSynthetic() gives you access to the synthetic flag in a very easy way.
My understanding from JIT implementors has always been that final is a good thing for performance. I also like the additional safety it adds to the proxy code, preventing us accidentally overriding our own implementations.
I do think overriding synthetic methods when proxying is a reasonably bad idea, similarly for bridge methods, which I imagine are also overridden. Intercepting these calls gives the wrong behaviour unless you are extremely careful. Obviously I'm not part of the OWB discussion, and they may be making valid points. For clarity we avoid weaving/overriding synthetic, static, private, bridge, abstract or native modified methods in Aries code.
I assume removing the final modifier from the proxy weaving code also fixes the issue?
Regards,
Tim
----------------
Tim
----------------------------------------
> Subject: Re: Yet another proxy/weaving problem
> From: david_jencks@yahoo.com
> Date: Sat, 4 Jun 2011 09:02:57 -0700
> CC: dev@openwebbeans.apache.org; dev@geronimo.apache.org
> To: dev@aries.apache.org
>
> I've now found another place where the added WovenProxy interface breaks OpenWebBeans. The lack of response on the aries list to my first post makes me think that perhaps this interface can't be removed. I notice that there's an isSynthetic() method on Class. I'm not sure what this means but I'm wondering if it would be possible to mark this interface synthetic and have the relevant parts of OWB ignore synthetic interfaces rather than explicitly configuring it to ignore this particular interface?
>
> thanks
> david jencks
>
> On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
>
> > another day another problem....
> >
> > org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : Name:null, WebBeans Type:DECORATOR, API Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate attribute must implement all of the decorator decorated types, but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not assignable from delegate type of interface org.jboss.jsr299.tck.tests.context.dependent.Interior
> >
> >
> > I believe the story here is that decorator classes must not implement interfaces that the delegate doesn't implement, but aries is adding the org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
> >
> > OWB is already excluding Serializable and I can modify the code to also exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is going to involve making the list of ignored interfaces configurable and may not be acceptable to OWB.
> >
> > Is there any way to make the weaving/proxying code not add this interface? I don't think the jdk proxying code needs to add interfaces....
> >
> > thanks
> > david jencks
>
RE: Yet another proxy/weaving problem
Posted by Timothy Ward <ti...@apache.org>.
Sorry,
Aparently I responded on the wrong fork of this message list
>From June 2nd
----------------------
I would like to quickly point out that the method java.lang.reflect.Method#isSynthetic() gives you access to the synthetic flag in a very easy way.
My understanding from JIT implementors has always been that final is a good thing for performance. I also like the additional safety it adds to the proxy code, preventing us accidentally overriding our own implementations.
I do think overriding synthetic methods when proxying is a reasonably bad idea, similarly for bridge methods, which I imagine are also overridden. Intercepting these calls gives the wrong behaviour unless you are extremely careful. Obviously I'm not part of the OWB discussion, and they may be making valid points. For clarity we avoid weaving/overriding synthetic, static, private, bridge, abstract or native modified methods in Aries code.
I assume removing the final modifier from the proxy weaving code also fixes the issue?
Regards,
Tim
----------------
Tim
----------------------------------------
> Subject: Re: Yet another proxy/weaving problem
> From: david_jencks@yahoo.com
> Date: Sat, 4 Jun 2011 09:02:57 -0700
> CC: dev@openwebbeans.apache.org; dev@geronimo.apache.org
> To: dev@aries.apache.org
>
> I've now found another place where the added WovenProxy interface breaks OpenWebBeans. The lack of response on the aries list to my first post makes me think that perhaps this interface can't be removed. I notice that there's an isSynthetic() method on Class. I'm not sure what this means but I'm wondering if it would be possible to mark this interface synthetic and have the relevant parts of OWB ignore synthetic interfaces rather than explicitly configuring it to ignore this particular interface?
>
> thanks
> david jencks
>
> On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
>
> > another day another problem....
> >
> > org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : Name:null, WebBeans Type:DECORATOR, API Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate attribute must implement all of the decorator decorated types, but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not assignable from delegate type of interface org.jboss.jsr299.tck.tests.context.dependent.Interior
> >
> >
> > I believe the story here is that decorator classes must not implement interfaces that the delegate doesn't implement, but aries is adding the org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
> >
> > OWB is already excluding Serializable and I can modify the code to also exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is going to involve making the list of ignored interfaces configurable and may not be acceptable to OWB.
> >
> > Is there any way to make the weaving/proxying code not add this interface? I don't think the jdk proxying code needs to add interfaces....
> >
> > thanks
> > david jencks
>
RE: Yet another proxy/weaving problem
Posted by Timothy Ward <ti...@apache.org>.
Sorry,
Aparently I responded on the wrong fork of this message list
>From June 2nd
----------------------
I would like to quickly point out that the method java.lang.reflect.Method#isSynthetic() gives you access to the synthetic flag in a very easy way.
My understanding from JIT implementors has always been that final is a good thing for performance. I also like the additional safety it adds to the proxy code, preventing us accidentally overriding our own implementations.
I do think overriding synthetic methods when proxying is a reasonably bad idea, similarly for bridge methods, which I imagine are also overridden. Intercepting these calls gives the wrong behaviour unless you are extremely careful. Obviously I'm not part of the OWB discussion, and they may be making valid points. For clarity we avoid weaving/overriding synthetic, static, private, bridge, abstract or native modified methods in Aries code.
I assume removing the final modifier from the proxy weaving code also fixes the issue?
Regards,
Tim
----------------
Tim
----------------------------------------
> Subject: Re: Yet another proxy/weaving problem
> From: david_jencks@yahoo.com
> Date: Sat, 4 Jun 2011 09:02:57 -0700
> CC: dev@openwebbeans.apache.org; dev@geronimo.apache.org
> To: dev@aries.apache.org
>
> I've now found another place where the added WovenProxy interface breaks OpenWebBeans. The lack of response on the aries list to my first post makes me think that perhaps this interface can't be removed. I notice that there's an isSynthetic() method on Class. I'm not sure what this means but I'm wondering if it would be possible to mark this interface synthetic and have the relevant parts of OWB ignore synthetic interfaces rather than explicitly configuring it to ignore this particular interface?
>
> thanks
> david jencks
>
> On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
>
> > another day another problem....
> >
> > org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : Name:null, WebBeans Type:DECORATOR, API Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate attribute must implement all of the decorator decorated types, but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not assignable from delegate type of interface org.jboss.jsr299.tck.tests.context.dependent.Interior
> >
> >
> > I believe the story here is that decorator classes must not implement interfaces that the delegate doesn't implement, but aries is adding the org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
> >
> > OWB is already excluding Serializable and I can modify the code to also exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is going to involve making the list of ignored interfaces configurable and may not be acceptable to OWB.
> >
> > Is there any way to make the weaving/proxying code not add this interface? I don't think the jdk proxying code needs to add interfaces....
> >
> > thanks
> > david jencks
>
Re: Yet another proxy/weaving problem
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 6, 2011, at 8:30 AM, Richard Ellis wrote:
> David,
>
> I don't think it is easy to mark the WovenProxy class as synthetic because
> it is a real interface with source in the org.apache.aries.proxy.weaving
> package. AFAIK there is no way to mark an interface as synthetic only on
> the implementing class, but not on the interface class itself. It is
> probably possible for us to write a plugin that operates during the
> process-classes phase which will add the synthetic marker to the
> WovenProxy interface class after compilation. Is this what you had in
> mind?
I'm not sure that David had it worked out *how* it would occur. But your suggestion would seem to fit the bill...
--kevan
Re: Yet another proxy/weaving problem
Posted by Richard Ellis <RI...@uk.ibm.com>.
I think the decision about whether it is logically correct to mark the
WovenProxy interface as synthetic is down to semantics. The WovenProxy
class is not dynamically generated, so it is in essence, not synthetic.
However, as you rightly point out only the weaving code calls the
interface and since the interface is added to classes dynamically then I
think we are in agreement that it would be better marked as synthetic in
this case. I was trying to work out if you had a proposal for how to
actually get it marked as synthetic, but it seems you don't, in which case
my proposal for adding the flag via a plugin during process-classes is the
only option on the table at the moment. Tim and I will work to get
something in under Aries-669 to do this.
To answer your question "Can this feature be written so that it doesn't
need to add an interface to every class?":
The motivation for adding the interface was to reduce the need for
reflective calls in the proxy code, which helped towards improving the
proxy performance by about 400% under some circumstances. Given this
improvement I would suggest that we try to be as accommodating as possible
of the interface. So if you mean is there a way to get the same
performance we have achieved without using an interface at all, then the
answer is maybe, but I haven't thought of a way to do it. If you have any
suggestions...
To answer your other question "I also don't really understand the purpose
of the introduced static_init* method, does it need to be called from
subclasses, why can't you add the new bytecode to an existing <clinit>
method?"
There was an existing StaticInitMerger class in the ASM library, so we
used that out of convenience rather than adding the code to the existing
<clinit>. Adding code to the existing <clinit> was harder because we had
to add information that couldn't be written until after we have visited
all the methods in the class (including the <clinit>) so we couldn't weave
the <clinit> whenever we encountered it because we might not yet have all
the required information. Using the ASM utility essentially renamed
multiple <clinit> methods found in the code to static_init_* methods and
then called them all from a single <clinit>. Obviously at the time we were
not aware that this would have side effects in certain places such as
those you encountered. The design I proposed in the comment on Aries-669
should resolve the problem by allowing us to mark a single generated
static_init_UUID method as synthetic and putting a single call to that
method in an existing <clinit> if we find one. If there isn't an existing
<clinit> then we will simply create one marked synthetic. As Tim mentioned
in his comment on Aries-669 we will try to implement a solution avoiding
any ASM source.
Rich
From:
David Jencks <da...@yahoo.com>
To:
dev@aries.apache.org
Date:
06/06/2011 21:57
Subject:
Re: Yet another proxy/weaving problem
On Jun 6, 2011, at 5:30 AM, Richard Ellis wrote:
> David,
>
> I don't think it is easy to mark the WovenProxy class as synthetic
because
> it is a real interface with source in the org.apache.aries.proxy.weaving
> package. AFAIK there is no way to mark an interface as synthetic only on
> the implementing class, but not on the interface class itself. It is
> probably possible for us to write a plugin that operates during the
> process-classes phase which will add the synthetic marker to the
> WovenProxy interface class after compilation. Is this what you had in
> mind?
I kinda figured that since you can change all the other bytecode in
unknown user supplied classes you might be able to think of a way to get
this flag into this known class you wrote. I was more wondering if it was
logically correct to mark it synthetic. I thought it probably was since
according to the extensive documentation of how this stuff works you have
so kindly supplied.... um my random guess based on trying to understand
the code is that only weaving generated code ever calls this interface.
I'd still like an explicit answer to my original question,
**************************************************
Can this feature be written so that it doesn't need to add an interface to
every class?
**************************************************
I also don't really understand the purpose of the introduced static_init*
method, does it need to be called from subclasses, why can't you add the
new bytecode to an existing <clinit> method?
thanks
david jencks
>
> Thanks,
> Rich
>
>
>
> From:
> David Jencks <da...@yahoo.com>
> To:
> dev@aries.apache.org
> Cc:
> dev@openwebbeans.apache.org, "Geronimo Dev List \(JIRA\)"
> <de...@geronimo.apache.org>
> Date:
> 04/06/2011 17:03
> Subject:
> Re: Yet another proxy/weaving problem
>
>
>
> I've now found another place where the added WovenProxy interface breaks
> OpenWebBeans. The lack of response on the aries list to my first post
> makes me think that perhaps this interface can't be removed. I notice
> that there's an isSynthetic() method on Class. I'm not sure what this
> means but I'm wondering if it would be possible to mark this interface
> synthetic and have the relevant parts of OWB ignore synthetic interfaces
> rather than explicitly configuring it to ignore this particular
interface?
>
> thanks
> david jencks
>
> On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
>
>> another day another problem....
>>
>> org.apache.webbeans.exception.WebBeansConfigurationException: Decorator
> : Name:null, WebBeans Type:DECORATOR, API
>
Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
> Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
> delegate attribute must implement all of the decorator decorated types,
> but decorator type interface org.apache.aries.proxy.weaving.WovenProxy
is
> not assignable from delegate type of interface
> org.jboss.jsr299.tck.tests.context.dependent.Interior
>>
>>
>> I believe the story here is that decorator classes must not implement
> interfaces that the delegate doesn't implement, but aries is adding the
> org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
>>
>> OWB is already excluding Serializable and I can modify the code to also
> exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests
pass
> but this is going to involve making the list of ignored interfaces
> configurable and may not be acceptable to OWB.
>>
>> Is there any way to make the weaving/proxying code not add this
> interface? I don't think the jdk proxying code needs to add
> interfaces....
>>
>> thanks
>> david jencks
>
>
>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
>
>
>
>
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Yet another proxy/weaving problem
Posted by David Jencks <da...@yahoo.com>.
On Jun 6, 2011, at 5:30 AM, Richard Ellis wrote:
> David,
>
> I don't think it is easy to mark the WovenProxy class as synthetic because
> it is a real interface with source in the org.apache.aries.proxy.weaving
> package. AFAIK there is no way to mark an interface as synthetic only on
> the implementing class, but not on the interface class itself. It is
> probably possible for us to write a plugin that operates during the
> process-classes phase which will add the synthetic marker to the
> WovenProxy interface class after compilation. Is this what you had in
> mind?
I kinda figured that since you can change all the other bytecode in unknown user supplied classes you might be able to think of a way to get this flag into this known class you wrote. I was more wondering if it was logically correct to mark it synthetic. I thought it probably was since according to the extensive documentation of how this stuff works you have so kindly supplied.... um my random guess based on trying to understand the code is that only weaving generated code ever calls this interface.
I'd still like an explicit answer to my original question,
**************************************************
Can this feature be written so that it doesn't need to add an interface to every class?
**************************************************
I also don't really understand the purpose of the introduced static_init* method, does it need to be called from subclasses, why can't you add the new bytecode to an existing <clinit> method?
thanks
david jencks
>
> Thanks,
> Rich
>
>
>
> From:
> David Jencks <da...@yahoo.com>
> To:
> dev@aries.apache.org
> Cc:
> dev@openwebbeans.apache.org, "Geronimo Dev List \(JIRA\)"
> <de...@geronimo.apache.org>
> Date:
> 04/06/2011 17:03
> Subject:
> Re: Yet another proxy/weaving problem
>
>
>
> I've now found another place where the added WovenProxy interface breaks
> OpenWebBeans. The lack of response on the aries list to my first post
> makes me think that perhaps this interface can't be removed. I notice
> that there's an isSynthetic() method on Class. I'm not sure what this
> means but I'm wondering if it would be possible to mark this interface
> synthetic and have the relevant parts of OWB ignore synthetic interfaces
> rather than explicitly configuring it to ignore this particular interface?
>
> thanks
> david jencks
>
> On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
>
>> another day another problem....
>>
>> org.apache.webbeans.exception.WebBeansConfigurationException: Decorator
> : Name:null, WebBeans Type:DECORATOR, API
> Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
> Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
> delegate attribute must implement all of the decorator decorated types,
> but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is
> not assignable from delegate type of interface
> org.jboss.jsr299.tck.tests.context.dependent.Interior
>>
>>
>> I believe the story here is that decorator classes must not implement
> interfaces that the delegate doesn't implement, but aries is adding the
> org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
>>
>> OWB is already excluding Serializable and I can modify the code to also
> exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass
> but this is going to involve making the list of ignored interfaces
> configurable and may not be acceptable to OWB.
>>
>> Is there any way to make the weaving/proxying code not add this
> interface? I don't think the jdk proxying code needs to add
> interfaces....
>>
>> thanks
>> david jencks
>
>
>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
Re: Yet another proxy/weaving problem
Posted by Richard Ellis <RI...@uk.ibm.com>.
David,
I don't think it is easy to mark the WovenProxy class as synthetic because
it is a real interface with source in the org.apache.aries.proxy.weaving
package. AFAIK there is no way to mark an interface as synthetic only on
the implementing class, but not on the interface class itself. It is
probably possible for us to write a plugin that operates during the
process-classes phase which will add the synthetic marker to the
WovenProxy interface class after compilation. Is this what you had in
mind?
Thanks,
Rich
From:
David Jencks <da...@yahoo.com>
To:
dev@aries.apache.org
Cc:
dev@openwebbeans.apache.org, "Geronimo Dev List \(JIRA\)"
<de...@geronimo.apache.org>
Date:
04/06/2011 17:03
Subject:
Re: Yet another proxy/weaving problem
I've now found another place where the added WovenProxy interface breaks
OpenWebBeans. The lack of response on the aries list to my first post
makes me think that perhaps this interface can't be removed. I notice
that there's an isSynthetic() method on Class. I'm not sure what this
means but I'm wondering if it would be possible to mark this interface
synthetic and have the relevant parts of OWB ignore synthetic interfaces
rather than explicitly configuring it to ignore this particular interface?
thanks
david jencks
On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
> another day another problem....
>
> org.apache.webbeans.exception.WebBeansConfigurationException: Decorator
: Name:null, WebBeans Type:DECORATOR, API
Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
delegate attribute must implement all of the decorator decorated types,
but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is
not assignable from delegate type of interface
org.jboss.jsr299.tck.tests.context.dependent.Interior
>
>
> I believe the story here is that decorator classes must not implement
interfaces that the delegate doesn't implement, but aries is adding the
org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
>
> OWB is already excluding Serializable and I can modify the code to also
exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass
but this is going to involve making the list of ignored interfaces
configurable and may not be acceptable to OWB.
>
> Is there any way to make the weaving/proxying code not add this
interface? I don't think the jdk proxying code needs to add
interfaces....
>
> thanks
> david jencks
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Yet another proxy/weaving problem
Posted by Mark Struberg <st...@yahoo.de>.
I'm now generally wondering:
1.) Does aries proxy ALL classes?
2.) are there only certain methods being proxied? Which one in this case?
3.) What proxying technology is Aries using?
4.) finally: How big is the performance impact?
LieGrue,
strub
--- On Sat, 6/4/11, David Jencks <da...@yahoo.com> wrote:
> From: David Jencks <da...@yahoo.com>
> Subject: Re: Yet another proxy/weaving problem
> To: dev@aries.apache.org
> Cc: dev@openwebbeans.apache.org, "Geronimo Dev List (JIRA)" <de...@geronimo.apache.org>
> Date: Saturday, June 4, 2011, 4:02 PM
> I've now found another place where
> the added WovenProxy interface breaks
> OpenWebBeans. The lack of response on the
> aries list to my first post makes me think that perhaps this
> interface can't be removed. I notice that there's an
> isSynthetic() method on Class. I'm not sure what this
> means but I'm wondering if it would be possible to mark this
> interface synthetic and have the relevant parts of OWB
> ignore synthetic interfaces rather than explicitly
> configuring it to ignore this particular interface?
>
> thanks
> david jencks
>
> On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
>
> > another day another problem....
> >
> >
> org.apache.webbeans.exception.WebBeansConfigurationException:
> Decorator : Name:null, WebBeans Type:DECORATOR, API
> Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
> Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
> delegate attribute must implement all of the decorator
> decorated types, but decorator type interface
> org.apache.aries.proxy.weaving.WovenProxy is not assignable
> from delegate type of interface
> org.jboss.jsr299.tck.tests.context.dependent.Interior
> >
> >
> > I believe the story here is that decorator classes
> must not implement interfaces that the delegate doesn't
> implement, but aries is adding the
> org.apache.aries.proxy.weaving.WovenProxy to the decorator
> class.
> >
> > OWB is already excluding Serializable and I can modify
> the code to also exclude
> org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests
> pass but this is going to involve making the list of ignored
> interfaces configurable and may not be acceptable to OWB.
> >
> > Is there any way to make the weaving/proxying code not
> add this interface? I don't think the jdk proxying
> code needs to add interfaces....
> >
> > thanks
> > david jencks
>
>
Re: Yet another proxy/weaving problem
Posted by Mark Struberg <st...@yahoo.de>.
I'm now generally wondering:
1.) Does aries proxy ALL classes?
2.) are there only certain methods being proxied? Which one in this case?
3.) What proxying technology is Aries using?
4.) finally: How big is the performance impact?
LieGrue,
strub
--- On Sat, 6/4/11, David Jencks <da...@yahoo.com> wrote:
> From: David Jencks <da...@yahoo.com>
> Subject: Re: Yet another proxy/weaving problem
> To: dev@aries.apache.org
> Cc: dev@openwebbeans.apache.org, "Geronimo Dev List (JIRA)" <de...@geronimo.apache.org>
> Date: Saturday, June 4, 2011, 4:02 PM
> I've now found another place where
> the added WovenProxy interface breaks
> OpenWebBeans. The lack of response on the
> aries list to my first post makes me think that perhaps this
> interface can't be removed. I notice that there's an
> isSynthetic() method on Class. I'm not sure what this
> means but I'm wondering if it would be possible to mark this
> interface synthetic and have the relevant parts of OWB
> ignore synthetic interfaces rather than explicitly
> configuring it to ignore this particular interface?
>
> thanks
> david jencks
>
> On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
>
> > another day another problem....
> >
> >
> org.apache.webbeans.exception.WebBeansConfigurationException:
> Decorator : Name:null, WebBeans Type:DECORATOR, API
> Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
> Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
> delegate attribute must implement all of the decorator
> decorated types, but decorator type interface
> org.apache.aries.proxy.weaving.WovenProxy is not assignable
> from delegate type of interface
> org.jboss.jsr299.tck.tests.context.dependent.Interior
> >
> >
> > I believe the story here is that decorator classes
> must not implement interfaces that the delegate doesn't
> implement, but aries is adding the
> org.apache.aries.proxy.weaving.WovenProxy to the decorator
> class.
> >
> > OWB is already excluding Serializable and I can modify
> the code to also exclude
> org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests
> pass but this is going to involve making the list of ignored
> interfaces configurable and may not be acceptable to OWB.
> >
> > Is there any way to make the weaving/proxying code not
> add this interface? I don't think the jdk proxying
> code needs to add interfaces....
> >
> > thanks
> > david jencks
>
>
Re: Yet another proxy/weaving problem
Posted by Mark Struberg <st...@yahoo.de>.
I'm now generally wondering:
1.) Does aries proxy ALL classes?
2.) are there only certain methods being proxied? Which one in this case?
3.) What proxying technology is Aries using?
4.) finally: How big is the performance impact?
LieGrue,
strub
--- On Sat, 6/4/11, David Jencks <da...@yahoo.com> wrote:
> From: David Jencks <da...@yahoo.com>
> Subject: Re: Yet another proxy/weaving problem
> To: dev@aries.apache.org
> Cc: dev@openwebbeans.apache.org, "Geronimo Dev List (JIRA)" <de...@geronimo.apache.org>
> Date: Saturday, June 4, 2011, 4:02 PM
> I've now found another place where
> the added WovenProxy interface breaks
> OpenWebBeans. The lack of response on the
> aries list to my first post makes me think that perhaps this
> interface can't be removed. I notice that there's an
> isSynthetic() method on Class. I'm not sure what this
> means but I'm wondering if it would be possible to mark this
> interface synthetic and have the relevant parts of OWB
> ignore synthetic interfaces rather than explicitly
> configuring it to ignore this particular interface?
>
> thanks
> david jencks
>
> On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
>
> > another day another problem....
> >
> >
> org.apache.webbeans.exception.WebBeansConfigurationException:
> Decorator : Name:null, WebBeans Type:DECORATOR, API
> Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
> Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
> delegate attribute must implement all of the decorator
> decorated types, but decorator type interface
> org.apache.aries.proxy.weaving.WovenProxy is not assignable
> from delegate type of interface
> org.jboss.jsr299.tck.tests.context.dependent.Interior
> >
> >
> > I believe the story here is that decorator classes
> must not implement interfaces that the delegate doesn't
> implement, but aries is adding the
> org.apache.aries.proxy.weaving.WovenProxy to the decorator
> class.
> >
> > OWB is already excluding Serializable and I can modify
> the code to also exclude
> org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests
> pass but this is going to involve making the list of ignored
> interfaces configurable and may not be acceptable to OWB.
> >
> > Is there any way to make the weaving/proxying code not
> add this interface? I don't think the jdk proxying
> code needs to add interfaces....
> >
> > thanks
> > david jencks
>
>
Re: Yet another proxy/weaving problem
Posted by David Jencks <da...@yahoo.com>.
I've now found another place where the added WovenProxy interface breaks OpenWebBeans. The lack of response on the aries list to my first post makes me think that perhaps this interface can't be removed. I notice that there's an isSynthetic() method on Class. I'm not sure what this means but I'm wondering if it would be possible to mark this interface synthetic and have the relevant parts of OWB ignore synthetic interfaces rather than explicitly configuring it to ignore this particular interface?
thanks
david jencks
On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
> another day another problem....
>
> org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : Name:null, WebBeans Type:DECORATOR, API Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate attribute must implement all of the decorator decorated types, but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not assignable from delegate type of interface org.jboss.jsr299.tck.tests.context.dependent.Interior
>
>
> I believe the story here is that decorator classes must not implement interfaces that the delegate doesn't implement, but aries is adding the org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
>
> OWB is already excluding Serializable and I can modify the code to also exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is going to involve making the list of ignored interfaces configurable and may not be acceptable to OWB.
>
> Is there any way to make the weaving/proxying code not add this interface? I don't think the jdk proxying code needs to add interfaces....
>
> thanks
> david jencks
Re: Yet another proxy/weaving problem
Posted by David Jencks <da...@yahoo.com>.
I've now found another place where the added WovenProxy interface breaks OpenWebBeans. The lack of response on the aries list to my first post makes me think that perhaps this interface can't be removed. I notice that there's an isSynthetic() method on Class. I'm not sure what this means but I'm wondering if it would be possible to mark this interface synthetic and have the relevant parts of OWB ignore synthetic interfaces rather than explicitly configuring it to ignore this particular interface?
thanks
david jencks
On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
> another day another problem....
>
> org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : Name:null, WebBeans Type:DECORATOR, API Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate attribute must implement all of the decorator decorated types, but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not assignable from delegate type of interface org.jboss.jsr299.tck.tests.context.dependent.Interior
>
>
> I believe the story here is that decorator classes must not implement interfaces that the delegate doesn't implement, but aries is adding the org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
>
> OWB is already excluding Serializable and I can modify the code to also exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is going to involve making the list of ignored interfaces configurable and may not be acceptable to OWB.
>
> Is there any way to make the weaving/proxying code not add this interface? I don't think the jdk proxying code needs to add interfaces....
>
> thanks
> david jencks
Re: Yet another proxy/weaving problem
Posted by David Jencks <da...@yahoo.com>.
I've now found another place where the added WovenProxy interface breaks OpenWebBeans. The lack of response on the aries list to my first post makes me think that perhaps this interface can't be removed. I notice that there's an isSynthetic() method on Class. I'm not sure what this means but I'm wondering if it would be possible to mark this interface synthetic and have the relevant parts of OWB ignore synthetic interfaces rather than explicitly configuring it to ignore this particular interface?
thanks
david jencks
On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
> another day another problem....
>
> org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : Name:null, WebBeans Type:DECORATOR, API Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate attribute must implement all of the decorator decorated types, but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not assignable from delegate type of interface org.jboss.jsr299.tck.tests.context.dependent.Interior
>
>
> I believe the story here is that decorator classes must not implement interfaces that the delegate doesn't implement, but aries is adding the org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
>
> OWB is already excluding Serializable and I can modify the code to also exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is going to involve making the list of ignored interfaces configurable and may not be acceptable to OWB.
>
> Is there any way to make the weaving/proxying code not add this interface? I don't think the jdk proxying code needs to add interfaces....
>
> thanks
> david jencks
Re: AW: Yet another proxy/weaving problem
Posted by Mark Struberg <st...@yahoo.de>.
Oh thanks for this info. So this problem is not only Aries related but might be happening in other valid scenarios too.
So we should think about a general solution.
LieGrue,
strub
--- On Fri, 6/3/11, Arne Limburg <ar...@openknowledge.de> wrote:
> From: Arne Limburg <ar...@openknowledge.de>
> Subject: AW: Yet another proxy/weaving problem
> To: "dev@openwebbeans.apache.org" <de...@openwebbeans.apache.org>
> Date: Friday, June 3, 2011, 7:47 AM
> Hi,
>
> we had the same problem with Cobertura. And configured it
> not to weave our Decorators which, of course, resulted in a
> lost of test-coverage information of our Decorators. Gurkan,
> how can the SPI module be used to circumvent the problem?
>
> I wonder, if the @Typed-Annotation could be used on
> Decorators to circumvent the problem or if one could write
> an extension that listens to the ProcessAnnotatedType event
> and remove the specific interface from the result of
> getTypeClosure(). Does OWB use this information or is
> reflection done to determine the implemented interfaces?
> I'll have a look at the code...
>
> Regards,
> Arne
>
> --
>
> Arne Limburg - Enterprise Developer
> open knowledge GmbH, Oldenburg
> Bismarckstraße 13, 26122 Oldenburg
> Mobil: +49 (0) 151 108 22 942
> Tel: +49 (0) 441 - 4082-0
> Fax: +49 (0) 441 - 4082-111
> arne.limburg@openknowledge.de
> http://www.openknowledge.de
>
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
> ________________________________________
> Von: Gurkan Erdogdu [gurkanerdogdu@yahoo.com]
> Gesendet: Freitag, 3. Juni 2011 09:37
> An: dev@geronimo.apache.org;
> dev@openwebbeans.apache.org
> Betreff: Re: Yet another proxy/weaving problem
>
> >>>another day another problem....
> Integration is always hard thing :)
>
> >>>but this is going to involve making the list of
> ignored interfaces configurable
> >>>and may not be acceptable to OWB.
> David, this is an acceptable. Explains why SPI module is
> there.
>
>
> --Gurkan
>
>
> ________________________________
> From: David Jencks <da...@yahoo.com>
> To: dev@aries.apache.org
> Cc: dev@openwebbeans.apache.org;
> Geronimo Dev List (JIRA)
> <de...@geronimo.apache.org>
> Sent: Fri, June 3, 2011 9:53:20 AM
> Subject: Yet another proxy/weaving problem
>
> another day another problem....
>
> org.apache.webbeans.exception.WebBeansConfigurationException:
> Decorator :
> Name:null, WebBeans Type:DECORATOR, API
> Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
>
> Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
> delegate attribute must implement all of the decorator
> decorated types, but
> decorator type interface
> org.apache.aries.proxy.weaving.WovenProxy is not
> assignable from delegate type of interface
> org.jboss.jsr299.tck.tests.context.dependent.Interior
>
>
> I believe the story here is that decorator classes must not
> implement interfaces
> that the delegate doesn't implement, but aries is adding
> the
> org.apache.aries.proxy.weaving.WovenProxy to the decorator
> class.
>
> OWB is already excluding Serializable and I can modify the
> code to also exclude
> org.apache.aries.proxy.weaving.WovenProxy and the jcdi
> tests pass but this is
> going to involve making the list of ignored interfaces
> configurable and may not
> be acceptable to OWB.
>
> Is there any way to make the weaving/proxying code not add
> this interface? I
> don't think the jdk proxying code needs to add
> interfaces....
>
> thanks
> david jencks
>
AW: Yet another proxy/weaving problem
Posted by Arne Limburg <ar...@openknowledge.de>.
Hi,
we had the same problem with Cobertura. And configured it not to weave our Decorators which, of course, resulted in a lost of test-coverage information of our Decorators. Gurkan, how can the SPI module be used to circumvent the problem?
I wonder, if the @Typed-Annotation could be used on Decorators to circumvent the problem or if one could write an extension that listens to the ProcessAnnotatedType event and remove the specific interface from the result of getTypeClosure(). Does OWB use this information or is reflection done to determine the implemented interfaces? I'll have a look at the code...
Regards,
Arne
--
Arne Limburg - Enterprise Developer
open knowledge GmbH, Oldenburg
Bismarckstraße 13, 26122 Oldenburg
Mobil: +49 (0) 151 108 22 942
Tel: +49 (0) 441 - 4082-0
Fax: +49 (0) 441 - 4082-111
arne.limburg@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
________________________________________
Von: Gurkan Erdogdu [gurkanerdogdu@yahoo.com]
Gesendet: Freitag, 3. Juni 2011 09:37
An: dev@geronimo.apache.org; dev@openwebbeans.apache.org
Betreff: Re: Yet another proxy/weaving problem
>>>another day another problem....
Integration is always hard thing :)
>>>but this is going to involve making the list of ignored interfaces configurable
>>>and may not be acceptable to OWB.
David, this is an acceptable. Explains why SPI module is there.
--Gurkan
________________________________
From: David Jencks <da...@yahoo.com>
To: dev@aries.apache.org
Cc: dev@openwebbeans.apache.org; Geronimo Dev List (JIRA)
<de...@geronimo.apache.org>
Sent: Fri, June 3, 2011 9:53:20 AM
Subject: Yet another proxy/weaving problem
another day another problem....
org.apache.webbeans.exception.WebBeansConfigurationException: Decorator :
Name:null, WebBeans Type:DECORATOR, API
Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
delegate attribute must implement all of the decorator decorated types, but
decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not
assignable from delegate type of interface
org.jboss.jsr299.tck.tests.context.dependent.Interior
I believe the story here is that decorator classes must not implement interfaces
that the delegate doesn't implement, but aries is adding the
org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
OWB is already excluding Serializable and I can modify the code to also exclude
org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is
going to involve making the list of ignored interfaces configurable and may not
be acceptable to OWB.
Is there any way to make the weaving/proxying code not add this interface? I
don't think the jdk proxying code needs to add interfaces....
thanks
david jencks
Re: Yet another proxy/weaving problem
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
>>>another day another problem....
Integration is always hard thing :)
>>>but this is going to involve making the list of ignored interfaces configurable
>>>and may not be acceptable to OWB.
David, this is an acceptable. Explains why SPI module is there.
--Gurkan
________________________________
From: David Jencks <da...@yahoo.com>
To: dev@aries.apache.org
Cc: dev@openwebbeans.apache.org; Geronimo Dev List (JIRA)
<de...@geronimo.apache.org>
Sent: Fri, June 3, 2011 9:53:20 AM
Subject: Yet another proxy/weaving problem
another day another problem....
org.apache.webbeans.exception.WebBeansConfigurationException: Decorator :
Name:null, WebBeans Type:DECORATOR, API
Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
delegate attribute must implement all of the decorator decorated types, but
decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not
assignable from delegate type of interface
org.jboss.jsr299.tck.tests.context.dependent.Interior
I believe the story here is that decorator classes must not implement interfaces
that the delegate doesn't implement, but aries is adding the
org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
OWB is already excluding Serializable and I can modify the code to also exclude
org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is
going to involve making the list of ignored interfaces configurable and may not
be acceptable to OWB.
Is there any way to make the weaving/proxying code not add this interface? I
don't think the jdk proxying code needs to add interfaces....
thanks
david jencks
Re: Yet another proxy/weaving problem
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
>>>another day another problem....
Integration is always hard thing :)
>>>but this is going to involve making the list of ignored interfaces configurable
>>>and may not be acceptable to OWB.
David, this is an acceptable. Explains why SPI module is there.
--Gurkan
________________________________
From: David Jencks <da...@yahoo.com>
To: dev@aries.apache.org
Cc: dev@openwebbeans.apache.org; Geronimo Dev List (JIRA)
<de...@geronimo.apache.org>
Sent: Fri, June 3, 2011 9:53:20 AM
Subject: Yet another proxy/weaving problem
another day another problem....
org.apache.webbeans.exception.WebBeansConfigurationException: Decorator :
Name:null, WebBeans Type:DECORATOR, API
Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],
Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
delegate attribute must implement all of the decorator decorated types, but
decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not
assignable from delegate type of interface
org.jboss.jsr299.tck.tests.context.dependent.Interior
I believe the story here is that decorator classes must not implement interfaces
that the delegate doesn't implement, but aries is adding the
org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
OWB is already excluding Serializable and I can modify the code to also exclude
org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is
going to involve making the list of ignored interfaces configurable and may not
be acceptable to OWB.
Is there any way to make the weaving/proxying code not add this interface? I
don't think the jdk proxying code needs to add interfaces....
thanks
david jencks