[cdi-dev] easy solution for class visibility checks?
Pete Muir
pmuir at redhat.com
Fri Dec 23 07:54:49 EST 2011
On 22 Dec 2011, at 23:08, Mark Struberg wrote:
> Yes, it's hard to get right - but the BDA is broken as well. I'd say it's even more heavily broken than just letting it out.
>
> 1.) The major reason is that 1 jar == 1 BDA as per the current spec. This is just way too restrictive and doesn't fit into any existing modularity system, because they either split inside the jars (OSGi exported vs not exported) or way outside the BDA (all jars in WEB-INF/lib of a webapp definitely belong to the same 'module'.
I don't interpret the spec like this, can you say why you come to this conclusion? (spec sections/quotes)
>
> 2.) A few CDI tricks don't recognize the BDA (e.g. @Specializes) but still will be broken if they hit _real_ module boundaries. BDA is not a solution for those.
I don't think this is a problem with bean archives, but with @Specializes.
>
>
> 3.) 99% of all beans in Seam are annotated with @DefaultBean. Guess what this 'DefaultBean' does? It 'works around' the BDA restriction and thus breaks a lots of things. Why? Because you cannot work with this BDA stuff in place. So while you are telling me that BDA is the solution, your folks are blasting it away right now ;)
No, it doesn't work around bean archives, it works around alternatives, which we all know don't work too well from CDI 1.0.
So far you aren't convincing me that bean archives are broken, but that that
1) we have a problem with global enablement of alternatives (which we know)
2) we have a problem with @Specializes and modularity (which we know)
:-)
>
>
>
> But I think we'll finally come up with a solution if we take the time.
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Ales Justin <ajustin at redhat.com>
>> To: cdi-dev <cdi-dev at lists.jboss.org>
>> Cc:
>> Sent: Wednesday, December 21, 2011 5:00 PM
>> Subject: Re: [cdi-dev] easy solution for class visibility checks?
>>
>> Sorry for pitching in so late.
>> (been busy with hacking something similar for our Ceylon M1 :-)
>>
>> Imho, I don't see how moving the visibility to either Context or Contextual
>> will help.
>> I'm more into Pete's favor (and w/o being bias), as there is no way on
>> earth devs will know how to properly implement this in Context or Contextual.
>>
>> I've stated this a few times already, I actually like BDA.
>> It's probably just the lack of proper wording and listing *all* visibility
>> rules (which is definitely hard, but hey this is *the* spec) in the spec that
>> lead to issues that we see now.
>>
>> You only get full visibility rules from CL hierarchy / wiring.
>> But as we all know the CL API doesn't expose anything about this hierarchy
>> / wiring,
>> hence the only one that knows this is the container, which needs a mechanism to
>> abstract this - aka BDA.
>>
>> This way you -- as it is now -- push the nitty-gritty CL details to container
>> devs, not the users.
>> And if you don't have exotic rules -- as we potentially had in MC --
>> implementing BDA is not that difficult.
>> e.g. JEE is pretty straight forward, with only a few exceptions
>>
>> Imo we just need to set better rules on alts, iceptors, decorators, specializes,
>> etc.
>> Or even extend the config, so the user can be even more explicit; e.g. force
>> certain isolation, filtering, etc
>>
>> -Ales
>>
>> On Dec 15, 2011, at 9:35 PM, Arne Limburg wrote:
>>
>>> Ok, as Mark mentioned: Our real problem with class-visibility is: What
>> classloader will Contextual.create use to create the contextual. If we would
>> know this, we could implement container-checks for class-visibility.
>>> So from this comes another idea: What about adding a method
>> getContextualClassLoader() to the Contextual interface? This method should
>> return the classloader that will be used for instance-creation. The container
>> then could check class-visibility for specializing beans, interceptors,
>> decorators and so on.
>>>
>>> Cheers,
>>> Arne
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: cdi-dev-bounces at lists.jboss.org
>> [mailto:cdi-dev-bounces at lists.jboss.org] Im Auftrag von Arne Limburg
>>> Gesendet: Donnerstag, 15. Dezember 2011 14:16
>>> An: Mark Struberg
>>> Cc: cdi-dev
>>> Betreff: Re: [cdi-dev] easy solution for class visibility checks?
>>>
>>> OK, then the question is: How would you implement Context.isVisible?
>> I'm pretty sure, that if your solution works, there would be a very generic
>> implementation for it, that we could use to specify container-behavior. Sounds
>> like it could work, but I still need to think about it...
>>>
>>> Cheers,
>>> Arne
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Mark Struberg [mailto:struberg at yahoo.de]
>>> Gesendet: Donnerstag, 15. Dezember 2011 14:04
>>> An: Arne Limburg; Fabien Marsaud
>>> Cc: cdi-dev; Pete Muir
>>> Betreff: Re: AW: [cdi-dev] easy solution for class visibility checks?
>>>
>>> Thought about that as well, but the problem is that the ClassLoader of a
>> Context is most times irrellevant.
>>>
>>>
>>> E.g. for @RequestScoped, the RequestContext.class is still in weld.jar or
>> owb-impl.jar which is in turn part of the very outermost container classloader.
>>>
>>> The RequestContext never uses the RequestContext.class.getClassLoader but
>> is just a Map<Bean<T>,T /*created via Bean<T>#create()*/>
>>>
>>>
>>> Maybe I'm also a bit too fixated on the way this stuff works in OWB
>> (where we currently don't support EnterpriseApplicationScoped out of the
>> box).
>>>
>>> Because it's not only the Context, it's also the way how
>> Contextual<T>#create works. Which ClassLoader does it take?
>>>
>>>
>>> *stillscratchingmyhead*
>>>
>>> LieGrue,
>>> strub
>>>
>>>> ________________________________
>>>> From: Arne Limburg <arne.limburg at openknowledge.de>
>>>> To: Fabien Marsaud <fabmars at gmail.com>; Mark Struberg
>>>> <struberg at yahoo.de>
>>>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>>>> Sent: Thursday, December 15, 2011 1:29 PM
>>>> Subject: AW: [cdi-dev] easy solution for class visibility checks?
>>>>
>>>>
>>>> Hi,
>>>>
>>>> But Mark’s idea is good anyway. Couldn’t that check be made by the
>> container? The spec just would need to write down the visibility-rules.
>>>> It seems to have to do something with the classloader of the Context
>> and the classloader of the bean type.
>>>> Something like “A bean is visible to a context if the bean-class is the
>> same (meanding Object identity) as the class of the same name that is returned
>> by the classloader of the Context-Instance”
>>>>
>>>> Cheers,
>>>> Arne
>>>>
>>>> Von:cdi-dev-bounces at lists.jboss.org
>>>> [mailto:cdi-dev-bounces at lists.jboss.org] Im Auftrag von Fabien Marsaud
>>>> Gesendet: Donnerstag, 15. Dezember 2011 13:20
>>>> An: Mark Struberg
>>>> Cc: cdi-dev
>>>> Betreff: Re: [cdi-dev] easy solution for class visibility checks?
>>>>
>>>>> Yup, I also don't really like it to make the Contexts
>> responsible alone, because it might make it harder to implement portable
>> Contexts.
>>>>
>>>> I was about to say the same. Usually a scope is straightforward:
>>>> @Scope @Retention @Target public @interface MyScope {}
>>>>
>>>> But the context taking care of it has to drag the whole carriage: the
>> beanstore, the 2 get() methods and the cleanup. This may be not tedious for you,
>> but it definitely is for the average programmer (if he dares ot make it right,
>> threadsafe, etc).
>>>>
>>>> A visibility method would add more complications and give a serious
>> opportunity to the developper to wreck havoc. There should be at least a default
>> impl and/or a higher order instance taking care of the visibility things.
>>>>
>>>> fm.
>>>> On Thu, Dec 15, 2011 at 12:28 PM, Mark Struberg
>> <struberg at yahoo.de> wrote:
>>>> another point is that currently 1 BDA == 1 single jar file (or
>>>> WEB-INF/classes)
>>>>
>>>>
>>>> But that's just way too restrictive imo. IF, then it should treat
>> all jars/classes in the same webapp as 1 BDA and all shared EAR jars as another
>> BDA.
>>>> But still then, there is a lot left undefined. Imo all the BDA stuff is
>> not worth the pita.
>>>>
>>>>
>>>>> Good point. There is definitely a shared responsibility though
>> here,
>>>>> and I'm not sure we can shift all responsibility to the
>> context.
>>>> Yup, I also don't really like it to make the Contexts responsible
>> alone, because it might make it harder to implement portable Contexts.
>>>> Otoh it's pretty pragmatic and is doable in all situations I knew.
>>>>
>>>> Maybe we can collect samples (use-cases) and play with them?
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Pete Muir <pmuir at redhat.com>
>>>>> To: Mark Struberg <struberg at yahoo.de>
>>>>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>>>>> Sent: Thursday, December 15, 2011 12:14 PM
>>>>> Subject: Re: [cdi-dev] easy solution for class visibility checks?
>>>>>
>>>>>
>>>>> On 15 Dec 2011, at 11:10, Mark Struberg wrote:
>>>>>
>>>>>> The BDA stuff is not only broken for @Alternatives, but also
>> for
>>>>> <interceptors> and <decorators>
>>>>>
>>>>> Right, I wrote e.g. not i.e. ;-) Sorry, was just being lazy.
>>>>>
>>>>>>
>>>>>> Plus: @Specializes is NOT affected by BDA as per CDI-1.0. But
>> still
>>>>>> gets
>>>>> hit by class visibility issues.
>>>>>
>>>>> Right, this is not right in the CDI spec.
>>>>>
>>>>>>
>>>>>>
>>>>>> Imo the container just cannot know whether a 3rd party Context
>> is
>>>>>> going to
>>>>> use the ThreadContextClassLoader, the SystemClassloader, the
>>>>> MyScoped.class.getClassLoader() etc. There is nothing a container
>> can
>>>>> do about it, because _only_ the Context knows where it will store
>> it's stuff.
>>>>>
>>>>> Good point. There is definitely a shared responsibility though
>> here,
>>>>> and I'm not sure we can shift all responsibility to the
>> context.
>>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.suntriprecords.com
>>>>
>>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
More information about the cdi-dev
mailing list