Re: roller + javaee + geronimo

[David Jencks <da...@yahoo.com>]

Since it looks like 4.0 may appear soon I'm appealing again for some  
committer to take a look at committing this and thus allow roller to  
run properly in javaee environments in particular geronimo.

The change is really really simple, of the form

if (newflag = "true") {
   new behavior
} else {
   old behavior
}
so it seems rather unlikely to me that it could break any existing  
functionality.

thanks
david jencks

On Jul 24, 2007, at 11:49 AM, Dave wrote:

> I may not have time for this for the next week or so.
>
> Any committers want to volunteer to help out and evaluate this patch?
>
> - Dave
>
>
>
> On 7/21/07, David Jencks <da...@yahoo.com> wrote:
>> 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 <da...@yahoo.com> 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
>> >
>>
>>

Re: roller + javaee + geronimo

[Dave <sn...@gmail.com>]

On 8/7/07, David Jencks <da...@yahoo.com> wrote:
> Since it looks like 4.0 may appear soon I'm appealing again for some
> committer to take a look at committing this and thus allow roller to
> run properly in javaee environments in particular geronimo.
>
> The change is really really simple, of the form
>
> if (newflag = "true") {
>    new behavior
> } else {
>    old behavior
> }
> so it seems rather unlikely to me that it could break any existing
> functionality.

I'm +1 on this assuming that the code is reviewed properly and looks
good, but I need to wrap up my 4.0 work immediately and fixing bugs
takes priority for me.

- Dave