|
From: Andy D. <an...@ma...> - 2004-06-11 17:16:08
|
I've run across a rules package in the Spring sandbox (org.springframework.rules) while working with spring-rcp (spring-rcp uses it for input validation), and was wondering if any thought has been given to integrating it with JSR-94? It is often unfeasable to keep some business logic isolated in a single tier (for example, some business logic ends up being in the UI for validation, some in the service layer, etc). However, it may be possible to avoid duplicating business logic and at least manage it from a central location. I've found that sometimes validation rules are duplicated elsewhere in the system (behind the service facade or in the DB, for example). What if I could keep rules in a central location (a rules DB or a set of XML files on the server), and then serve those rules to whoever needs them? For example, the UI asks for any rules against a particular object that it is editing so it can perform as-you-type validation, while the domain model behind the service facade might ask for the same rules to both validate and operate on data passed in from a client. This way, all my rules are centrally managed, never duplicated, and can be reused. I'm thinking of using such an approach in my next project and basing it off of JSR-94 - but I'd like to use spring and spring-rcp and since spring-rcp relies on org.springframework.rules, it would be nice if the rules package could integrate with JSR-94. I'm just brainstorming at the moment, so I could have missed something... Is this a bad idea? - Andy |
|
From: James C. <jim...@do...> - 2004-06-11 21:06:16
|
Rod, Do you remember this issue? Has this one been addressed yet? http://article.gmane.org/gmane.comp.java.springframework.user/1502 From: Chris Nokleberg <chris <at> sixlegs.com> Subject: Re: CGLIB proxies are not assignable Newsgroups: gmane.comp.java.springframework.user Date: Sun, 11 Apr 2004 17:15:30 +0000 Rod Johnson <rod.johnson <at> interface21.com> writes: > This is the behaviour I would expect. As you say, maybe we should > add it to the docs. All proxies _are_ instances of the class to be > proxied. I actually think this is a bug. If the name of the class is changing it means that caching of generated classes is not working correctly --it is probably generating a new class per proxy. This will obviously slow down proxy creation tremendously and eventually cause OutOfMemoryExceptions. The typical culprit is when you use a custom CallbackFilter that does not implement equals/hashCode. I don't have time right now but I'll take a look soon. Happy Easter Chris |
|
From: Colin S. <col...@ex...> - 2004-06-12 02:02:16
|
James, This is a bug which is fixed in CVS head (post 1.0.2). 1.0.2 and earlier were indeed not caching classes, and I personally ran out of 'Perm' space in an app because of this, but the new code seems to work fine. Make sure you upgrade to the cglib-1.0.2.jar that is in CVS as well. It actually represents CGLIB head, which the new code depends on. James Cook wrote: >Rod, > >Do you remember this issue? Has this one been addressed yet? > >http://article.gmane.org/gmane.comp.java.springframework.user/1502 > >From: Chris Nokleberg <chris <at> sixlegs.com> >Subject: Re: CGLIB proxies are not assignable >Newsgroups: gmane.comp.java.springframework.user >Date: Sun, 11 Apr 2004 17:15:30 +0000 > >Rod Johnson <rod.johnson <at> interface21.com> writes: > > >>This is the behaviour I would expect. As you say, maybe we should >>add it to the docs. All proxies _are_ instances of the class to be >>proxied. >> >> > >I actually think this is a bug. If the name of the class is changing >it means that caching of generated classes is not working correctly >--it is probably generating a new class per proxy. This will obviously >slow down proxy creation tremendously and eventually cause >OutOfMemoryExceptions. The typical culprit is when you use a >custom CallbackFilter that does not implement equals/hashCode. I >don't have time right now but I'll take a look soon. > >Happy Easter >Chris > > |
|
From: Rob H. <ro...@ca...> - 2004-06-14 12:26:09
|
James (All), First I better introduce myself, my name is Rob Harrop and I have been working on the Cglib proxy class, fixing bugs and improving performance. The problem you mention is now fixed, but it does rely on the HEAD of Cglib (which I mistakenly checked into CVS without changing the name). The new CallbackFilter correctly implements hashCode so that Cglib can cache class instances. Rob On 11 Jun 2004, at 22:05, James Cook wrote: > Rod, > > Do you remember this issue? Has this one been addressed yet? > > http://article.gmane.org/gmane.comp.java.springframework.user/1502 > > From: Chris Nokleberg <chris <at> sixlegs.com> > Subject: Re: CGLIB proxies are not assignable > Newsgroups: gmane.comp.java.springframework.user > Date: Sun, 11 Apr 2004 17:15:30 +0000 > > Rod Johnson <rod.johnson <at> interface21.com> writes: >> This is the behaviour I would expect. As you say, maybe we should >> add it to the docs. All proxies _are_ instances of the class to be >> proxied. > > I actually think this is a bug. If the name of the class is changing > it means that caching of generated classes is not working correctly > --it is probably generating a new class per proxy. This will obviously > slow down proxy creation tremendously and eventually cause > OutOfMemoryExceptions. The typical culprit is when you use a > custom CallbackFilter that does not implement equals/hashCode. I > don't have time right now but I'll take a look soon. > > Happy Easter > Chris > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the > one installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |