openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars-Fredrik Smedberg <itsme...@gmail.com>
Subject Re: Question on verifying java classes in a CDI extension
Date Sun, 13 Jul 2014 08:59:38 GMT
Hi Mark

So I understand that from a portable point of view observing the
afterDeploymentValidation event will not be the best choice.

I guess that isAssignableFrom and getSuperClass will face the same problem
for EJBs as you explain and that both ways will work for CDI beans?

Is there any way forward for EJBs with business interfaces?

Regards
Lars-Fredrik



On Sun, Jul 13, 2014 at 10:39 AM, Mark Struberg <struberg@yahoo.de> wrote:

> I fear this wont work as the Contexts are not yet started in
> AfterDeploymentValidation.
>
> "The container must fire a third event after it has validated that there
> are no deployment problems and before creating contexts or processing
> requests."
>
> the isAssignableFrom also has a pitfall of course: if you only like to
> also use this on CDI beans all is fine. But for EJBs it will only work for
> No Interface Views (NIV). Means POJOs with no interface.
> For any EJB with a 'business interface' (basically every interface which
> is not java.io.* or javax.ejb.*) you will get a java.lang.reflect Proxy
> (aka 'interface proxy'). Say if you have a class
>
> @Stateless
> public class MailServiceImpl implements MailService, Serializable
>
> and an injection point
> private @Inject MailService;
> or
> private @EJB MailService;
>
> then you might NOT get some MailServiceImpl$$proxy extends MailServiceImpl
> but a java.lang.reflect proxy which only implements MailService and
> Serializable (and probably some container internal interfaces).
>
> Romains trick with AfterDeploymentValidation would also not be 100%
> portable. It relies on the fact that most containers cache their proxy
> classes. But this is totally up to the container to do or not.
>
> LieGrue,
> strub
>
>
>
>   On Sunday, 13 July 2014, 10:19, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
>
>
>
> the idea was to get the proxy for each classes which will get proxied
> and cache this class. Only issue is to get the proxy you need the Bean
> related context to be active (which can be false for several contexts)
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-07-13 10:07 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
> > @Romain
> >
> > Thanks for the answer.
> >
> > About the afterdeployment I not quite understand, could you elaborate a
> > little bit please on how to do and why it might not work?
> >
> > Regards
> > Lars-Fredrik
> >
> >
> > On Sun, Jul 13, 2014 at 9:34 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >>
> >> IIRC for weld you can test $Proxy and the package. It is a bit fragile
> (ie
> >> will not work with resin for instance) but better than isassignable at
> >> runtime.
> >>
> >> Algo can be: if not in the set try superclass, if superclass in the set
> >> and a proxy (is there $ and it is not a nested class) then add it to
> the set
> >> for next calls.
> >>
> >> IsAssignable doest always work (support too much inheritance)
> >>
> >> You can also get the proxy in the afterdeployment validation for these
> >> beans and cache their class name but can imply some context to be
> active so
> >> previous algo is still better
> >>
> >> Le 13 juil. 2014 07:13, "Lars-Fredrik Smedberg" <itsmeden@gmail.com> a
> >> écrit :
> >>
> >>> @Mark
> >>>
> >>> Thanks for the solution, I guess that would work regardless of the
> >>> underlying proxy technique as well.
> >>>
> >>> The "problem" with solution is that I need to traverse the Set and I
> >>> cannot do a simple set.contains(...), which might not be a big problem
> since
> >>> if I get a match I could insert the proxy class in the set as well I
> >>> guess...
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Sat, Jul 12, 2014 at 10:48 PM, Mark Struberg <struberg@yahoo.de>
> >>> wrote:
> >>>>
> >>>> maybe it's possible to use Class.isAssignableFrom?
> >>>>
> >>>> Because a proxy for the
> >>>> publuc class MyCustomer
> >>>>
> >>>> is basically simply a subclass
> >>>> public class MyCustomer$$Proxy extends MyCustomer
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>> On Saturday, 12 July 2014, 20:52, Lars-Fredrik Smedberg
> >>>> <itsmeden@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Hi!
> >>>>
> >>>> I have the following scenario:
> >>>>
> >>>> 1. A CDI extensions verifies all AnnotatedTypes (in @Observes
> >>>> ProcessAnnotatedType) that is annotated with a specific annotation
> >>>> 2. The class (from annotatedType.getJavaClass()) is verified according
> >>>> to some application specific rules...
> >>>> 3. If the class has been successfully verified its placed in a
> >>>> Set<Class<?>> that is a member variable of the CDI extension
> >>>> 4. The extension is injected into another bean and when the
> application
> >>>> is running I would like to check if a specific object has a type that
> is
> >>>> amongst the correctly verified types in the Set
> >>>>
> >>>> The above works fine if the object to check is an object created by
> new
> >>>> or if its an injected dependent object. However if the object is a
> normal
> >>>> scoped object the class of the object will
> >>>> not match any of the classes in the Set because it will be the proxy
> >>>> class and not the proxied class (which is the one verified and put in
> the
> >>>> Set in the CDI extension).
> >>>>
> >>>> Is there any other way of doing the above or can I somehow get the
> >>>> proxied class so I can check if its in the Set?
> >>>>
> >>>> Regards
> >>>> Lars-Fredrik
> >>>>
> >>>> --
> >>>> Med vänlig hälsning / Best regards
> >>>>
> >>>> Lars-Fredrik Smedberg
> >>>>
> >>>> STATEMENT OF CONFIDENTIALITY:
> >>>> The information contained in this electronic message and any
> >>>> attachments to this message are intended for the exclusive use of the
> >>>> address(es) and may contain confidential or privileged information.
If
> >>>> you are not the intended recipient, please notify Lars-Fredrik
> Smedberg
> >>>> immediately at itsmeden@gmail.com, and destroy all copies of this
> >>>> message and any attachments.
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Med vänlig hälsning / Best regards
> >>>
> >>> Lars-Fredrik Smedberg
> >>>
> >>> STATEMENT OF CONFIDENTIALITY:
> >>> The information contained in this electronic message and any
> >>> attachments to this message are intended for the exclusive use of the
> >>> address(es) and may contain confidential or privileged information. If
> >>> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> >>> immediately at itsmeden@gmail.com, and destroy all copies of this
> >>> message and any attachments.
> >
> >
> >
> >
> > --
> > Med vänlig hälsning / Best regards
> >
> > Lars-Fredrik Smedberg
> >
> > STATEMENT OF CONFIDENTIALITY:
> > The information contained in this electronic message and any
> > attachments to this message are intended for the exclusive use of the
> > address(es) and may contain confidential or privileged information. If
> > you are not the intended recipient, please notify Lars-Fredrik Smedberg
> > immediately at itsmeden@gmail.com, and destroy all copies of this
> > message and any attachments.
>
>
>


-- 
Med vänlig hälsning / Best regards

Lars-Fredrik Smedberg

STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.

Mime
View raw message