Bug 4348 - Do artifacts need no-arg constructor?
Do artifacts need no-arg constructor?
Status: CLOSED FIXED
Product: jbatch
Classification: Unclassified
Component: source
1
PC Windows
: P5 minor
: ---
Assigned To: cvignola
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-20 15:33 UTC by ScottKurz
Modified: 2013-01-16 16:28 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2012-11-20 15:33:22 UTC
Should the spec say that artifacts need a no-arg constructor?  

Maybe this gets lumped into some of the other discussions with DI/CDI/etc. about artifact portability from a more generic Java perspective...
Comment 1 ScottKurz 2012-11-20 15:34:54 UTC
Minor clarification:  I guess the point in saying the artifact would have a no-arg ctor would be to go on to say that the batch container would actually use it to instantiate the instance....
Comment 2 mminella 2012-12-03 21:54:04 UTC
I would assume no given that the loading of artifacts is up to the underlying implementation.  In the Spring example, we don't require no arg constructors and allow users to use constructor injection as they wish.  Although I've never used CDI, I'd imagine similar facilities are available there as well...
Comment 3 cvignola 2012-12-06 19:31:59 UTC
Artifacts cannot be portable if spec implementations decide how constructors are supported.  I believe the spec must require no-arg constructors.
Comment 4 mminella 2012-12-06 19:36:50 UTC
Chris, I respectfully disagree.  By requiring (and therefore implying the use of) no arg constructors, you will then need some form of initialization mechanism to be called once all required properties are set (similar to the InitializationBean interface in Spring).  Without that functionality, I don't think we can require no-arg constructors.
Comment 5 cvignola 2012-12-06 20:10:08 UTC
Michael, I see your point, but I'm not so sure the spec can be completely mute on this subject, either. It still seems to me if the spec delegates this part of the programming model to spec implementors that we break portability. 

So I'm starting to think we need to go in the other direction:  rather than requiring a particular sort of constructor in the programming model,  stipulate the runtime implementation must not require any non-default constructors.

In effect, that implies artifacts are initialized with the default constructor. I wonder if the spec should simply state that. 

If you think the spec should say nothing about constructors,  please comment explicitly on how you see code portability working.  

Thanks
Comment 6 mminella 2012-12-06 20:19:59 UTC
My expectation, since we have agreed that DI is a requirement for the spec and the form of DI is not, was that we would identify a common way to associate artifacts (@Named/batch.xml) and that's as far as the spec would go.  How those artifacts are constructed is an implementation detail dependent on the DI framework used.  If I choose to use CDI, Spring, Guice or any other DI framework, they all have their own mechanisms for object creation and migrating from one to the other would come with a certain level of effort that is outside of the scope of this spec to mitigate (IMO).

For that reason, I would not expect the spec to weigh in on this topic.
Comment 7 cvignola 2012-12-20 15:50:18 UTC
Michael, I think you've convinced me. Construction comes with the DI implementation. The spec will say nothing on this subject.