Good deal! On Tue, Dec 16, 2008 at 12:21 PM, Daniel Mueller <[email protected]>wrote:
> > 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" <[email protected]> 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 > > <[email protected]>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" <[email protected]> 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 > > > > <[email protected]>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" <[email protected]> > 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 > > > > > > <[email protected]>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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
