Setter injection with non-public methods and dependency-annotated instance variables

[Jacek Laskowski <ja...@laskowski.net.pl>]

Hi,

While reviewing Raj's patch for a setter injection example I spot that
the private method was used with the @Resource dependency annotation.
As I've been thinking about it for a while before I saw it in Raj's
patch it's a good time to ask here and find out where I was wrong.

To me, using non-public methods with a dependency annotation is a bad
idea. It is because it hinders component testing capability, i.e.
there's no simple way to test out the component outside the container
(tm), not too mention that constructing an instance is much harder
with no DI env. Rather than just setting up the component via setters
(when public methods are the only ones dependency annotated) with no
complicated test environment, one would have to use DI framework to
inject the resources and only when it finishes fine start the tests.

To sum up, using non-public methods for setter injection is highly
discouraged and deemed a bad practice. And no field injection should
be used, either.

Am I missing something?

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Setter injection with non-public methods and dependency-annotated instance variables

[David Blevins <da...@visi.com>]

On Jan 14, 2007, at 2:48 AM, Jacek Laskowski wrote:

> Hi,
>
> While reviewing Raj's patch for a setter injection example I spot that
> the private method was used with the @Resource dependency annotation.
> As I've been thinking about it for a while before I saw it in Raj's
> patch it's a good time to ask here and find out where I was wrong.
>
> To me, using non-public methods with a dependency annotation is a bad
> idea. It is because it hinders component testing capability, i.e.
> there's no simple way to test out the component outside the container
> (tm), not too mention that constructing an instance is much harder
> with no DI env. Rather than just setting up the component via setters
> (when public methods are the only ones dependency annotated) with no
> complicated test environment, one would have to use DI framework to
> inject the resources and only when it finishes fine start the tests.
>
> To sum up, using non-public methods for setter injection is highly
> discouraged and deemed a bad practice. And no field injection should
> be used, either.

I agree private field setter injection is not the best idea for  
exactly the reasons you mention.  The spec allows it so it's fine to  
show it, but your comments would be great to add to the examples  
README.txt file.  Or maybe in the wiki page that needs to be created  
for the example.

-David

> Am I missing something?
>
> Jacek
>
> -- 
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Raj Saini <ra...@gmail.com>]

Jacek Laskowski wrote:
> In other words, I reverted my -1 as these semi-annotations are just
> our approach to document the samples and won't polute the rest of
> OpenEJB 3.

Okay, I will work on it. Never worked with Apache Wiki before. If I 
stuck somewhere, will bother you again. :-)

Thanks,

Raj
>
> Jacek
>

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 1/15/07, Raj Saini <ra...@gmail.com> wrote:

> Sure, I can give it a try. However, there was a issue related to semi
> annotations in code for wiki documentation.
> (http://www.mail-archive.com/openejb-commits@incubator.apache.org/msg01156.html).
> Do I need to bother this or just document as Filippo Diotalevi did earlier?

That should help -
http://www.mail-archive.com/openejb-dev@incubator.apache.org/msg01321.html
;-)

In other words, I reverted my -1 as these semi-annotations are just
our approach to document the samples and won't polute the rest of
OpenEJB 3.

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Raj Saini <ra...@gmail.com>]

Jacek Laskowski wrote:
> Taking the opportunity that you're in a good mood, would you mind if I
> asked you to create a Wiki page for the example (as Dave pointed out)
> so the good points don't disappear ;-)
>
Sure, I can give it a try. However, there was a issue related to semi 
annotations in code for wiki documentation. 
(http://www.mail-archive.com/openejb-commits@incubator.apache.org/msg01156.html). 
Do I need to bother this or just document as Filippo Diotalevi did earlier?

Thanks,

Raj
> Jacek
>

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 1/15/07, Raj Saini <ra...@gmail.com> wrote:

> My pleasure. :-)

Taking the opportunity that you're in a good mood, would you mind if I
asked you to create a Wiki page for the example (as Dave pointed out)
so the good points don't disappear ;-)

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Raj Saini <ra...@gmail.com>]

Jacek Laskowski wrote:
> On 1/15/07, Raj Saini <ra...@gmail.com> wrote:
>
>> I understand your point. Having public methods on bean class should not
>> be a problem. Since these methods are not part of the business
>> interface, they wont be accessible to the component clients.
>
> Ah! You're right. I completely forgot about methods that are exposed
> to clients - only those in business intf are. Setter methods won't be
> available *unless* they belong to the business intf. How I could
> forget about it! Thanks Raj!
>
My pleasure. :-)
> Jacek
>

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 1/15/07, Raj Saini <ra...@gmail.com> wrote:

> I understand your point. Having public methods on bean class should not
> be a problem. Since these methods are not part of the business
> interface, they wont be accessible to the component clients.

Ah! You're right. I completely forgot about methods that are exposed
to clients - only those in business intf are. Setter methods won't be
available *unless* they belong to the business intf. How I could
forget about it! Thanks Raj!

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Mohammad Nour El-Din <no...@gmail.com>]

Hi All...

On 1/15/07, Raj Saini <ra...@gmail.com> wrote:
>
> Jacek Laskowski wrote:
> > On 1/15/07, Raj Saini <ra...@gmail.com> wrote:
> >
> >> I feel, it would more depend on the component developer. For example,
> >> she/he may choose to have default (package private) access modifier if
> >> test classes are going to reside in the same package.
> >
> > I've been thinking along those lines. As dependency annotation are to
> > configure a EJB component's state, there should be a way to do alike
> > outside the container. Tests may reside in the same package as the
> > classes they test, but in general if the EJBs are to be run outside
> > the container, they will miss some initializations.
>
> I understand your point. Having public methods on bean class should not
> be a problem. Since these methods are not part of the business
> interface, they wont be accessible to the component clients.


The point issued is good indeed, but I think that JCP people gave this
flexibility so developers still can design their components in a good
fashion, they still have the ability to have their own seceret
implementation hidden from the outside world - not just from the components
clients -, and in the same time accessible to Deployers and Application
assemblers as required by the EJB specs.

Thanks,
>
> Raj
> >
> > Jacek
> >
>
>


-- 
Thanks
- Mohammad Nour

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Raj Saini <ra...@gmail.com>]

Jacek Laskowski wrote:
> On 1/15/07, Raj Saini <ra...@gmail.com> wrote:
>
>> I feel, it would more depend on the component developer. For example,
>> she/he may choose to have default (package private) access modifier if
>> test classes are going to reside in the same package.
>
> I've been thinking along those lines. As dependency annotation are to
> configure a EJB component's state, there should be a way to do alike
> outside the container. Tests may reside in the same package as the
> classes they test, but in general if the EJBs are to be run outside
> the container, they will miss some initializations.

I understand your point. Having public methods on bean class should not 
be a problem. Since these methods are not part of the business 
interface, they wont be accessible to the component clients.

Thanks,

Raj
>
> Jacek
>

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 1/15/07, Raj Saini <ra...@gmail.com> wrote:

> I feel, it would more depend on the component developer. For example,
> she/he may choose to have default (package private) access modifier if
> test classes are going to reside in the same package.

I've been thinking along those lines. As dependency annotation are to
configure a EJB component's state, there should be a way to do alike
outside the container. Tests may reside in the same package as the
classes they test, but in general if the EJBs are to be run outside
the container, they will miss some initializations.

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Setter injection with non-public methods and dependency-annotated instance variables

[Raj Saini <ra...@gmail.com>]

Jacek Laskowski wrote:
> Hi,
>
> While reviewing Raj's patch for a setter injection example I spot that
> the private method was used with the @Resource dependency annotation.
> As I've been thinking about it for a while before I saw it in Raj's
> patch it's a good time to ask here and find out where I was wrong.
>
> To me, using non-public methods with a dependency annotation is a bad
> idea. It is because it hinders component testing capability, i.e.
> there's no simple way to test out the component outside the container
> (tm), not too mention that constructing an instance is much harder
> with no DI env. Rather than just setting up the component via setters
> (when public methods are the only ones dependency annotated) with no
> complicated test environment, one would have to use DI framework to
> inject the resources and only when it finishes fine start the tests.
>
> To sum up, using non-public methods for setter injection is highly
> discouraged and deemed a bad practice. And no field injection should
> be used, either.
>
I feel, it would more depend on the component developer. For example, 
she/he may choose to have default (package private) access modifier if 
test classes are going to reside in the same package.
> Am I missing something?
>
> Jacek
>