David Jencks wrote:
On Jul 17, 2007, at 4:31 PM, Ate Douma wrote:
<giant snip>
- Jetspeed "light" (no need for database persistence and much
simplified page/site management)
- I think that moving to jpa for persistence would be a good idea. I
think moving to java(ee)5 is reasonable too, but it may be possible
to use openjpa in a 1.4 environment (I'm not sure). At least if we
can move to java 5 I think I can help with this.
With the planned support for JSR-286 Portlet API 2.0, which requires
Java 5 too, leaving 1.4 behind is one of the consequences.
About moving to JPA: yes. I'm all for replacing OJB with either JPA or
JDO2.
Personally, I think JPA still has a long way to go before it can match
JDO2, and JPA has some severe limitations too.
That could well be the case, and I've heard that from other people, but
jpa has some big advantages in terms of availability -- there are
openjpa, toplink, and hibernate all for free whereas AFAIK the only free
jdo2 implementation is the RI. (IMO the reason jpa is here is that
there weren't any good, available, community backed, free jdo1
implementations, opening the door to hibernate...)
Or because the database vendors didn't like it they lost out on the JDO spec
and couldn't impose their own requirements/limitations on it (anymore).
But lets not get into conspiracy theories here :)
I agree JPA has more momentum right now and it is unclear to me if JDO will be
able to keep up with that.
But as an example, at my company one of my colleagues is currently writing a
JDO2 to JCR mapping implementation which seems to come along quite nicely,
something I don't think will be able to do with JPA anywhere soon.
If we can be sure enough JPA can cover our needs though and be
performant too, its OK with me.
I'd be rather surprised if moving to openjpa didn't speed things up :-)
Indeed :)
But please note: what I proposed above for a Jetspeed "light" actually
is (also to) separate out database persistence altogether by factoring
out those dependencies from our component model so we can also provide
an memory or xml/file based storage model.
I'll try not to get ahead of myself here :-). That seems like a good
idea but lets also be careful of introducing more layers than we need.
I wonder if we can have some pojo data objects, with both jpa and jaxb
annotations, then use the classes with jpa for db storage and jaxb for
xml storage.... and nothing for in memory...
Well, in memory might be too far reached, but I definitely want to pursue supporting a
true "light" Jetspeed portal in which for instance the registry,
preferences and security components can maintain their persistent data in xml
or maybe JCR as well.
I'd like to see our components to expose a API generalized enough to be able to support that so that one type of back end store can be replaced for another
other without far reaching repercussions to the rest of the portal core.
The discussion we had on the [EMAIL PROTECTED] list recently about closer cooperation between the pluto and jetspeed team and a possible "light" jetspeed
alternative for what the Pluto Portal is pushed towards is very much at the basis of all this.
Thanks,
Ate
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
