I've uploaded a revised patch for ROL-1482 that includes jndi setup
for the planet EMF. It also keeps the current non-jndi EMF setup by
default, since I figured out how to override this in the geronimo
plugin.
It would be really great to get this into the next roller release as
then we can release a geronimo-roller plugin.
onto the build stuff...
many thanks
david jencks
On Jul 20, 2007, at 3:57 PM, David Jencks wrote:
On Jul 20, 2007, at 6:44 AM, Dave wrote:
On 7/18/07, David Jencks <[EMAIL PROTECTED]> wrote:
I've been working with Peter Petersson to get roller 4 running on
geronimo 2, and we've now succeeded. As a result we have some ideas
to make roller more javaee friendly and geronimo friendly.
1. Provide an option to look up the EntityManagerFactory in jndi
rather than constructing it through java code. Generally in ee5 app
servers you want to use the ee5 mechanisms to access the ee5
features :-) so just as there is an option to look up the datasource
in jndi rather than using a Driver class directly, it would be great
to have the option to look up the EMF in jndi as well. I don't
see a
convenient way to use the ee5 injection features since AFAICT there
aren't any managed objects (servlets, filters, listeners, or jsf
managed beans) very near the code that needs the EMF. I've
implemented this and it works in geronimo, see ROL-1482. The only
possibly objectionable part of this patch I can imagine is the
switch
to the servlet 2.5 schema for the persistence unit ref. In geronimo
at least we can work around a 2.4 web.xml if you don't want to
upgrade yet: the remainder of the patch would still be extremely
helpful.
I don't think we want to require 2.5 yet.
Thanks for the contribution, but I'm -1 on the patch because it does
not address how to configure the EMF used by the Planet subsystem.
True... I wonder why the app worked on geronimo since the
proprietary emf configuration in roller itself doesn't work on
geronimo. Anyway I'm fixing this. Since what I tried worked
without planet its not entirely sure I'll be able to figure out if
the change works.
I'm not necessarily opposed to making the EMF configurable, but I
don't need it and I'm not prepared to test it -- so I'm not overly
inclined to apply the patch even when it handles both RollerPU and
PlanetPU.
Do you personally use and test both the jndi datasource lookup and
the Driver ways of getting a jdbc connection?
Out of curiousity, what advantage does looking up the EMF instead of
the DataSource via JNDI give to our users?
Anyone who has used a javaee5 container is going to be used to
configuring jpa using persistence.xml rather than the well-hidden
properties files proprietary to roller/planet. Also your
configuration system doesn't actually let you set very much such as
non-jta-datasource or persistence provider. In geronimo at any
rate (I haven't looked at other servers) you can override most of
the contents of persistence.xml in the geronimo plan without
modifying the persistence.xml in the web app itself. Even without
this, modifying a couple of persistence.xmls to use say Kodo is a
lot easier than trying to find the code that currently decides
which persistence provider to use, modifying it, and figuring out
what you need to build to get it into the final product.
2.jpa mapping info. I notice you are currently using orm.xml files.
Do you have plans to move to annotations, and is anyone working on
that? Also IIUC it's possible to make the annotations or orm files
match the script generated schema more closely by including stuff
like column sizes, does anyone have an opinion on if that is
desirable?
I think consensus is that annotations are better here, but we haven't
had the time yet to move from XML files to annotations.
In the unlikely event I have some spare time I may work on a patch
for this.
3. For deployment in geronimo, and use in a geronimo plugin, we need
to get at at least the roller war and possibly some inner details
such as the core jar. It would be most convenient for us if these
were available through a maven repository. So this leads to the
questions...
3a. Would you consider including some use of the maven ant tasks in
the ant build scripts to get various artifacts into maven
repositories?
Yes.
Thanks, I'll work on this.
3b Are you completely thrilled with the ant build or would you be
interested in considering a maven build system?
I satisfied with Ant and have had nothing but trouble with Maven.
Every time I've used it I've run into problems that I could not debug
due to its black-box nature.
I understand there are advantages to moving to Maven, and all of my
previous troubles might have been stupid user-error on my part,
but at
this time I'm not interested in doing the work to rewrite the build.
If somebody else did the work, I'd be happy to consider their
patch/branch.
This might be a longer term goal.... lets start small
thanks
david jencks
- Dave
