Re: [DISCUSSION] javassist-3.12
Don't the maven folks frown upon having repository specs in any poms that go in the central repo? I remember seeing something about that a while back that they were trying to clean that stuff up for some reason. On Wed, Jun 23, 2010 at 10:02 AM, Mark Struberg wrote: > Hoi! > > Since javassist-3.11 has quite remarkable mem leaks, we should use > javassist-3.12 for our RC1 (or -alpha-1) release. > > The problem is that javassist-3.12 is still not uploaded to maven.central. > Pete and Andrew Dinn are working on that but it will most probably take a few > further weeks since Pete is not available atm (JBoss world, etc). > > The release is available on the public jboss edge maven repo: > > http://repository.jboss.org/maven2-brew > > Wdyt, should we use this repo or should we continue delivering with > javassist-3.11 for now and upgrade to 3.12 later? > > We can also write in our README that we know about the mem leaks and that > people should upgrade to 3.12 theirselfs if needed. > > LieGrue, > strub > > > >
[jira] Commented: (OWB-375) Performance: OWB logging performs operations when logging disabled.
[
https://issues.apache.org/jira/browse/OWB-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868282#action_12868282
]
James Carman commented on OWB-375:
--
I agree that this could speed up performance, but are you seriously thinking
this could be a bottleneck? Between the dynamic proxies that are involved and
the "web" aspect of OWB, I would think the string concatenations would be the
least of your worries.
> Performance: OWB logging performs operations when logging disabled.
>
>
> Key: OWB-375
> URL: https://issues.apache.org/jira/browse/OWB-375
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Core
>Reporter: Jacquelle Leggett
>Assignee: Gurkan Erdogdu
>
> Logging operations in OWB code are not guarded by Logger.isLoggable(..) or
> something similar and results in Strings being processed when logging is
> disabled.
> Here's an example from AbstractInjectable:
> logger.debug("Injected into bean : " +
> this.injectionOwnerBean.toString() + " with injection point : " +
> injectionPoint);
> The String concatenation above will occur whether or not logging is enabled.
> WebBeansLogger should be modified so that the above can be changed to:
> if(logger.isDebugEnabed())
> logger.debug("Injected into bean : " +
> this.injectionOwnerBean.toString() + " with injection point : " +
> injectionPoint);
>
> Generally speaking, it's best for logging statements to be guarded by an
> isEnabled() flag to prevent performance impacts.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Need to switch to subclassing?
Here's something that will solve your problem, use AspectJ.
On Tue, May 11, 2010 at 2:51 AM, Mark Struberg wrote:
> Oki let me rephrase: I'd like to know if the spec (or Gavin) intends to
> define this behaviour or if it is 'intentionally left undefined'.
>
> LieGrue,
> strub
>
> --- On Tue, 5/11/10, Gurkan Erdogdu wrote:
>
>> From: Gurkan Erdogdu
>> Subject: Re: Need to switch to subclassing?
>> To: dev@openwebbeans.apache.org
>> Date: Tuesday, May 11, 2010, 6:47 AM
>> Such things should
>> work the same in Weld, CanDI, OWB and all other
>> JSR-299 containers
>> Mmmm, I am not the same. Java EE specifications do not
>> explicitly define some behaviors. Containers could implement
>> those areas with their own way but they are all required to
>> pass the "Java EE TCK". Therefore, one behavior in one
>> container may be differently functioned from other
>> containers. This is mostly observed on container specific
>> security managements.
>>
>> This is the main motivation behind the TCKs.
>>
>>
>> Thanks;
>>
>> --Gurkan
>>
>>
>>
>> From: Mark Struberg
>> To: dev@openwebbeans.apache.org
>> Sent: Tue, May 11, 2010 9:22:11 AM
>> Subject: Re: Need to switch to subclassing?
>>
>> I could not find this explicitly stated in the EJB spec
>> neither - so maybe OpenEJB needs a fix too? :D
>>
>> Nah, just like to know what the 299 spec intends. Such
>> things should work the same in Weld, CanDI, OWB and all
>> other JSR-299 containers. I bet there are only very few
>> developers (users!) out there which would find a bug caused
>> by such a behaviour.
>>
>> So my main concern is not the behaviour itself, but that
>> it's currently not really well defined how it should
>> behave.
>>
>> I'll post this also on the weld list to get a feeling what
>> they expect it to do.
>>
>> LieGrue,
>> strub
>>
>> --- On Tue, 5/11/10, Gurkan Erdogdu
>> wrote:
>>
>> > From: Gurkan Erdogdu
>> > Subject: Re: Need to switch to subclassing?
>> > To: dev@openwebbeans.apache.org
>> > Date: Tuesday, May 11, 2010, 6:11 AM
>> > This will also not work on EJB
>> > containers. For example, in EJB Hello
>> >
>> > @Interceptors(MyInterceptor.class)
>> > public Hello implemenet IHello{
>> >
>> > public void method1(){
>> >
>> method2();
>> > }
>> >
>> > public void method2(){
>> >
>> ...
>> > }
>> > }
>> >
>> > @Local
>> > public interface IHello{
>> > public void method1();
>> > public void method2();
>> > }
>> >
>> > main(){
>> > IHello proxy = getting from
>> intitial context
>> > proxy.method1();
>> > }
>> >
>> >
>> > Calling method2() from method1() does not trigger
>> > interception. Interceptor is called ones when client
>> calls
>> > method1() on bean proxy. You could try it on OpenEJB
>> for
>> > example
>> >
>> > Thanks;
>> >
>> > Gurkan
>> >
>> >
>> >
>> >
>> > From: Mark Struberg
>> > To: dev@openwebbeans.apache.org
>> > Sent: Tue, May 11, 2010 8:30:15 AM
>> > Subject: Need to switch to subclassing?
>> >
>> > Hi!
>> >
>> > There is a subtle difference between implementing
>> > interceptors via proxy or via subclasses.
>> >
>> > I have the following service which imports data from
>> a
>> > legacy system into my db. Since commits are very
>> performance
>> > intense, they should get imported in packages of 100.
>> So
>> > I'll get 100 'Employees' from my legacy system and
>> then call
>> > a @Transactional method to store them in my own
>> database.
>> >
>> > public void ImportService() {
>> > public void importEmployee() {
>> > List
>> les;
>> > while ((les =
>> > getNext100EmployeesFromLegacy()) != nul) {
>> >
>> importLegacyEmployees(le);
>> > }
>> > }
>> >
>> > �...@transactional
>> > protected
>> > importLegacyEmployees(List les)
>> {
>> > for (LegacyEmployee le: les)
>> {
>> >
>> employeeService.store(le);
>> > }
>> > }
>> > }
>> >
>> > This would actually _not_ when using proxies for the
>> > interceptor handling, because calling a method on an
>> own
>> > class doesn't invoke the proxyhandler.
>> >
>> > So is this expected to work?
>> >
>> > Sure, I could easily move the importLegacyEmployees()
>> to an
>> > own service, but that would infringe classic OOP
>> heavily
>> > imo.
>> >
>> > Gurkan, what does the spec say here, I did find
>> nothing.
>> > The old spec explicitly mentioned that we need to use
>> > subclassing, but I cannot find this anymore.
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>>
>>
>
>
>
>
[jira] Commented: (OWB-340) BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor Found
[ https://issues.apache.org/jira/browse/OWB-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851550#action_12851550 ] James Carman commented on OWB-340: -- My patch does that. However, it doesn't propagate a very helpful error message. I guess, if the constructor is null, we could go back through and try to figure out how many suitable constructors there are in the class again and give them the error message then. > BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor > Found > -- > > Key: OWB-340 > URL: https://issues.apache.org/jira/browse/OWB-340 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 >Reporter: James Carman >Assignee: Gurkan Erdogdu > Attachments: OWB-340.patch > > > Instead of throwing an exception, we should just return an InjectionTarget > object that returns an empty set of AnnotatedConstructors from > getConstructors(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-340) BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor Found
[ https://issues.apache.org/jira/browse/OWB-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851546#action_12851546 ] James Carman commented on OWB-340: -- What if I'm not calling produce()? > BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor > Found > -- > > Key: OWB-340 > URL: https://issues.apache.org/jira/browse/OWB-340 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 >Reporter: James Carman >Assignee: Gurkan Erdogdu > Attachments: OWB-340.patch > > > Instead of throwing an exception, we should just return an InjectionTarget > object that returns an empty set of AnnotatedConstructors from > getConstructors(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-340) BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor Found
[ https://issues.apache.org/jira/browse/OWB-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851527#action_12851527 ] James Carman commented on OWB-340: -- No more thoughts on this? I think (know) this is important for extensions which need to inject non-managed objects. In Wicket, the container won't be constructing pages/components. The user's code will. But, I need to be able to inject those objects using the CDI annotations. So, I need to be able to inject the object, but not necessarily be able to create it. This works perfectly with Weld. > BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor > Found > -- > > Key: OWB-340 > URL: https://issues.apache.org/jira/browse/OWB-340 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 >Reporter: James Carman >Assignee: Gurkan Erdogdu > Attachments: OWB-340.patch > > > Instead of throwing an exception, we should just return an InjectionTarget > object that returns an empty set of AnnotatedConstructors from > getConstructors(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Resuming Conversations...
Should I perhaps create a new class called WicketConversationService which implements ConversationService? Would that be the easiest way? On Tue, Mar 30, 2010 at 2:53 PM, James Carman wrote: > Ok, so how do I resume a conversation using OWB? Suppose I know (via > a request parameter or something) that the conversation I need to > resume has id "123". What API call do I use to resume it? > > On Tue, Mar 30, 2010 at 2:50 PM, Mark Struberg wrote: >> Hi James, Nik! >> >> There is currently also a long discussion between JBoss folks about whether >> the current Conversation itself is sufficient or if they should add >> functionality in the spec MR. >> But I'm not sure if there was an outcome yet. >> >> Which means as long as the MR hasn't released, we cannot provide you with >> some portable interface :( >> >> LieGrue, >> strub >> >> --- James Carman schrieb am Di, 30.3.2010: >> >>> Von: James Carman >>> Betreff: Re: Resuming Conversations... >>> An: dev@openwebbeans.apache.org >>> Datum: Dienstag, 30. März, 2010 20:25 Uhr >>> Well, right now, I've got >>> implementation-specific jars for my wicket >>> integration. So, I guess I can do it that way, but >>> I'd rather do it >>> in a "portable" fashion if I can. >>> >>> On Tue, Mar 30, 2010 at 2:01 PM, Nicklas Karlsson >>> wrote: >>> > Mark Struberg was *just* about to comment on the >>> ConversationManager API >>> > suggestion I mailed him about a few weeks ago ;-) >>> > >>> > On Tue, Mar 30, 2010 at 8:55 PM, James Carman >>> > wrote: >>> > >>> >> Is there a portable way to resume conversations >>> with OWB (or using the >>> >> standard API for that matter)? I would love to >>> be able to write my >>> >> Wicket CDI support using the standard API, but so >>> far I can't figure >>> >> out how to do that. >>> >> >>> > >>> > >>> > >>> > -- >>> > --- >>> > Nik >>> > >>> >> >> __ >> Do You Yahoo!? >> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz >> gegen Massenmails. >> http://mail.yahoo.com >> >
Re: Resuming Conversations...
Ok, so how do I resume a conversation using OWB? Suppose I know (via a request parameter or something) that the conversation I need to resume has id "123". What API call do I use to resume it? On Tue, Mar 30, 2010 at 2:50 PM, Mark Struberg wrote: > Hi James, Nik! > > There is currently also a long discussion between JBoss folks about whether > the current Conversation itself is sufficient or if they should add > functionality in the spec MR. > But I'm not sure if there was an outcome yet. > > Which means as long as the MR hasn't released, we cannot provide you with > some portable interface :( > > LieGrue, > strub > > --- James Carman schrieb am Di, 30.3.2010: > >> Von: James Carman >> Betreff: Re: Resuming Conversations... >> An: dev@openwebbeans.apache.org >> Datum: Dienstag, 30. März, 2010 20:25 Uhr >> Well, right now, I've got >> implementation-specific jars for my wicket >> integration. So, I guess I can do it that way, but >> I'd rather do it >> in a "portable" fashion if I can. >> >> On Tue, Mar 30, 2010 at 2:01 PM, Nicklas Karlsson >> wrote: >> > Mark Struberg was *just* about to comment on the >> ConversationManager API >> > suggestion I mailed him about a few weeks ago ;-) >> > >> > On Tue, Mar 30, 2010 at 8:55 PM, James Carman >> > wrote: >> > >> >> Is there a portable way to resume conversations >> with OWB (or using the >> >> standard API for that matter)? I would love to >> be able to write my >> >> Wicket CDI support using the standard API, but so >> far I can't figure >> >> out how to do that. >> >> >> > >> > >> > >> > -- >> > --- >> > Nik >> > >> > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz > gegen Massenmails. > http://mail.yahoo.com >
Re: Resuming Conversations...
Well, right now, I've got implementation-specific jars for my wicket integration. So, I guess I can do it that way, but I'd rather do it in a "portable" fashion if I can. On Tue, Mar 30, 2010 at 2:01 PM, Nicklas Karlsson wrote: > Mark Struberg was *just* about to comment on the ConversationManager API > suggestion I mailed him about a few weeks ago ;-) > > On Tue, Mar 30, 2010 at 8:55 PM, James Carman > wrote: > >> Is there a portable way to resume conversations with OWB (or using the >> standard API for that matter)? I would love to be able to write my >> Wicket CDI support using the standard API, but so far I can't figure >> out how to do that. >> > > > > -- > --- > Nik >
Resuming Conversations...
Is there a portable way to resume conversations with OWB (or using the standard API for that matter)? I would love to be able to write my Wicket CDI support using the standard API, but so far I can't figure out how to do that.
[jira] Commented: (OWB-340) BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor Found
[ https://issues.apache.org/jira/browse/OWB-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850739#action_12850739 ] James Carman commented on OWB-340: -- The point is that it's not necessarily a problem. What if I'm not trying to construct the InjectionTarget? What if I already have an instance and I want to inject it? > BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor > Found > -- > > Key: OWB-340 > URL: https://issues.apache.org/jira/browse/OWB-340 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 >Reporter: James Carman >Assignee: Gurkan Erdogdu > Attachments: OWB-340.patch > > > Instead of throwing an exception, we should just return an InjectionTarget > object that returns an empty set of AnnotatedConstructors from > getConstructors(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-340) BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor Found
[ https://issues.apache.org/jira/browse/OWB-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated OWB-340: - Attachment: OWB-340.patch Here's a patch that gets rid of the immediate exceptions for when there is not exactly one suitable constructor found. If the constructor is null when someone tries to use it, we throw an exception at that point. The only problem here is that we don't convey the fact that there could be multiple suitable constructors found. It merely says "No suitable constructor found for bean ." > BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor > Found > -- > > Key: OWB-340 > URL: https://issues.apache.org/jira/browse/OWB-340 > Project: OpenWebBeans > Issue Type: Bug > Components: Core > Affects Versions: 1.0.0 >Reporter: James Carman >Assignee: Gurkan Erdogdu > Attachments: OWB-340.patch > > > Instead of throwing an exception, we should just return an InjectionTarget > object that returns an empty set of AnnotatedConstructors from > getConstructors(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-340) BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor Found
[ https://issues.apache.org/jira/browse/OWB-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated OWB-340: - Description: Instead of throwing an exception, we should just return an InjectionTarget object that returns an empty set of AnnotatedConstructors from getConstructors(). (was: Instead of throwing an exception, we should just return an AnnotatedType object that returns an empty set of AnnotatedConstructors from getConstructors().) Summary: BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor Found (was: BeanManagerImpl.createAnnotatedType() Throws Exception When No Constructor Found) > BeanManagerImpl.createInjectionTarget() Throws Exception When No Constructor > Found > -- > > Key: OWB-340 > URL: https://issues.apache.org/jira/browse/OWB-340 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 > Reporter: James Carman >Assignee: Gurkan Erdogdu > > Instead of throwing an exception, we should just return an InjectionTarget > object that returns an empty set of AnnotatedConstructors from > getConstructors(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-340) BeanManagerImpl.createAnnotatedType() Throws Exception When No Constructor Found
BeanManagerImpl.createAnnotatedType() Throws Exception When No Constructor Found Key: OWB-340 URL: https://issues.apache.org/jira/browse/OWB-340 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: James Carman Assignee: Gurkan Erdogdu Instead of throwing an exception, we should just return an AnnotatedType object that returns an empty set of AnnotatedConstructors from getConstructors(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-339) Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
[
https://issues.apache.org/jira/browse/OWB-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated OWB-339:
-
Attachment: OWB-339.patch
Here's a better patch. The previous one contained formatting.
> Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
> -
>
> Key: OWB-339
> URL: https://issues.apache.org/jira/browse/OWB-339
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Injection and Lookup
>Affects Versions: 1.0.0, M4
>Reporter: James Carman
>Assignee: James Carman
> Attachments: OWB-339.patch
>
>
> I've got an inject method for injecting non-contextual objects:
> @SuppressWarnings("unchecked")
> public void inject(T instance)
> {
> BeanManager mgr = BeanManagerImpl.getManager();
> AnnotatedType annotatedType = mgr.createAnnotatedType((Class)
> instance.getClass());
> InjectionTarget injectionTarget =
> mgr.createInjectionTarget(annotatedType);
> CreationalContext context = mgr.createCreationalContext(null);
> injectionTarget.inject(instance, context);
> }
> But, when I try it, I get a NPE in WebBeansUtil:
> java.lang.NullPointerException
> at
> org.apache.webbeans.util.WebBeansUtil.getObjectFromCreationalContext(WebBeansUtil.java:2643)
> at
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:733)
> at
> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:118)
> at
> org.apache.webbeans.inject.InjectableField.doInjection(InjectableField.java:54)
> at
> org.apache.webbeans.component.AbstractInjectionTargetBean.injectField(AbstractInjectionTargetBean.java:354)
> at
> org.apache.webbeans.component.AbstractInjectionTargetBean.injectFields(AbstractInjectionTargetBean.java:314)
> at
> org.apache.webbeans.portable.creation.InjectionTargetProducer.inject(InjectionTargetProducer.java:58)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-339) Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
[
https://issues.apache.org/jira/browse/OWB-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated OWB-339:
-
Attachment: (was: OWB-339.patch)
> Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
> -
>
> Key: OWB-339
> URL: https://issues.apache.org/jira/browse/OWB-339
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Injection and Lookup
>Affects Versions: 1.0.0, M4
>Reporter: James Carman
> Assignee: James Carman
>
> I've got an inject method for injecting non-contextual objects:
> @SuppressWarnings("unchecked")
> public void inject(T instance)
> {
> BeanManager mgr = BeanManagerImpl.getManager();
> AnnotatedType annotatedType = mgr.createAnnotatedType((Class)
> instance.getClass());
> InjectionTarget injectionTarget =
> mgr.createInjectionTarget(annotatedType);
> CreationalContext context = mgr.createCreationalContext(null);
> injectionTarget.inject(instance, context);
> }
> But, when I try it, I get a NPE in WebBeansUtil:
> java.lang.NullPointerException
> at
> org.apache.webbeans.util.WebBeansUtil.getObjectFromCreationalContext(WebBeansUtil.java:2643)
> at
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:733)
> at
> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:118)
> at
> org.apache.webbeans.inject.InjectableField.doInjection(InjectableField.java:54)
> at
> org.apache.webbeans.component.AbstractInjectionTargetBean.injectField(AbstractInjectionTargetBean.java:354)
> at
> org.apache.webbeans.component.AbstractInjectionTargetBean.injectFields(AbstractInjectionTargetBean.java:314)
> at
> org.apache.webbeans.portable.creation.InjectionTargetProducer.inject(InjectionTargetProducer.java:58)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-339) Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
[
https://issues.apache.org/jira/browse/OWB-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850528#action_12850528
]
James Carman commented on OWB-339:
--
I tried committing this stuff myself, but apparently I'm not a committer
anymore (perhaps we should fix the documentation then).
> Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
> -
>
> Key: OWB-339
> URL: https://issues.apache.org/jira/browse/OWB-339
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Injection and Lookup
>Affects Versions: 1.0.0, M4
>Reporter: James Carman
>Assignee: James Carman
> Attachments: OWB-339.patch
>
>
> I've got an inject method for injecting non-contextual objects:
> @SuppressWarnings("unchecked")
> public void inject(T instance)
> {
> BeanManager mgr = BeanManagerImpl.getManager();
> AnnotatedType annotatedType = mgr.createAnnotatedType((Class)
> instance.getClass());
> InjectionTarget injectionTarget =
> mgr.createInjectionTarget(annotatedType);
> CreationalContext context = mgr.createCreationalContext(null);
> injectionTarget.inject(instance, context);
> }
> But, when I try it, I get a NPE in WebBeansUtil:
> java.lang.NullPointerException
> at
> org.apache.webbeans.util.WebBeansUtil.getObjectFromCreationalContext(WebBeansUtil.java:2643)
> at
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:733)
> at
> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:118)
> at
> org.apache.webbeans.inject.InjectableField.doInjection(InjectableField.java:54)
> at
> org.apache.webbeans.component.AbstractInjectionTargetBean.injectField(AbstractInjectionTargetBean.java:354)
> at
> org.apache.webbeans.component.AbstractInjectionTargetBean.injectFields(AbstractInjectionTargetBean.java:314)
> at
> org.apache.webbeans.portable.creation.InjectionTargetProducer.inject(InjectionTargetProducer.java:58)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-339) Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
[
https://issues.apache.org/jira/browse/OWB-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated OWB-339:
-
Attachment: OWB-339.patch
Here's a patch that fixes it for my test case.
> Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
> -
>
> Key: OWB-339
> URL: https://issues.apache.org/jira/browse/OWB-339
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Injection and Lookup
>Affects Versions: 1.0.0, M4
>Reporter: James Carman
>Assignee: James Carman
> Attachments: OWB-339.patch
>
>
> I've got an inject method for injecting non-contextual objects:
> @SuppressWarnings("unchecked")
> public void inject(T instance)
> {
> BeanManager mgr = BeanManagerImpl.getManager();
> AnnotatedType annotatedType = mgr.createAnnotatedType((Class)
> instance.getClass());
> InjectionTarget injectionTarget =
> mgr.createInjectionTarget(annotatedType);
> CreationalContext context = mgr.createCreationalContext(null);
> injectionTarget.inject(instance, context);
> }
> But, when I try it, I get a NPE in WebBeansUtil:
> java.lang.NullPointerException
> at
> org.apache.webbeans.util.WebBeansUtil.getObjectFromCreationalContext(WebBeansUtil.java:2643)
> at
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:733)
> at
> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:118)
> at
> org.apache.webbeans.inject.InjectableField.doInjection(InjectableField.java:54)
> at
> org.apache.webbeans.component.AbstractInjectionTargetBean.injectField(AbstractInjectionTargetBean.java:354)
> at
> org.apache.webbeans.component.AbstractInjectionTargetBean.injectFields(AbstractInjectionTargetBean.java:314)
> at
> org.apache.webbeans.portable.creation.InjectionTargetProducer.inject(InjectionTargetProducer.java:58)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-339) Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
Injecting Non-Contextual Beans Causes NPE in WebBeansUtil
-
Key: OWB-339
URL: https://issues.apache.org/jira/browse/OWB-339
Project: OpenWebBeans
Issue Type: Bug
Components: Injection and Lookup
Affects Versions: 1.0.0, M4
Reporter: James Carman
Assignee: James Carman
I've got an inject method for injecting non-contextual objects:
@SuppressWarnings("unchecked")
public void inject(T instance)
{
BeanManager mgr = BeanManagerImpl.getManager();
AnnotatedType annotatedType = mgr.createAnnotatedType((Class)
instance.getClass());
InjectionTarget injectionTarget =
mgr.createInjectionTarget(annotatedType);
CreationalContext context = mgr.createCreationalContext(null);
injectionTarget.inject(instance, context);
}
But, when I try it, I get a NPE in WebBeansUtil:
java.lang.NullPointerException
at
org.apache.webbeans.util.WebBeansUtil.getObjectFromCreationalContext(WebBeansUtil.java:2643)
at
org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:733)
at
org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:118)
at
org.apache.webbeans.inject.InjectableField.doInjection(InjectableField.java:54)
at
org.apache.webbeans.component.AbstractInjectionTargetBean.injectField(AbstractInjectionTargetBean.java:354)
at
org.apache.webbeans.component.AbstractInjectionTargetBean.injectFields(AbstractInjectionTargetBean.java:314)
at
org.apache.webbeans.portable.creation.InjectionTargetProducer.inject(InjectionTargetProducer.java:58)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [DISCUSSION] Using of Logginf in OWB
Which projects did you speak with? On Wed, Mar 3, 2010 at 5:01 AM, Mark Struberg wrote: > Sorry to bring this up again. > > I now looked at many Apache projects for the last few days and talked with a > few people. > > Basically they all switched over to java.util.logging! > > With jdk1.5 the most problems are gone and it is actually now a pretty usable > standard. Plus it is THE standard on EE, we don't need any further dependency > and we can be really sure that there is no classpath conflict somwhere (I > remember what a jarmageddon this have been in the past with commons-logging). > > So I strongly vote for not pulling in another 3rd party jar nor doing it > ourselfs, but simply use the standard java mechanisms. Nowadays this is > simply the way to go, and I think all the other solutions will vanish in the > next few years. > > LieGrue, > strub > > --- Gurkan Erdogdu schrieb am Do, 25.2.2010: > >> Von: Gurkan Erdogdu >> Betreff: Re: [DISCUSSION] Using of Logginf in OWB >> An: dev@openwebbeans.apache.org >> Datum: Donnerstag, 25. Februar, 2010 14:56 Uhr >> Actually yes but it also adds extra >> jars. Instead of adding extra jars could >> we use it with reflection mechanism? WDYT? If it really >> needs a jar on >> classpath, then I think we can live with it. >> >> I am also +1 on using slf4j after reading some documents >> :) >> >> Thanks; >> >> --Gurkan >> >> 2010/2/25 James Carman >> >> > -1 to #3, why re-invent the wheel? It's more >> code that you have to >> > implement, test, maintain, and enhance. >> > >> > +1 to #2 and SLF4J >> > >> > On Thu, Feb 25, 2010 at 2:11 AM, Gurkan Erdogdu >> > >> wrote: >> > > Hi; >> > > >> > > Last couple of days there were some good >> discussion on how to proceed >> > with >> > > logging in OWB. There are some approaches: >> > > >> > > 1* Remove any hard log dependency library from >> classpath(For example : >> > > removing log4.jar from classpath) and use java >> logging. >> > > 2* Use some third-party facades, for example >> using commons-logging and >> > slf4j >> > > etc. I read many complaints about using >> commons-logging in projects >> > because >> > > of classloading issues and memory leaks etc. But >> no knowledge on using >> > > slf4j. >> > > 3* Define our own interface and implement it with >> other logger >> > frameworks. >> > > At runtime, OWB selects which one to use. >> > > >> > > Related issue is : http://issues.apache.org/jira/browse/OWB-300 >> > > >> > > My Comment: >> > > -- >> > > I do not think that using only standard java >> logging is good. Clients >> > want >> > > to use other logging frameworks with OWB >> replacing standard java logging. >> > > But also, I do not want that logging will be the >> most complex part of the >> > > OWB. Logging must be simple. >> > > >> > > Instead of using third party libraries and their >> jars (managing their >> > jars, >> > > adding extra classpath jars etc.), I just want to >> create a our own simple >> > > facade(interface),and implement it with "log4j" >> and "java logging". But >> > > log4j.jar will be optional in "pom.xml" therefore >> there is no hard >> > > dependency to log4j.jar. After that we can >> provide configuration options >> > to >> > > clients which logging framework they use. (Using >> system properties, owb >> > > configuration file etc.).Standard logging will be >> Java Logging. If anyone >> > > really wants to use another logging framework, it >> must implement and >> > > contribute :) >> > > >> > > +1 for the item (3) >> > > >> > > >> > > WDYT? >> > > >> > > --Gurkan >> > > >> > >> >> >> >> -- >> Gurkan Erdogdu >> http://gurkanerdogdu.blogspot.com >> > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz > gegen Massenmails. > http://mail.yahoo.com >
Re: Java EE Independent Core
https://issues.apache.org/jira/browse/OWB-310 On Fri, Feb 26, 2010 at 6:44 AM, Mark Struberg wrote: > yes, very good point Sven, thanks! > > In fact this is a left over from the times the configuration was still > heavily based on XML. We should definitely get rid of this dependency and use > the internal JDK capabilities for parsing. > > Would you please be so kind and open a Jira for that? > > Thanks, > mark > > --- Sven Linstaedt schrieb am Fr, 26.2.2010: > >> Von: Sven Linstaedt >> Betreff: Re: Java EE Independent Core >> An: dev@openwebbeans.apache.org >> Datum: Freitag, 26. Februar, 2010 09:54 Uhr >> Call me ignorant, but what is dom4j >> good for? ;) Afaik beans.xml schema is >> not very complex. Is there other xml we need to parse, >> besides this one? >> Otherwise I would like to suggest using jre built in dom or >> sax parsers. >> wdyt? >> >> Besides this one: I appreciate your idea, so +1 >> >> br, Sven >> >> >> >> 2010/2/26 Mark Struberg >> >> > big +1 :) >> > >> > LieGrue, >> > strub >> > >> > --- Gurkan Erdogdu >> schrieb am Fr, 26.2.2010: >> > >> > > Von: Gurkan Erdogdu >> > > Betreff: Java EE Independent Core >> > > An: dev@openwebbeans.apache.org >> > > Datum: Freitag, 26. Februar, 2010 01:03 Uhr >> > > Hi; >> > > >> > > As we have discussed some time ago, Mark and some >> other >> > > folks would like to use OWB without any >> dependency on Java >> > > EE. I did more than this, and remove all Java EE >> and Web >> > > dependency from webbeans-impl. It just depends on >> EL-API >> > > because of BeanManager API uses it. >> > > >> > > Now, it depends on following jars. I have also >> created some >> > > other projects related with full Java EE and Java >> Web >> > > technologies. >> > > >> > > Dependent Jars >> > > - >> > > log4j (think to drop it also) >> > > dom4j >> > > javassist >> > > scannotation >> > > geronimo-interceptor-spec >> > > jcdi-api >> > > atinject-api >> > > >> > > New Projects >> > > --- >> > > webbeans-web --> Supports web >> > > webbeans-ee --> Fully EE Environment >> > > webbeans-ee-common --> Some commons >> > > >> > > I will hold it until releasing M4. In the mean >> time please >> > > do not commit big changes to trunk. >> > > >> > > Thanks; >> > > >> > > --Gurkan >> > > >> > > >> > > >> > > >> > > >> ___ >> > > Yahoo! Türkiye açıldı! http://yahoo.com.tr >> > > İnternet üzerindeki en iyi içeriği Yahoo! >> Türkiye >> > > sizlere sunuyor! >> > >> > __ >> > Do You Yahoo!? >> > Sie sind Spam leid? Yahoo! Mail verfügt über einen >> herausragenden Schutz >> > gegen Massenmails. >> > http://mail.yahoo.com >> > >> > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz > gegen Massenmails. > http://mail.yahoo.com >
Re: Java EE Independent Core
So, now we're only down to (theoretically in the near future): SLF4J (for logging) commons-proxy (for proxy creation) javassist/cglib (to be chosen by deployment environment, could be optional if user is only proxying interfaces and not beans?) scannotation (for scanning the classpath for annotated classes) geronimo-interceptor-spec (specification to be provided by "container" hopefully) jcdi-api (specification to be provided by "container" hopefully) atinject-api (specification to be provided by "container" hopefully) So, we're really only looking at 4 dependencies besides the API that we depend on? Not too shabby. Of course, there would need to be an SLF4J "impl" jar in there somewhere. 2010/2/26 Sven Linstaedt : > I will create a issue for this task. > > br, Sven > > > 2010/2/26 Gurkan Erdogdu > >> Hi Sven; >> >> Actually I have used dom4j to parse more complex XML that was defined by >> earlier versions of the specification. I think that we can remove XML parts >> of the code base and use Java Standard Parsers instead of Dom4j. >> >> This probably will be done after releasing M4. >> >> Thanks; >> >> --Gurkan >> >> 2010/2/26 Sven Linstaedt >> >> > Call me ignorant, but what is dom4j good for? ;) Afaik beans.xml schema >> is >> > not very complex. Is there other xml we need to parse, besides this one? >> > Otherwise I would like to suggest using jre built in dom or sax parsers. >> > wdyt? >> > >> > Besides this one: I appreciate your idea, so +1 >> > >> > br, Sven >> > >> > >> > >> > 2010/2/26 Mark Struberg >> > >> > > big +1 :) >> > > >> > > LieGrue, >> > > strub >> > > >> > > --- Gurkan Erdogdu schrieb am Fr, 26.2.2010: >> > > >> > > > Von: Gurkan Erdogdu >> > > > Betreff: Java EE Independent Core >> > > > An: dev@openwebbeans.apache.org >> > > > Datum: Freitag, 26. Februar, 2010 01:03 Uhr >> > > > Hi; >> > > > >> > > > As we have discussed some time ago, Mark and some other >> > > > folks would like to use OWB without any dependency on Java >> > > > EE. I did more than this, and remove all Java EE and Web >> > > > dependency from webbeans-impl. It just depends on EL-API >> > > > because of BeanManager API uses it. >> > > > >> > > > Now, it depends on following jars. I have also created some >> > > > other projects related with full Java EE and Java Web >> > > > technologies. >> > > > >> > > > Dependent Jars >> > > > - >> > > > log4j (think to drop it also) >> > > > dom4j >> > > > javassist >> > > > scannotation >> > > > geronimo-interceptor-spec >> > > > jcdi-api >> > > > atinject-api >> > > > >> > > > New Projects >> > > > --- >> > > > webbeans-web --> Supports web >> > > > webbeans-ee --> Fully EE Environment >> > > > webbeans-ee-common --> Some commons >> > > > >> > > > I will hold it until releasing M4. In the mean time please >> > > > do not commit big changes to trunk. >> > > > >> > > > Thanks; >> > > > >> > > > --Gurkan >> > > > >> > > > >> > > > >> > > > >> > > > ___ >> > > > Yahoo! Türkiye açıldı! http://yahoo.com.tr >> > > > İnternet üzerindeki en iyi içeriği Yahoo! Türkiye >> > > > sizlere sunuyor! >> > > >> > > __ >> > > Do You Yahoo!? >> > > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden >> Schutz >> > > gegen Massenmails. >> > > http://mail.yahoo.com >> > > >> > >> >> >> >> -- >> Gurkan Erdogdu >> http://gurkanerdogdu.blogspot.com >> >
Re: [DISCUSSION] Using of Logginf in OWB
-1 to #3, why re-invent the wheel? It's more code that you have to implement, test, maintain, and enhance. +1 to #2 and SLF4J On Thu, Feb 25, 2010 at 2:11 AM, Gurkan Erdogdu wrote: > Hi; > > Last couple of days there were some good discussion on how to proceed with > logging in OWB. There are some approaches: > > 1* Remove any hard log dependency library from classpath(For example : > removing log4.jar from classpath) and use java logging. > 2* Use some third-party facades, for example using commons-logging and slf4j > etc. I read many complaints about using commons-logging in projects because > of classloading issues and memory leaks etc. But no knowledge on using > slf4j. > 3* Define our own interface and implement it with other logger frameworks. > At runtime, OWB selects which one to use. > > Related issue is : http://issues.apache.org/jira/browse/OWB-300 > > My Comment: > -- > I do not think that using only standard java logging is good. Clients want > to use other logging frameworks with OWB replacing standard java logging. > But also, I do not want that logging will be the most complex part of the > OWB. Logging must be simple. > > Instead of using third party libraries and their jars (managing their jars, > adding extra classpath jars etc.), I just want to create a our own simple > facade(interface),and implement it with "log4j" and "java logging". But > log4j.jar will be optional in "pom.xml" therefore there is no hard > dependency to log4j.jar. After that we can provide configuration options to > clients which logging framework they use. (Using system properties, owb > configuration file etc.).Standard logging will be Java Logging. If anyone > really wants to use another logging framework, it must implement and > contribute :) > > +1 for the item (3) > > > WDYT? > > --Gurkan >
[jira] Commented: (OWB-300) Currently OWB requires log4j for logging. This patch provides a means of choosing other loggers.
[ https://issues.apache.org/jira/browse/OWB-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837867#action_12837867 ] James Carman commented on OWB-300: -- I understand the whole idea about minimizing dependencies, but let's get real here. If you're using OWB or some other web-based framework, you've already got a boatload of dependencies. Adding SLF4J to the mix does buy you some flexibility, though. What if a project doesn't want to use JUL? What if they want all of their logging to go somewhere else? Having OWB force them to use and configure JUL is a bigger no-no, if you ask me. OWB needs to be flexible for the client environment. With SLF4J, the client project can use whatever logging implementation they wish and SLF4J (and thus OWB) can adapt to it. > Currently OWB requires log4j for logging. This patch provides a means of > choosing other loggers. > > > Key: OWB-300 > URL: https://issues.apache.org/jira/browse/OWB-300 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core >Affects Versions: M4 > Environment: All >Reporter: Paul J. Reder >Assignee: Gurkan Erdogdu >Priority: Minor > Fix For: M4 > > Attachments: OWBLoggerOnly.patch > > > Currently OWB requires (is dependent on) log4j for logging. This patch > provides a means of choosing other loggers (thus reducing the number of > dependencies but allowing flexibility). Notably, the patch switches the > logging code to using the JDK java util logging (which is already available > for other reasons). The patch includes comments to show how to maintain log4j > use or use it as a model to enable other logging libs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-300) Currently OWB requires log4j for logging. This patch provides a means of choosing other loggers.
[ https://issues.apache.org/jira/browse/OWB-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837814#action_12837814 ] James Carman commented on OWB-300: -- So, use SLF4J. Some folks don't like (including myself) using the JDK logging facilities. Using SLF4J allows the code to talk to one abstraction API and the deployment environment to supply whatever implementation they deem necessary (including JDK logging of course). > Currently OWB requires log4j for logging. This patch provides a means of > choosing other loggers. > > > Key: OWB-300 > URL: https://issues.apache.org/jira/browse/OWB-300 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core >Affects Versions: M4 > Environment: All >Reporter: Paul J. Reder >Assignee: Gurkan Erdogdu >Priority: Minor > Fix For: M4 > > Attachments: OWBLoggerOnly.patch > > > Currently OWB requires log4j for logging. This patch provides a means of > choosing other loggers. Notably, the patch switches the logging code to using > the JDK java util logging. The patch includes comments to show how to > maintain log4j use or use it as a model to enable other logging libs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-300) Currently OWB requires log4j for logging. This patch provides a means of choosing other loggers.
[ https://issues.apache.org/jira/browse/OWB-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837568#action_12837568 ] James Carman commented on OWB-300: -- I would rather see a logging abstraction such as Commons Logging or SLF4J. > Currently OWB requires log4j for logging. This patch provides a means of > choosing other loggers. > > > Key: OWB-300 > URL: https://issues.apache.org/jira/browse/OWB-300 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core >Affects Versions: M4 > Environment: All >Reporter: Paul J. Reder >Assignee: Gurkan Erdogdu >Priority: Minor > Fix For: M4 > > Attachments: OWBLoggerOnly.patch > > > Currently OWB requires log4j for logging. This patch provides a means of > choosing other loggers. Notably, the patch switches the logging code to using > the JDK java util logging. The patch includes comments to show how to > maintain log4j use or use it as a model to enable other logging libs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSSION] Release M4
Of course. That would be part of it, too. Looks like I'll have to submit this as a patch, since I'm not a committer anymore. I keep getting unauthorized errors when I try to commit (I tried to create a branch). On Tue, Feb 23, 2010 at 7:44 AM, Mark Struberg wrote: > we also must not forget to change our MethodHandlers, e.g. > NormalScopedBeanInterceptorHandler et al. > Those are currently implementing the javassist.util.proxy.ProxyHandler > interface. > > It's actually not too much, but it's a pretty sensitive area. > > LieGrue, > strub > > --- James Carman schrieb am Di, 23.2.2010: > >> Von: James Carman >> Betreff: Re: [DISCUSSION] Release M4 >> An: dev@openwebbeans.apache.org >> Datum: Dienstag, 23. Februar, 2010 13:40 Uhr >> I was looking into it. So, the >> only place where we do any proxy >> creation stuff is in the JavassistProxyFactory class? >> If so, here's >> what I plan to do: >> >> 1. Rename the class. >> 2. Change the implementation to use Commons Proxy >> instead, perhaps >> the ProxyFactory used inside the logic should be looked up >> as a >> singleton just like we do elsewhere, so it can be >> configured? >> >> Thoughts? >> >> On Tue, Feb 23, 2010 at 7:36 AM, Mark Struberg >> wrote: >> > I think that would be too much of a change for M4. >> > >> > But I definitely would like to have this for 1.0.0 :) >> > >> > This would completely remove us from the hardcoded >> javassist dependency, thus integration into any kind of EE >> Application Server would really leverage from it! >> > >> > Btw, thanks again for helping us on that, James! >> > >> > LieGrue, >> > strub >> > >> > --- James Carman >> schrieb am Di, 23.2.2010: >> > >> >> Von: James Carman >> >> Betreff: Re: [DISCUSSION] Release M4 >> >> An: dev@openwebbeans.apache.org >> >> Datum: Dienstag, 23. Februar, 2010 13:27 Uhr >> >> Do you guys want the commons-proxy >> >> changes in M4? >> >> >> >> On Tue, Feb 23, 2010 at 2:35 AM, Gurkan Erdogdu >> >> >> >> wrote: >> >> > Hi folks; >> >> > >> >> > I plan to release M4 this week. Please commit >> your >> >> recent changes that you >> >> > would like to include in M4 until Friday. We >> will >> >> freeze code on Friday >> >> > night and I will build a release at weekend. >> Probably >> >> VOTE on the release >> >> > will be at next Monday. >> >> > >> >> > Please do no commit __big__ changes to >> current code >> >> base that may cause to >> >> > cancel releasing. I will be tinkering on some >> minor >> >> changes. >> >> > >> >> > Thanks; >> >> > >> >> > --Gurkan >> >> > >> >> >> > >> > __ >> > Do You Yahoo!? >> > Sie sind Spam leid? Yahoo! Mail verfügt über einen >> herausragenden Schutz gegen Massenmails. >> > http://mail.yahoo.com >> > >> > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz > gegen Massenmails. > http://mail.yahoo.com >
Re: [DISCUSSION] Release M4
I was looking into it. So, the only place where we do any proxy creation stuff is in the JavassistProxyFactory class? If so, here's what I plan to do: 1. Rename the class. 2. Change the implementation to use Commons Proxy instead, perhaps the ProxyFactory used inside the logic should be looked up as a singleton just like we do elsewhere, so it can be configured? Thoughts? On Tue, Feb 23, 2010 at 7:36 AM, Mark Struberg wrote: > I think that would be too much of a change for M4. > > But I definitely would like to have this for 1.0.0 :) > > This would completely remove us from the hardcoded javassist dependency, thus > integration into any kind of EE Application Server would really leverage from > it! > > Btw, thanks again for helping us on that, James! > > LieGrue, > strub > > --- James Carman schrieb am Di, 23.2.2010: > >> Von: James Carman >> Betreff: Re: [DISCUSSION] Release M4 >> An: dev@openwebbeans.apache.org >> Datum: Dienstag, 23. Februar, 2010 13:27 Uhr >> Do you guys want the commons-proxy >> changes in M4? >> >> On Tue, Feb 23, 2010 at 2:35 AM, Gurkan Erdogdu >> >> wrote: >> > Hi folks; >> > >> > I plan to release M4 this week. Please commit your >> recent changes that you >> > would like to include in M4 until Friday. We will >> freeze code on Friday >> > night and I will build a release at weekend. Probably >> VOTE on the release >> > will be at next Monday. >> > >> > Please do no commit __big__ changes to current code >> base that may cause to >> > cancel releasing. I will be tinkering on some minor >> changes. >> > >> > Thanks; >> > >> > --Gurkan >> > >> > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz > gegen Massenmails. > http://mail.yahoo.com >
Re: [DISCUSSION] Release M4
Do you guys want the commons-proxy changes in M4? On Tue, Feb 23, 2010 at 2:35 AM, Gurkan Erdogdu wrote: > Hi folks; > > I plan to release M4 this week. Please commit your recent changes that you > would like to include in M4 until Friday. We will freeze code on Friday > night and I will build a release at weekend. Probably VOTE on the release > will be at next Monday. > > Please do no commit __big__ changes to current code base that may cause to > cancel releasing. I will be tinkering on some minor changes. > > Thanks; > > --Gurkan >
Re: let's get rid of javassist ProxyFactory
Perhaps you guys should check out Commons Proxy's code? On Sun, Feb 21, 2010 at 5:17 AM, Mark Struberg wrote: > Hi! > > I think the javassist ProxyFactory is simply not made for us. > From the JavaDoc: > >> setHandler >> >> public void setHandler(MethodHandler mi) >> Sets the default invocation handler. This invocation handler is shared >> among all the instances of a proxy class unless another is explicitly >> specified. > > Which means that we cannot store _anything_ in a javassist ProxyHandler :( > > What I remember from java.lang.reflec.ProxyHandler is that this is possible. > That's what I also find backed in the JavaDoc: > >> Each proxy instance has an associated invocation handler. When a method >> is invoked on a proxy instance, the method invocation is encoded and >> dispatched to the invoke method of its invocation handler. > > LieGrue, > strub > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz > gegen Massenmails. > http://mail.yahoo.com >
