> This would be a fairly straightforward surgery of
> replacing the EJB Stateless beans with Spring beans;
Sorry, no experience with Spring. I take your word for it.
> the current
> implementation uses JPA entities rather than EJB Entity beans, so
> they will work unchanged in a Web container architecture.
And there is the initial release of EclipseLink (formerly Oracle's
TopLink) available as an OSGi bundle. EclipseLink implements JPA and
should be easy to use in an OSGi server architecture (sorry, no
experience in using this either).
> All of the
> current Web Services can be move up to web tier rather transparently.
>
> The second step is that I would like to move to a pure OSGI (Equinox)
> server. This will require more effort, especially (well at least for
> me) in the learning curve.
If the above assumptions hold the way to an OSGi only server seems
straightforward. I'm not sure about the amount of work the Spring
framework needs but there is an OSGi implementation of Spring
(http://www.springframework.org/osgi). So in the long run it may be
easiest to go directly the OSGi route.
>
> The advantages, as I see them are:
> simplified development environment
> simplified installation
> simplified maintenance
> lower the bar of entry
> simple single user environments would be realistic
I agree with this statements.
>
> I would like to throw these ideas open to the team. If there
> consensus then I would like to expand the conversation to the
> community via the newsgroup and/or bugzilla.
>
In my opinion we should go for OSGi (but I'm kind of a nerd when it
comes to new/exciting technologies). It's always harder to use new
and possibly buggy technologies but we are not on a tight schedule
for a producton release so we can use the best possible approach.