Re: [Springframework-developer] release plan

[Rod J. <rod...@in...>]

> I guess we really need a feature freeze now as soon as possible. Let's
finish the DTD handling, without any obvious questions left unanswered, and
then turn towards a proper release before the TheServerSide Symposium
(already in 3 weeks!). Whether we'll call it 0.8 or 0.9 is a matter of
taste, IMO - in terms of features, 0.9 could be appropriate too.

Yes. I really didn't want to get into radical change at such a late stage,
but I think the DTD issue had to be resolved.

Please let me know of any issues with the new XML. Juergen, thanks for
clearing up the loose ends. (I forgot about references to ancestor
factories. I think your solution is good.)

I've just added partial array support. I can't get Integer[] working and
don't have any more time to look at it, but I tested successfully with
Class[]. It just uses the XML <list> tag.

The only issue I know of now is that a List will always consist of Strings
(except for references). Unfortunately without generics we don't know the
type the List expects. Any thoughts on how to address this? Provide a new
tag for the collection's component class? That would be backward compatible,
so I'm sick of XML right now and I guess we can leave it until 1.0 to
resolve.

0.9 might be the best naming of our imminent release. There's a lot more in
Spring now than we imagined for 0.8. And we can always release
0.91/0.95/whatever if we need something between it and 1.0.

> Let's review the additions proposed some weeks ago:
> - JDO support (done, at the same level as the Hibernate support)
Good. I'll add AOP support before 1.0.

> - SOAP remoting (essential but with which integration strategy, for 1.0)
Certainly not essential for 0.9. I would rather even get to 1.0 and add this
in 1.1, rather than delay 1.0. Unfortunately we couldn't do this with XML as
it would have broken apps. Adding new functionality that's
backward-compatible is fine.

> - Mature JMS support with proper tests (I'd even say essential, for 1.0)
Again, I'd be happy to have this come afterwards. I'd prioritize it about
the same as SOAP, or even a little lower.

> - ResultSets from StoredProcedure (essential, already for 0.9)
Essential for 1.0. Highly desirable for 0.9. If it isn't
backward-compatible, it becomes more important for 0.9.

> Regarding JMS: Personally, I'm interested in the issue. But I don't have
much experience with JMS, so it might better if someone else looked into it.
Any experiences, maybe even volunteers? :-) Shouldn't be hard to do, if one
knows the typical use cases. For comparison: JDO support just took me about
15 hours in total, with pretty sound existing JDO knowledge.

I may have a chance to do something on this in a couple of months. At that
point I'll probably be writing a lot of JMS-related code at work, and will
need to solve the same problems anyway.

> I'm inclined to look at the SOAP stuff myself, although I wouldn't mind a
collaboration. Is anyone working with SOAP currently, maybe even in a
production system? I'm not perfectly clear about our strategy in this
respect. As I see it, the goal is to be able to export any bean as SOAP
service, via a special web controller (an "exporter") that takes the service
bean as reference (just like with our current Hessian/Burlap remoting).

I think it should be absolutely consistent with the existing remoting. This
is not an area I'm likely to be involved in for a while.

>
> It's obvious that we will have to integrate with existing tools, but which
ones?
> - Apache Axis? Obvious candidate, but rather complicated to handle. Quite
a lot of research effort to do a proper integration with it, I guess.
> - TheMindElectric's GLUE? Very easy to use with its own web server, quite
easy to use with a J2EE web container too. But not open source, and sparse
docs on internals.
> - Let's not forget that J2EE 1.4 requires every app server to support
exposing SOAP services, directly from EJBs or via Servlets. Does this offer
any options for us?
Interesting. I was thinking about that myself. However, I don't know much
about it.

I have used Axis successfully in the past, but it is complex. And
performance is reportedly pretty bad (although that may have changed).

Regards,
Rod