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 -~----------~----~----~----~------~----~------~--~---