Menu
▾
▴
springframework-developer
|
From: Cameron B. <ca...@da...> - 2003-12-15 03:22:55
|
The .classpath points to an non existant velocity-1.3.jar... there is a velocity-1.3.1.jar there, which even after changing to, doesn't fix all classpath errors. Cameron -- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] |
|
From: Colin S. <col...@ex...> - 2003-12-15 04:01:55
|
As per my other emails, I haven't gotten any emails on the list over the weekends, so I don't know what people are workin on, but I guess the Eclipse breakage is probably from one of the non-Eclipse guys (Juergen?). I've added back in a link to velocity 1.3.1 and the velocity tools. I also added in a link to the common-attributes, which seems to be needed now. At this point all is ok except for some sandbox code, which still has errors, BCELAttributes, PersonJava, AttributesWriterTests, and CompilerTests. I am not attempting to fix those since I don't know what the intent is. As per discussion last week, they are going away, and I think Rod or somebody just accidentally left them in... Cameron Braid wrote: > The .classpath points to an non existant velocity-1.3.jar... there is > a velocity-1.3.1.jar there, which even after changing to, doesn't fix > all classpath errors. > > Cameron > |
|
From: Cameron B. <ca...@da...> - 2003-12-15 04:12:20
|
Thankyou for the prompt reply. Most appreciated. Cameron Colin Sampaleanu wrote: > As per my other emails, I haven't gotten any emails on the list over > the weekends, so I don't know what people are workin on, but I guess > the Eclipse breakage is probably from one of the non-Eclipse guys > (Juergen?). > > I've added back in a link to velocity 1.3.1 and the velocity tools. I > also added in a link to the common-attributes, which seems to be > needed now. > > At this point all is ok except for some sandbox code, which still has > errors, BCELAttributes, PersonJava, AttributesWriterTests, and > CompilerTests. I am not attempting to fix those since I don't know > what the intent is. As per discussion last week, they are going away, > and I think Rod or somebody just accidentally left them in... > > > Cameron Braid wrote: > >> The .classpath points to an non existant velocity-1.3.jar... there is >> a velocity-1.3.1.jar there, which even after changing to, doesn't fix >> all classpath errors. >> >> Cameron >> > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > -- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] |
|
From: Alef A. <al...@jt...> - 2003-12-15 23:09:19
|
All, Two questions. First of all, we're having an app here based on some proprietary tech that we've wrapped in Spring. It's transparently using either POJOs or EJBs (when using EJBs the POJOs are just wrapped by en EJB, thus enabling easy clustering and more stuff like that). However, we're using the HibernateSessionFactory and don't know when to close the session when using an EJBs instead of POJOs. I found this solution on hibernate website in the documentation about spring combined with hibernate (having a ThreadLocal threadcounter that you're increasing and decreasing everytime a different EJB is entered or left). But it doesn't sounds like a decent approach (Chris Bauer - I guess - also advised against it). I could use long transactions, but that's a hassle as well. So anybody has any opinions on how to keep track of when to close the session when doing for one web-call that does an ejb-call that does another ejb-call (both of which do something hibsession related)? Ok, the second one involves the ApplicationContext. I've divided my beans across a lot of files (in order to keep them modular) and I'm loading them in all different kinds of places using the for example the ClasspathAppCtx (and providing it with an array of context locations). However, it's difficult avoiding circular references! Suppose there's two app contexts, A and B. In A there's bean 1 depending on bean 2 in B. In B, there's bean 3, depending on bean 4 in A. This is circular, however, I still want to somehow be able to do this. Basically the BeanFactory stops processing bean definitions if it can't find a bean reference that might be located in a sibbling context. I tend to state that the bean definition creation should postponed until all sibbling-contexts are resolved and maybe then try it again? Any suggestions (or just 'no not possible' will do as well :) Alef |
|
From: Rod J. <rod...@in...> - 2003-12-15 08:36:50
Attachments:
TxClassWithClassAttribute.java
|
Colin, Thanks for fixing the Eclipse path--Juergen did the Velocity changes, but for some reason I seem to have a blind spot when I change the Eclipse classpath myself. We mainly want those broken files in the sandbox for the history. I'll probably just comment the content out. The reason that we now depend on Commons Attributes is that we now have a simple facade interface (org.springframework.metadata.Attributes) behind which we can have pluggable attributes implementations (including our own post 1.0, and JSR-175). I've now implemented this interface for Commons Attributes. This is now used as the basis of .NET-style attribute-driven transaction management and pooling as I've wanted for quite a while, and like the old "enterprise services" package, which is now gone from the sandbox. See the attached file for an example. The build script and XML bean definitions in that package in the test tree illustrate how Commons Attributes is used to compile the sources, and how AOP autoproxying is configured to do this. I'll make a post to describe this functionality properly later this week--I think it's quite important. The attribute-driven layer over our generic AOP autoproxying support (now in org.springframework.aop.autoproxy) is very thin. Regards, Rod ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> To: <spr...@li...> Sent: Monday, December 15, 2003 4:02 AM Subject: Re: [Springframework-developer] Eclipse build broken > As per my other emails, I haven't gotten any emails on the list over the > weekends, so I don't know what people are workin on, but I guess the > Eclipse breakage is probably from one of the non-Eclipse guys (Juergen?). > > I've added back in a link to velocity 1.3.1 and the velocity tools. I > also added in a link to the common-attributes, which seems to be needed now. > > At this point all is ok except for some sandbox code, which still has > errors, BCELAttributes, PersonJava, AttributesWriterTests, and > CompilerTests. I am not attempting to fix those since I don't know what > the intent is. As per discussion last week, they are going away, and I > think Rod or somebody just accidentally left them in... > > > Cameron Braid wrote: > > > The .classpath points to an non existant velocity-1.3.jar... there is > > a velocity-1.3.1.jar there, which even after changing to, doesn't fix > > all classpath errors. > > > > Cameron > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
