|
[
Permlink
| « Hide
]
Douglas C. Kaminsky added a comment - 18/Jan/08 02:39 PM
component should be execution. thanks
Alternative way to improve ItemProcessor type-safety is to add an AbstractTypeSafeItemProcessor that would contain the type-checking logic.
I think the ClassCastException you get without implementing type-checks is informative enough in general, so I guess a non-invasive solution makes sense. The problem with catching a ClassCastException is that such an exception is not necessarily because the wrong type of data was passed to the processor. You could potentially get a ClassCastException from anywhere in your process() code. I'm specifically looking to isolate the condition where you simply have a bad configuration with incompatible item provider / processor - e.g. provider gives you String, processor wants to operate on Integer.
Of course, you could always add a call to Integer.valueOf to your processor to handle this but that's your choice. If that were the case, your processor would then be a String processor, so the same type checking would make sense. Attached patches that potentially address this issue. Feedback gratefully accepted.
I'd offer my vote for generic-based interfaces, especially for things like ItemTransformer. A generic ItemTransformer interface could be offered in addition to the current API as an alternative to waiting for a major rev. If this is an option I would not be adverse to contributing to such an effort.
I have a generic-enabled version of core already locally that's already tested and working - that's not the issue. Spring Source as a rule (if I remember properly) promises compatibility with up to two major versions past, which means since Java is on 6.0 right now that all their code must be 1.4.2 compatible.
(Apparently, Spring Integration is the exception to this rule? -- seems they already use generics as part of their core API) That's why I contributed the 1.4.2-friendly AbstractTypesafeItemWriter as the proposed solution instead of saying "you're out of luck until we use Java 5, and since that's a major API change, you're out of luck until Spring Batch 2.0" Personally, I am of the belief that new frameworks shouldn't have to adhere to the back-compatibility rule, but what are you going to do? Once Spring Core / Spring Batch goes full Java 5.0 you know someone's going to request a 1.4.2 compatible backport version anyway, so it's kind of a no-win situation no matter how you cut it. I've seen other projects with a structure that has something like a spring-batch-core-tiger project that adds Java 5 only features to supplement the API of spring-batch-core. If this isn't going to be part of the official release structure I'd still be really interested in working on it as a 3rd-party extension. Would you mind sharing your generic-enabled version of the core code?
I have no problem contributing it to the Spring Batch project, but the general rule has been that Spring Source does not accept code that they are unwilling or unable to maintain, since they sell service contracts. Until Spring Source as a company moves forward to Java 5.0 (which will, if I understand properly, most likely happen when Java 7.0 is released) it's pointless for me to post it - however, I will definitely put it forward when the time comes.
Sorry I wasn't clear, I'm basically asking if I could use it personally until such time as they consider the issue again. It will save me rewriting something very similar for my use on my current project since I would want to use a generics-based approach.
Unfortunately that's not an option - my code belongs to my employer until such time as it is contributed to Spring Batch. If I were to contribute it now, knowing it wouldn't be accepted, it would be tantamount to sending it to you personally.
Now don't get the wrong impression -- I didn't mention I had a working version locally to try and lure you in to a false sense of hope or anything :) I was just trying to explain that not having something written in Java 5 was not really the issue, it's the back-compatibility promise and the software support responsibilities of Spring Source. If someone from Spring Source comes forward and says "contribute it and we'll support it as an add-on or extension" or says "we're adopting Java 5.0, send it to us" then I'll go ahead and do it. Until then, I'm sorry to say it's proprietary. I suppose this issue can be closed since ItemReaders and ItemWriters have been 'generified'?
Sounds good to me. Java 5 generics solve this problem nicely.
Resolving as fixed (since parameterization technically fixed the issue)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Closed
Major
