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 couple of those you loose
> > > > > some features provided by JPA).
> >
> > > > > For the third group of people, those that want to use reuse their
> > > > > objects as Java compatible JPA entities: Do we really need that
> right
> > > > > now? Are there enough real use cases to warrant the effort? Mind
> that
> > > > > you can always write a Java compatible access layer for your
> entities
> > > > > in Scala. In that layer you refrain from using stuff that Java
> doesn't
> > > > > like and then just use that connector from your java code. IMO lift
> > > > > shouldn't solve that problem. Although it's interesting, I don't
> > > > > really see the benefit of having actual JPA object usable from
> Java.
> > > > > As already discussed on the list, there's a whole bunch of
> > > > > compatibility problems to make the Record entity be an actual JPA
> > > > > entity. If we find out that solving the problem for the second
> group
> > > > > is only possible if we solve this one, then fine, otherwise I
> > > > > personally wouldn't bother to fix that thing now. You can code
> around
> > > > > it and it shouldn't be that much of a problem to do so.
> >
> > > > > Pick your battles...
> >
> > > > > Daniel
> >
> > > > > On Dec 2, 1:22 am, "David Pollak" <feeder.of.the.be...@gmail.com>
> > > > > wrote:
> > > > > > My 2 cents:
> >
> > > > > > - I'm strongly opposed to any compiler plugins as they (1)
> mean
> > > that
> > > > > IDEs
> > > > > > will work less well and (2) they require some sort of
> installation
> > > (if
> > > > > they
> > > > > > can be rolled into the Maven building stuff, it makes this
> > > objection
> > > > > go
> > > > > > away)
> > > > > > - I'm strongly opposed to mixing annotations and the Record
> stuff.
> > > > > It'll
> > > > > > just make for wicked ugly looking code.
> >
> > > > > > 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."
> >
> > > > > > On Sun, Nov 30, 2008 at 7:45 AM, Derek Chen-Becker <
> > > > > dchenbec...@gmail.com>wrote:
> >
> > > > > > > The whole point of integrating (and I use the word integrating
> here
> > > > > > > loosely) is so that there's a common form framework for people
> to
> > > use.
> > > > > > > Really, the point of Record as far as I can tell is to loosen
> > > and/or
> > > > > remove
> > > > > > > the tight coupling with the datastore, and in that sense Record
> is
> > > > > > > succeeding. As Tim points out, there are going to be people
> with
> >
> > ...
> >
> > 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
-~----------~----~----~----~------~----~------~--~---
