Danny Angus wrote:
> Result after 24 hours,
24 hours! Where did it say that?
I saw the proposal but didn't vote yesterday as I wanted time to clarify
something once I had come up with a viable solution.
>From the proposal...
> The basic pattern will be to have agnostic POJO's contain
> James' domain
> specific code.
> These POJO's will be extended to produce SDI, CDI, J2EE, or bespoke
> pattern-specific lifecycle specialisations through
> inheritance, delegation
> or injection.
> These specialisations can then be used to assemble
> behavioural solutions in
> CDI SDI or J2EE containers which can be maintaned independantly of the
> domain specific code in the POJO's
Container agnostic POJOs have a definite +1 from me.
But the vote offers...
> [ ] +1 I agree that Agnostic SDI style POJO's are an
> effective first step
> and will participate in the development work
> [ ] +0 I neither agree nor disagree that Agnostic SDI style
> POJO's are an
> effective first step but do not oppose the proposal
> [ ] -0 I disagree that Agnostic SDI style POJO's are an
> effective first
> step but do not oppose the proposal
> [ ] -1 I disagree that Agnostic SDI style POJO's are an
> effective first
> step and oppose the proposal because:..
...which may imply we are going to first develop SDI style POJOs. What
happened to the agnostic ones? Aren't "Agnostic" and "SDI style"
contradictory? Are we voting for agnostic POJO's and a first implementation
with SDI enablement or pure SDI POJOs?
The reason I have an issue with this is that as I, and others, have
previously highlighted you cannot simply extend an SDI class to implement a
CDI equivalent. Java does not allow us to reduce the visibility of the
inherited SDI setter methods, but we need to to make the contract of the CDI
class clear. So we absolutely do need a pattern which is DI agnostic. We
would want the specialisations for each kind of container to live in
different packages too, as we don't want to be creating monolithic packages
containing SDI/CDI/EJB/FlavourOfTheMonth enablements.
One way of achieving these objectives is to implement the Agnostic POJOs as
abstract classes with protected setter methods...
package com.agnostic;
public abstract class AgnosticPojo
{
protected AgnosticPojo()
{
super();
}
protected void setStuff(Object stuff)
{
}
}
For SDI, we extend the class like this...
package com.sdi;
import com.agnostic.AgnosticPojo;
public class SetterDI extends AgnosticPojo
{
public SetterDI()
{
super();
}
public void setStuff(Object stuff)
{
super.setStuff(stuff);
}
}
...and for CDI...
package com.cdi;
import com.agnostic.AgnosticPojo;
public class ConstructorDI extends AgnosticPojo
{
// reduce the visibility of the default constructor
private ConstructorDI()
{
super();
}
// Inject dependencies
public ConstructorDI(Object stuff)
{
this();
setStuff(stuff);
}
}
So, if my vote had been within in the unspecified 24 hours, it would have
been a firm +1 if we were voting for POJOs as described in the text of the
proposal. A much more reluctant +1 voting on...
> [ ] +1 I agree that Agnostic SDI style POJO's are an
> effective first step
...as I see "Agnostic" and "SDI style" as contradictory and as you may have
gathered by now, SDI a dead end branch on the evolution of DI. Still, the
future of James is more important than my personal feelings. I never liked
Avalon either, its what is in our POJO's that counts.
Summary after rant = +1
Cheers
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
