On Thu, Jan 10, 2013 at 4:35 PM, lb <lburgazz...@gmail.com> wrote:
>
> I think the problem is in BindyAbstractFactory.java :
>
> /**
> * method uses to initialize the model representing the classes who will
> * bind the data. This process will scan for classes according to the
> * package name provided, check the annotated classes and fields.
> *
> * @throws Exception
> */
> public void initModel() throws Exception {
> // Find classes defined as Model
> if (packageNames != null) {
> initModelClasses(this.packageNames);
> } else if (type != null) {
> // use the package name from the type as it may refer to types
> in the same package
> String pckName = type.getPackage().getName();
> initModelClasses(pckName);
> } else {
> throw new IllegalArgumentException("Either packagenames or type
> should be configured");
> }
> }
>
> Looks like bindy scan the package even a class has been specified.
> This force people to write beans in different packages and in my opinion it
> is a wrong behavior; isn't it?
>
Yeah unfortunately bindy was created with the package scanning from the start.
This is a mistake, but its not so easy to fix, as it breaks backwards
compatibility.
In Camel 3.0 we have the luxury of being able to fix that.
>
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/camel-bindy-bindy-ignore-bean-class-type-tp5725275p5725298.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
