How to avoid classes being picked as managed beans?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

How to avoid classes being picked as managed beans?

aalmiray
Hello guys. I'm new to Weld and CDI, perhaps the subject of this message is a bit obvious to some of you but for the life of me couldn't find a portable solution to the following problem: Weld will pick up all classes of an application (found in a single jar that contains an empty beans.xml file), however I would like the container to cherry pick a set of classes based on some criteria (package name, class name convention, annotation, etc).

I've seen that Weld has an extension (non-standard) that allows classes to be annotated with @Veto. It works fine but it poses to additional problems:
- @Veto is Weld specific
- you must annotate each class explicitly, which causes trouble with some classes I have in my app as they are Groovy scripts, thus I can't annotated them (Groovy script do get compiled to class files but you don't actually 'see' the class definition, it is generated by the compiler, thus the annotation could only be added by a compiler plugin that rewrites the generated AST (yes, it can be done but it's a heck of a Yak shaving at this point)).

So, is there a way to specify which classes should be included/excluded in a more generic, standard way?

TIA.
Andres
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid classes being picked as managed beans?

Jason Porter
On Wed, Mar 9, 2011 at 09:03, aalmiray <[hidden email]> wrote:

> Hello guys. I'm new to Weld and CDI, perhaps the subject of this message is a
> bit obvious to some of you but for the life of me couldn't find a portable
> solution to the following problem: Weld will pick up all classes of an
> application (found in a single jar that contains an empty beans.xml file),
> however I would like the container to cherry pick a set of classes based on
> some criteria (package name, class name convention, annotation, etc).
>
> I've seen that Weld has an extension (non-standard) that allows classes to
> be annotated with @Veto. It works fine but it poses to additional problems:
> - @Veto is Weld specific

The annotation is specific to Weld (hopefully will make it into the
CDI 1.1 spec), but the way it works is not.

> - you must annotate each class explicitly, which causes trouble with some
> classes I have in my app as they are Groovy scripts, thus I can't annotated
> them (Groovy script do get compiled to class files but you don't actually
> 'see' the class definition, it is generated by the compiler, thus the
> annotation could only be added by a compiler plugin that rewrites the
> generated AST (yes, it can be done but it's a heck of a Yak shaving at this
> point)).
>
> So, is there a way to specify which classes should be included/excluded in a
> more generic, standard way?

You could create an extension (which is what @Veto uses) to veto a
class from being picked up at deploy time. See
https://github.com/seam/solder/blob/master/impl/src/main/java/org/jboss/seam/solder/core/CoreExtension.java
for a possible implementation.

You could also create a class without a zero-arg constructor, or
create a final class.

> TIA.
> Andres
>
> --
> View this message in context: http://weld-development-discussions.46994.n3.nabble.com/How-to-avoid-classes-being-picked-as-managed-beans-tp2655829p2655829.html
> Sent from the Weld development discussions mailing list archive at Nabble.com.
> _______________________________________________
> weld-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/weld-dev
>



--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
_______________________________________________
weld-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid classes being picked as managed beans?

aalmiray
Awesome! This is precisely what I was looking for.

Thanks!
Andres
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid classes being picked as managed beans?

mojavelinux
In reply to this post by Jason Porter
On Wed, Mar 9, 2011 at 11:30, Jason Porter <lightguard.jp@gmail.com> wrote:
On Wed, Mar 9, 2011 at 09:03, aalmiray <[hidden email]> wrote:
> Hello guys. I'm new to Weld and CDI, perhaps the subject of this message is a
> bit obvious to some of you but for the life of me couldn't find a portable
> solution to the following problem: Weld will pick up all classes of an
> application (found in a single jar that contains an empty beans.xml file),
> however I would like the container to cherry pick a set of classes based on
> some criteria (package name, class name convention, annotation, etc).
>
> I've seen that Weld has an extension (non-standard) that allows classes to
> be annotated with @Veto. It works fine but it poses to additional problems:
> - @Veto is Weld specific

The annotation is specific to Weld (hopefully will make it into the
CDI 1.1 spec), but the way it works is not.

Two corrections :) @Veto is part of Seam (Seam Solder), not Weld. Also, it is portable, as it's based on the portable extension facility in CDI.

Since you can write your own extensions, the solutions to your question are boundless. i can give you some other starting points to consider.

Instead of including beans.xml, which will automatically cause all candidate types to be picked up as beans, you can go the other route and leave out beans.xml, and register beans explicitly. Here's an example:

public class ManualBeanRegistrationExtension implements Extension {
    public void registerBeans(@Observes BeforeBeanDiscovery event, BeanManager bm) {
        event.addAnnotatedType(bm.createAnnotatedType(BeanClassToRegister.class));
    }
}

Another approach is to use Weld's scanning configuration. That is a non-portable solution, though, so you'd have weigh that. If I'm not mistaken, that feature is being discussed for CDI 1.1.


-Dan

--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597



_______________________________________________
weld-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid classes being picked as managed beans?

Jason Porter
You're right Dan :)

On Wed, Mar 9, 2011 at 13:30, Dan Allen <[hidden email]> wrote:

> On Wed, Mar 9, 2011 at 11:30, Jason Porter <[hidden email]> wrote:
>>
>> On Wed, Mar 9, 2011 at 09:03, aalmiray <[hidden email]> wrote:
>> > Hello guys. I'm new to Weld and CDI, perhaps the subject of this message
>> > is a
>> > bit obvious to some of you but for the life of me couldn't find a
>> > portable
>> > solution to the following problem: Weld will pick up all classes of an
>> > application (found in a single jar that contains an empty beans.xml
>> > file),
>> > however I would like the container to cherry pick a set of classes based
>> > on
>> > some criteria (package name, class name convention, annotation, etc).
>> >
>> > I've seen that Weld has an extension (non-standard) that allows classes
>> > to
>> > be annotated with @Veto. It works fine but it poses to additional
>> > problems:
>> > - @Veto is Weld specific
>>
>> The annotation is specific to Weld (hopefully will make it into the
>> CDI 1.1 spec), but the way it works is not.
>
> Two corrections :) @Veto is part of Seam (Seam Solder), not Weld. Also, it
> is portable, as it's based on the portable extension facility in CDI.
> Since you can write your own extensions, the solutions to your question are
> boundless. i can give you some other starting points to consider.
> Instead of including beans.xml, which will automatically cause all candidate
> types to be picked up as beans, you can go the other route and leave out
> beans.xml, and register beans explicitly. Here's an example:
> public class ManualBeanRegistrationExtension implements Extension {
>     public void registerBeans(@Observes BeforeBeanDiscovery event,
> BeanManager bm) {
>
>  event.addAnnotatedType(bm.createAnnotatedType(BeanClassToRegister.class));
>     }
> }
> Another approach is to use Weld's scanning configuration. That is a
> non-portable solution, though, so you'd have weigh that. If I'm not
> mistaken, that feature is being discussed for CDI 1.1.
> http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/configure.html#d0e5767
> -Dan
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>



--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu

_______________________________________________
weld-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid classes being picked as managed beans?

aalmiray
In reply to this post by mojavelinux
mojavelinux wrote
Another approach is to use Weld's scanning configuration. That is a
non-portable solution, though, so you'd have weigh that. If I'm not
mistaken, that feature is being discussed for CDI 1.1.

http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/configure.html#d0e5767
Indeed. Those scan/exclusion features will come in handy. Hope they make it to CDI 1.1; in the meantime I'll resort to a custom Extension as a I need to filter out some beans by type too.

Thanks again for the quick response
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid classes being picked as managed beans?

mojavelinux
On Wed, Mar 9, 2011 at 15:59, aalmiray <[hidden email]> wrote:

mojavelinux wrote:
>
> Another approach is to use Weld's scanning configuration. That is a
> non-portable solution, though, so you'd have weigh that. If I'm not
> mistaken, that feature is being discussed for CDI 1.1.
>
> http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/configure.html#d0e5767
>

Indeed. Those scan/exclusion features will come in handy. Hope they make it
to CDI 1.1; in the meantime I'll resort to a custom Extension as a I need to
filter out some beans by type too.

Here's the issue report for that proposal: https://issues.jboss.org/browse/CDI-87

If you come across some feature/extension point that you think would help improve CDI, please feel empowered to propose a change/addition to CDI. You're experience using CDI in Griffon will give you a unique perspective.


Thanks again for the quick response

You bet.

-Dan

--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597



_______________________________________________
weld-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev