Mmh, the commons-logging problem you can neatly circumnavigate with
SLF4J and the appropriate bridges. And I absolutely agree with you,
this is not the preferred solution, nor the one that will win you the
style award, but it's probably the one that you can get up and running
with the least effort and reinventing the wheel portion. Might also be
just an intermediate solution or something that is in a contrib folder
somewhere (same status as your current non-Record JPA efforts
probably).
Aye, anyway, I think we agree on what the advantages and disadvantages
are and can look around for solutions that are neater. If I come up
with something I'll post it.
Daniel
On Dec 16, 9:28 pm, "Derek Chen-Becker" <dchenbec...@gmail.com> wrote:
> Don't get me wrong, I've used Spring before to great benefit. My biggest
> concern is that it uses commons-logging, which complicates logging config a
> bit.It also expands the POM via those dependencies. Bottom line: I'd like to
> avoid it if we can, but I don't have a problem if it ends up being the best
> way to do it.
>
> Derek
>
> On Mon, Dec 15, 2008 at 10:08 PM, Daniel Mueller
> <dan.in.a.bot...@gmail.com>wrote:
>
>
>
> > I know what you mean, I have the same feelings about it. Spring can be
> > a big mess (it's pretty certainly making a mess of your classpath with
> > all those deps). On the other hand, I just tried to find out how big a
> > mess it actually would be. It's substantial but not frightening IMO.
> > Adding the spring dependencies (only the relevant ones) is adding
> > almost the same as the hibernate.jar alone.
> > aopalliance-1.0.jar
> > commons-logging-1.1.1.jar
> > spring-beans-2.5.6.jar
> > spring-context-2.5.6.jar
> > spring-core-2.5.6.jar
> > spring-orm-2.5.6.jar
> > spring-tx-2.5.6.jar
> > ~= 1.8M
>
> > hibernate-3.2.6.ga.jar
> > ~= 2.2M
>
> > I didn't include annotations and EM on the hibernate side, they add
> > together something like 200k, and I might have missed something on the
> > spring side (the rest of the deps are optional, some might be needed
> > though).
>
> > Not really arguing here, just trying to not get into FUD.
>
> > Daniel
>
> > PS: I just did that with downloading from the maven repo directly, but
> > if you have a working project you want to inspect the jars from: get
> > the executed commandline somehow, split in vi with ":%s/:/^M/
> > g" (that's CTRL-V CTRL-M), save to cp.txt, then "cp `grep spring
> > cp.txt` ." or whatever you like ("du `grep spring cp.txt` | sort -
> > nr"). Nice way to check your classpath.
>
> > On Dec 16, 5:32 am, "Derek Chen-Becker" <dchenbec...@gmail.com> wrote:
> > > That may be workable but I have to recoil a little when we talk about
> > > bringing Spring into the mix. It has its purpose but I would hate to make
> > it
> > > an implicit requirement of using Record with JPA; it's just huge.
>
> > > Derek
>
> > > On Mon, Dec 15, 2008 at 12:46 PM, Daniel Mueller
> > > <dan.in.a.bot...@gmail.com>wrote:
>
> > > > I never did it with JPA, that's why I mentioned that there might be
> > > > some problems to circumnavigate (my websearch turned up that it's not
> > > > possible, but I might have missed something). But on the actual
> > > > backend frameworks you can do things like that (or at least hibernate
> > > > can [1,2, also see 3 below]).
>
> > > > The best resource to describe what we want to do is Spring ORM [3].
> > > > They had the same problem and describe the caveats with it (see the
> > > > text box for loadtime weaving under the JPA section). If we would run
> > > > our generation through Spring ORM we should probably get away with a
> > > > Record-only setup, where Record boots Spring ORM with dynamic classes
> > > > (Maps) and configures the desired backend. The nice thing would be
> > > > that Spring is already aware of which backend you use and optimizes
> > > > accordingly.
>
> > > > I don't really like the fact that this adds a truckload of
> > > > dependencies to the stack (spring-{orm,beans,context,core,tx} are
> > > > required, couple more optional), but it's the easiest solution I can
> > > > think of in terms of integration and timerequirements, and it should
> > > > also be pretty stable and straightforward to use for the users (Spring
> > > > has nice documentation IMO). Oh, and just if you were wondering, this
> > > > is the supported frameworks list: Hibernate, JDO, Oracle TopLink,
> > > > iBATIS SQL Maps and JPA. The biggies are supported without even going
> > > > through JPA. Sweet.
>
> > > > Daniel
>
> > > > [1]http://forums.oracle.com/forums/message.jspa?messageID=2432779
> > > > [2]http://wiki.eclipse.org/Eclipselink/Examples/JPA/Dynamic
> > > > [3]
> >http://static.springframework.org/spring/docs/2.5.x/reference/orm.html
>
> > > > On Dec 15, 9:41 pm, "Derek Chen-Becker" <dchenbec...@gmail.com> wrote:
> > > > > I've been thinking a little about the XML path and there may be a
> > > > wrinkle.
> > > > > No matter how you define the XML mappings, JPA expects persistable
> > fields
> > > > to
> > > > > either be real fields (var) on the instance or getter/setter pairs;
> > using
> > > > an
> > > > > object for field a la Record still isn't either of these. I have a
> > busy
> > > > few
> > > > > weeks ahead but I'm going to do some reading in the meantime and see
> > if
> > > > we
> > > > > can come up with something transparent but easy to use.
>
> > > > > Derek
>
> > > > > On Mon, Dec 15, 2008 at 12:39 AM, Daniel Mueller
> > > > > <dan.in.a.bot...@gmail.com>wrote:
>
> > > > > > (Reactivating discussion. I guess it's been discussed more on the
> > > > > > committer list, but here you have my 2 cents anyway)
>
> > > > > > For the sake of the Record-JPA discussion, people will fall into
> > two
> > > > > > categories when they are using lift:
> > > > > > * The first group of people have an existing, working, tested
> > JPA/OR
> > > > > > based data access library written in Java and are looking to
> > integrate
> > > > > > that with a webapp written in lift. They will usually be coming
> > from
> > > > > > an enterprise background, and will have some constraints on what
> > they
> > > > > > can develop from scratch ("no - we will not rewrite all the db
> > access
> > > > > > code to support the new web framework").
> > > > > > * The second group doesn't have an existing data access library in
> > > > > > Java and would like to write all their new stuff with lift in
> > Scala.
> > > > > > But maybe they have mapping/usage requirements that precludes using
> > > > > > mapper because it's too simple, or they just know their way around
> > one
> > > > > > of the other JPA enabled OR libs and want to bank on that knowledge
> > > > > > (without writing the entire layer in Java).
> > > > > > * The third group also doesn't have an existing data access
> > library,
> > > > > > but for some reasons, they want their OR model not only be
> > accessible
> > > > > > from lift, but actually also from Java code. This means that they
> > not
> > > > > > only have to be able use JPA, but that the Scala code they write
> > has
> > > > > > to be _JPA compatible_ (Java usable JPA entities etc.).
>
> > > > > > For the first group, some sort of delegation strategy from the
> > Record
> > > > > > entity to the JPA entity is necessary (unless you can mixin the
> > record
> > > > > > stuff on top of an actual JPA entity?). The JPA/OR configuration is
> > > > > > already in place on the existing lib (annotations/xml). The only
> > thing
> > > > > > that record is doing is adding another layer on top of it for
> > > > > > validation, binding to UI, maybe querying. Something like what was
> > > > > > proposed earlier by Derek should be enough
>
> > > > > > > class MyEntry extends Record[MyEntry] {
> > > > > > > var inner : RealEntry = _
>
> > > > > > > object name extends StringField(this) with Delegation
> > > > > > > name.delegate(inner.name, inner.name = _)
>
> > > > > > > ...
> > > > > > > }
>
> > > > > > Now for the second group, they probably would like to have all the
> > > > > > power associated with a JPA/OR framework without resolving to
> > writing
> > > > > > that layer in Java. Mind you that this is quite a different problem
> > > > > > from what the first group wants to solve.
> > > > > > * They just want to have Record entities, no separate JPA entity,
> > no
> > > > > > delegation.
> > > > > > * They don't want to duplicate configuration from what they already
> > > > > > specify on Record entities.
> > > > > > * Have the integration as hassle free as possible, because in their
> > > > > > eyes, there is no actual delegation.
>
> > > > > > What the second group needs is a bit trickier, and most of the
> > > > > > discussion has revolved around how to make it as transparent as
> > > > > > possible (compiler plugins, byte code weaving, etc.).
>
> > > > > > Remember that for the second group of people Record is attempting
> > to
> > > > > > solve the _exact same problem_ as JPA. It's a unifying frontend,
> > that
> > > > > > abstracts away differences in persistence libraries. And as with
> > JPA,
> > > > > > Record has the configuration present in code (instead of
> > annotations
> > > > > > it just uses actual subclasses and parameters, but still).
>
> > > > > > But there's one thing that has only been mentioned on the off by
> > > > > > David.
>
> > > > > > > I believe there are ways to use Record's deep knowledge of class
> > > > layouts
> > > > > > to
> > > > > > > generate data structures and/or XML to send to JPA to "do the
> > right
> > > > > > thing."
>
> > > > > > The key point here is XML. While those annotations are a nice
> > feature
> > > > > > for the programmer to get rid of the XML configuration from pre EJB
> > > > > > 3.0, it's less than sexy for attaching a unified API (record) to an
> > > > > > implementation library (jpa, which incidentially is another unified
> > > > > > API for the actual OR libs :/ ). But that's a feature for the
> > > > > > developer who doesn't want to specify the configuration in an XML.
> > But
> > > > > > the XML configuration capability is still there. Generating XML
> > from
> > > > > > Record entities (maybe even in memory) to boot the JPA/OR lib
> > should
> > > > > > be pretty easy and doesn't require more opaque techniques (compiler
> > > > > > plugin, byte code weaving). And it can be overridden easily as
> > well
> > > > > > even to integrate things that are not supported in Record.
> > > > > > I'm not well versed enough in JPA to make statements about whether
> > the
> > > > > > XML configuration is feature complete compared to the annotations,
> > and
> > > > > > how flexible the mapping can be (directly from the Record object
> > > > > > fields to the columns). I would assume that the mapping is not
> > > > > > flexible enough to work with the objects fields from Record, but
> > maybe
> > > > > > we can start discussing strategies to solve that (using vars,
> > > > > > generating bytecode, using untyped maps as entities, generating OR
> > lib
> > > > > > specific XML - And yes I know that with a
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
