springframework-developer — Spring Framework developers list

[Springframework-developer] DisposableBean / destroy-method -> never gets called

[Roman R. <r.r...@we...>]

Hi Spring developers!

I=B4m using Spring for my current WebApp project and I found a strange behav=
iour of Spring.

I=B4m not sure if I=B4m doing something wrong or if it=B4s a bug. So, perhaps yo=
u can take a look at.

First, here is my posting in the Spring forum which describes my problem:
http://forum.springframework.org/viewtopic.php=3Ft=3D5003

I tried to debug Spring to track the problem down. Here=B4s what I have:

1. All beans which are implementing the interface DisposableBean are store=
d in the map AbstractBeanFactory.disposableBeans. But the method AbstractB=
eanFactory.destroySingletons() gets only called for the factory "-servlet.=
xml", not for the other two xml files.

2. On shutdown, ContextLoaderListener.contextDestroyed() calls ContextLoad=
er.closeWebApplicationContext(). But=20

servletContext.getAttribute(WebApplicationContext.ROOT=5FWEB=5FAPPLICATION=5FCON=
TEXT=5FATTRIBUTE);

always returns null. Perhaps the ServletContext is destroyed when the List=
ener gets informed=3F While my app is running,=20

servletContext.getAttribute(WebApplicationContext.ROOT=5FWEB=5FAPPLICATION=5FCON=
TEXT=5FATTRIBUTE);

returns the correct application context.

I=B4m shutting down my webapp with the url:=20
http://localhost:8080/manager/stop=3Fpath=3D/mywebapp

My environment:
Tomcat 5.5.7
Java 1.5
Spring 1.2RC1

Please let me know if you need more information.


Best regards,

Roman

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/=3Fmc=3D021193

RE: [Springframework-developer] EJBs vs POJOs

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

I do use ant to build but now that I am getting familiar with appfuse I =
will
need to convince other developers who are using JBuilder to develop =
their EJB
apps. I have been using ant and IntelliJ for a a while now.=20





-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Eugene Kuleshov
Sent: Friday, April 22, 2005 12:21 PM
To: spr...@li...
Subject: Re: [Springframework-developer] EJBs vs POJOs


Garvey, Paul M (GE Commercial Finance) wrote:

> Dmitriy,
>         I haven't had a chance to look at Spring EJB support as yet=20
> but it sounds
> interesting, Will be reading about Spring support this weekend. IDEs=20
> such as JBuilder
> makes EJB development very easy, testing aside, is Spring EJB support=20
> easier to code
> than straight EJBs?=20

  Paul, don't you think that rely your development on IDE is a bad idea? =

I believe it is better to setup a common build process (XDoclet,=20
MiddleGen, Cactus, Ant/Maven, etc) and do not rely on concrete IDE.

  By the way, I have strange feeling about current Spring's EJB=20
convenience classes. The idea is that they will automatically lookup=20
Spring's application context for you and then you'll use=20
getBeanFactory().getBean() in onEjbCreate() method to pull pring-managed =

POJO. However it require java:comp/env/ejb/BeanFactoryPath env property=20
to be set and also custom implementation setSessionContext() in order to =

make bean factory a singleton (I don't know who would want non-singleton =

factory?).
  So, we've ended up with our own EJBM helper classes (very similar to=20
the Spring but without factory ) and a custom SpringLocator singleton=20
that I'm using in onEjbCreate() methods instead:

public class SpringLocator {
    private static final ApplicationContext context =3D new=20
ClassPathXmlApplicationContext( CONTEXT_PATH);

    public static Object getBean(String id) {
        return context.getBean(id);
    }
....

  In this case I don't have to override setSessionContext in every bean. =

That of course only makes sence and should be used only on facade beans=20
(session/mdb or transaction) and all inner components should use DI and=20
not locator.

  regards,
  Eugene




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] dynamic attibutes

[Otto v. W. <vo...@gm...>]

Sorry for the cross post, I think this email is more appropriate for
the dev list.  I appreciate any input (if this makes sense, I'm can
contribute code for this)

I was trying to figure a simple way to use attributes for AOP in 1.4
that doesn't require an extra compilation step, and I came up with a
dynamic approach:

In my spring configuration, I just set some attributes like this:

<bean id=3D"exampleService"
   class=3D"com.foo.ExampleCachingService">
   <property name=3D"methodAttributes"><map>
       <entry key=3D"getFoo"><list>
           <value>org.wanghy.cache.interceptor.caching.Cached("test")</valu=
e>
           <value>...interceptor.DefaultTransactionAttribute()</value>
       </list></entry>
   </map></property>
</bean>

I have a BaseDynamicAttributedBean, that initializes the attributes:

   public void setMethodAttributes(Map methodAttributes) {
       this.methodAttributes =3D methodAttributes;
   }

   public void afterPropertiesSet() throws Exception {
      DynamicAttributes.initAttributes(this.getClass(), methodAttributes);
   }

The implementation of DynamicAttributes (which implements
org.springframework.metadata.Attributes) uses an java interpreter to
evaluate the attribute definition (right now I'm using Groovy, but it
could use anything like Janino or BeanShell).  I'm also planning on
adding some error checking, like making sure that there isn't more
than one bean trying to set attributes for a given class, making sure
method names aren't ambigous, etc.

I had two reasons for wanting to do this: 1) using java 1.5 isn't an
option on the project I'm working on, and we wanted to avoid the
additional compilation step of using commons attributes. 2) there's a
percieved desire/preference in my project to be able to configure AOP
in XML, and I think that the other ways to configure interceptors in
XML is kind of confusing and verbose.

I ran some tests and it seems to work fine.  My question is, does
anyone see any potential pitfalls with this approach?

thanks,
Otto

RE: [Springframework-developer] EJBs vs POJOs

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

Dmitriy,
       Thanks for the link i will be reading this weekend between =
cutting my lawn :-)
Paul =20



-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Dmitriy Kopylenko
Sent: Friday, April 22, 2005 11:20 AM
To: spr...@li...
Subject: Re: [Springframework-developer] EJBs vs POJOs




 IDEs such as JBuilder
makes EJB development very easy, testing aside, is Spring EJB support =
easier to code
than straight EJBs?=20
=20

It certainly is :-) Here is a good place to start: =
http://www.springframework.org/docs/reference_1.2RC2/ejb.html

Regards,
Dmitriy.

Re: [Springframework-developer] EJBs vs POJOs

[Eugene K. <eu...@ja...>]

Garvey, Paul M (GE Commercial Finance) wrote:

> Dmitriy,
>         I haven't had a chance to look at Spring EJB support as yet 
> but it sounds
> interesting, Will be reading about Spring support this weekend. IDEs 
> such as JBuilder
> makes EJB development very easy, testing aside, is Spring EJB support 
> easier to code
> than straight EJBs? 

  Paul, don't you think that rely your development on IDE is a bad idea? 
I believe it is better to setup a common build process (XDoclet, 
MiddleGen, Cactus, Ant/Maven, etc) and do not rely on concrete IDE.

  By the way, I have strange feeling about current Spring's EJB 
convenience classes. The idea is that they will automatically lookup 
Spring's application context for you and then you'll use 
getBeanFactory().getBean() in onEjbCreate() method to pull pring-managed 
POJO. However it require java:comp/env/ejb/BeanFactoryPath env property 
to be set and also custom implementation setSessionContext() in order to 
make bean factory a singleton (I don't know who would want non-singleton 
factory?).
  So, we've ended up with our own EJBM helper classes (very similar to 
the Spring but without factory ) and a custom SpringLocator singleton 
that I'm using in onEjbCreate() methods instead:

public class SpringLocator {
    private static final ApplicationContext context = new 
ClassPathXmlApplicationContext( CONTEXT_PATH);

    public static Object getBean(String id) {
        return context.getBean(id);
    }
....

  In this case I don't have to override setSessionContext in every bean. 
That of course only makes sence and should be used only on facade beans 
(session/mdb or transaction) and all inner components should use DI and 
not locator.

  regards,
  Eugene

Re: [Springframework-developer] EJBs vs POJOs

[Dmitriy K. <dko...@ru...>]

>  IDEs such as JBuilder
> makes EJB development very easy, testing aside, is Spring EJB support 
> easier to code
> than straight EJBs? 
>  

It certainly is :-) Here is a good place to start: 
http://www.springframework.org/docs/reference_1.2RC2/ejb.html

Regards,
Dmitriy.

RE: [Springframework-developer] EJBs vs POJOs

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

Dmitriy,
        I haven't had a chance to look at Spring EJB support as yet but =
it sounds
interesting, Will be reading about Spring support this weekend. IDEs =
such as JBuilder
makes EJB development very easy, testing aside, is Spring EJB support =
easier to code
than straight EJBs?=20
=20
Paul=20
=20

=20



-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Dmitriy Kopylenko
Sent: Thursday, April 21, 2005 6:25 PM
To: spr...@li...
Subject: Re: [Springframework-developer] EJBs vs POJOs


To put simply - if you absolutely require to physically distribute your =
application, EJB (SLSB facade) would probably be the good choice here. =
Please note that you still would want to use Spring-EJB support as it =
transparently exposes your POJO business interfaces as EJB =
implementations (via proxies) and also frees the application code from =
low level plumbing code related to EJB programming model e.g. JNDI =
lookups, etc. Coupled with IoC container (for DI) you get easy testable =
code with minimal dependence on EJB container.

Regards,
Dmitriy.

Garvey, Paul M (GE Commercial Finance) wrote:=20

James,

      Your response was insightful and you did partially answered my =
question.

Let me try to be a bit clearer, If I had to create an application that =
needed to

be distributed across multiple machines I would normally use EJBs =
(stateless Bean + Entity Beans)

or (stateless beans + DAOs) or (stateless beans + hibernate) etc. Could =
I use Spring

in this senario? Would it make more sense to stick with the EJB =
paradigm? I want to have a clear picture=20

in my mind of when to use Spring on a project and when to use EJBs. In =
other words,=20

when does it make most sense to use EJBs instead of Spring and vice =
versa?

Are there times when Spring is just not the solution to the problem and =
EBJ is?



Paul











-----Original Message-----

From:  spr...@li...

[ mailto:spr...@li...]On Behalf

Of James Cook

Sent: Thursday, April 21, 2005 5:25 PM

To:  spr...@li...

Subject: RE: [Springframework-developer] EJBs vs POJOs





Spring simply provides a convenient fa=E7ade to other persistence

implementations, including EJB!



You may have meant Entity Beans when you stated EJB. If so, another

way of wording your question is, "Are there cases when EJB is

preferred as a persistence mechanism over a POJO persistence

(Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)

mechanism?"



Take these with a grain of salt, since I don't have hands-on

experience with all of the POJO persistence mechanisms. A few benefits

don't come easily to the world of POJO persistence.



a) POJO-based approaches (AFAIK) with the exception of EJB3, do not

support distributed security contexts. Even if you were writing an EJB

implementation, you would want to limit the number of network calls

your app has to make. But if you really have part of your application

on one machine, and part on another, you can invoke EJB's on the

various machines and remain within the same security context.



b) Clustered sessions are still the realm of the J2EE container.

Distributed caching of persistent object between machines is difficult

to achieve using POJO persistence.



c) Support for CORBA clients is a standard feature of J2EE.



There may be more. Of course, EJB3 will probably turn this discussion

on its ear.



If I totally missed your point, and you just wanted to know if Spring

provided lightweight (sorry Hani) alternatives for the specification

components that make up Enterprise Java Beans (EJB), namely:



- Stateless Session Bean (yes, via service interfaces, pojos you write)

- Stateful Session Bean (no)

- Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)

- Message Driven Bean (No, AFAIK)

- Timer Bean (yes, via quartz)

- Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, =
maybe

others)









 =20

-----Original Message-----

From:  spr...@li...

[ mailto:spr...@li...] On=20

Behalf Of Garvey, Paul M (GE Commercial Finance)

Sent: Thursday, April 21, 2005 3:53 PM

To:  spr...@li...

Subject: [Springframework-developer] EJBs vs POJOs



All,



I fairly new to Spring and I am currently reading some documentation=20

on it. I have bought into the concept of the lightweight feature of=20

Spring. I do have a quick question, Springs seems to handle every=20

scenario that I would

use EJBs, is there a few cases where EJBs are unavoidable to use? In =
other

words

are there any scenarios where Spring is just not the best tool to use =
and

EJBs is

the more suited? Any thoughts?



Paul

















-------------------------------------------------------

SF email is sponsored by - The IT Product Guide

Read honest & candid reviews on hundreds of IT Products from real=20

users. Discover which products truly live up to the hype. Start=20

reading now.  http://ads.osdn.com/?ad_ide95 =
<http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick> =
&alloc_id=14396&op=3Dick

_______________________________________________

Springframework-developer mailing list=20

Spr...@li...

https://lists.sourceforge.net/lists/listinfo/springframework-developer

   =20





-------------------------------------------------------

SF email is sponsored by - The IT Product Guide

Read honest & candid reviews on hundreds of IT Products from real users.

Discover which products truly live up to the hype. Start reading now.

http://ads.osdn.com/?ad_ide95 =
<http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick> =
&alloc_id=14396&op=3Dick

_______________________________________________

Springframework-developer mailing list

Spr...@li...

https://lists.sourceforge.net/lists/listinfo/springframework-developer





-------------------------------------------------------

SF email is sponsored by - The IT Product Guide

Read honest & candid reviews on hundreds of IT Products from real users.

Discover which products truly live up to the hype. Start reading now.

http://ads.osdn.com/?ad_ide95 =
<http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick> =
&alloc_id=14396&op=3Dclick

_______________________________________________

Springframework-developer mailing list

Spr...@li...

https://lists.sourceforge.net/lists/listinfo/springframework-developer

 =20

Re: [Springframework-developer] help

[Thomas V. de V. <tho...@gm...>]

What's the problem dear colleague?

On 4/21/05, sel...@ac... <
sel...@ac...> wrote:
>=20
> help
>=20
> This message is for the designated recipient only and may contain=20
> privileged, proprietary, or otherwise private information. If you have=20
> received it in error, please notify the sender immediately and delete the=
=20
> original. Any other use of the email by you is prohibited.
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&opclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] help

[Gustavo F. <gfa...@gm...>]

Please, just ask how we can help you. ;-)

On 4/22/05, Darren Davison <da...@da...> wrote:
>=20
>=20
> On Fri, April 22, 2005 5:06, sel...@ac... said:
> > help
>=20
> you certainly seem to need it :)
>=20
> --
> Darren Davison
> Public Key: 0xDD356B0D
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&opclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] help

[Darren D. <da...@da...>]

On Fri, April 22, 2005 5:06, sel...@ac... said:
> help

you certainly seem to need it :)


--=20
Darren Davison
Public Key: 0xDD356B0D

[Springframework-developer] FAILED BUILD: sparc-solaris1 (last 30 lines included)

[Darren D. <da...@sh...>]

1114156327
FAILED
    [junit] ------------- Standard Output ---------------
    [junit] com.sun.jmx.mbeanserver.JmxMBeanServer
    [junit] ------------- ---------------- ---------------

    [junit] Testcase: testDatesInJmx took 0,469 sec
    [junit] Testcase: testGetDates took 0,101 sec
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,424 sec
    [junit] Testsuite: org.springframework.jmx.export.LazyInitTests
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,424 sec

    [junit] Testcase: testLazyInit took 0,349 sec
    [junit] Testcase: testInvokeOnLazyInitBean took 0,053 sec
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,581 sec
    [junit] Testsuite: org.springframework.jmx.export.MBeanExporterTests
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,581 sec

    [junit] Testcase: testWithLocatedMBeanServer took 0,009 sec
    [junit] Testcase: testWithSuppliedMBeanServer took 0,019 sec
    [junit] Testcase: testUserCreatedMBeanRegWithDynamicMBean took 0,02 sec
    [junit] Testcase: testAutodetectMBeans took 0,242 sec
    [junit] Testcase: testAutodetectLazyMBeans took 0,226 sec
    [junit] Testcase: testExportAopProxy took 0,024 sec
    [junit] 	FAILED
    [junit] Should be able to get value from an AOP JDK proxy
    [junit] junit.framework.AssertionFailedError: Should be able to get value from an AOP JDK proxy
    [junit] 	at org.springframework.jmx.export.MBeanExporterTests.testExportAopProxy(MBeanExporterTests.java:155)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: x86-solaris1 (last 30 lines included)

[Darren D. <da...@sh...>]

1114152988
FAILED
    [junit] ------------- Standard Output ---------------
    [junit] com.sun.jmx.mbeanserver.JmxMBeanServer
    [junit] ------------- ---------------- ---------------

    [junit] Testcase: testDatesInJmx took 0,295 sec
    [junit] Testcase: testGetDates took 0,047 sec
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,312 sec
    [junit] Testsuite: org.springframework.jmx.export.LazyInitTests
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,312 sec

    [junit] Testcase: testLazyInit took 0,237 sec
    [junit] Testcase: testInvokeOnLazyInitBean took 0,051 sec
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,477 sec
    [junit] Testsuite: org.springframework.jmx.export.MBeanExporterTests
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,477 sec

    [junit] Testcase: testWithLocatedMBeanServer took 0,047 sec
    [junit] Testcase: testWithSuppliedMBeanServer took 0,006 sec
    [junit] Testcase: testUserCreatedMBeanRegWithDynamicMBean took 0,013 sec
    [junit] Testcase: testAutodetectMBeans took 0,198 sec
    [junit] Testcase: testAutodetectLazyMBeans took 0,15 sec
    [junit] Testcase: testExportAopProxy took 0,031 sec
    [junit] 	FAILED
    [junit] Should be able to get value from an AOP JDK proxy
    [junit] junit.framework.AssertionFailedError: Should be able to get value from an AOP JDK proxy
    [junit] 	at org.springframework.jmx.export.MBeanExporterTests.testExportAopProxy(MBeanExporterTests.java:155)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: sparc-solaris2 (last 30 lines included)

[Darren D. <da...@sh...>]

1114149802
FAILED
    [junit] ------------- Standard Output ---------------
    [junit] com.sun.jmx.mbeanserver.JmxMBeanServer
    [junit] ------------- ---------------- ---------------

    [junit] Testcase: testDatesInJmx took 0,525 sec
    [junit] Testcase: testGetDates took 0,064 sec
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,411 sec
    [junit] Testsuite: org.springframework.jmx.export.LazyInitTests
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,411 sec

    [junit] Testcase: testLazyInit took 0,332 sec
    [junit] Testcase: testInvokeOnLazyInitBean took 0,055 sec
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,615 sec
    [junit] Testsuite: org.springframework.jmx.export.MBeanExporterTests
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,615 sec

    [junit] Testcase: testWithLocatedMBeanServer took 0,009 sec
    [junit] Testcase: testWithSuppliedMBeanServer took 0,008 sec
    [junit] Testcase: testUserCreatedMBeanRegWithDynamicMBean took 0,024 sec
    [junit] Testcase: testAutodetectMBeans took 0,294 sec
    [junit] Testcase: testAutodetectLazyMBeans took 0,207 sec
    [junit] Testcase: testExportAopProxy took 0,025 sec
    [junit] 	FAILED
    [junit] Should be able to get value from an AOP JDK proxy
    [junit] junit.framework.AssertionFailedError: Should be able to get value from an AOP JDK proxy
    [junit] 	at org.springframework.jmx.export.MBeanExporterTests.testExportAopProxy(MBeanExporterTests.java:155)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: ppc-osx2 (last 30 lines included)

[Darren D. <da...@sh...>]

1114147005
FAILED
    [junit] ------------- Standard Output ---------------
    [junit] com.sun.jmx.mbeanserver.JmxMBeanServer
    [junit] ------------- ---------------- ---------------

    [junit] Testcase: testDatesInJmx took 0,315 sec
    [junit] Testcase: testGetDates took 0,06 sec
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,404 sec
    [junit] Testsuite: org.springframework.jmx.export.LazyInitTests
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,404 sec

    [junit] Testcase: testLazyInit took 0,296 sec
    [junit] Testcase: testInvokeOnLazyInitBean took 0,063 sec
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,75 sec
    [junit] Testsuite: org.springframework.jmx.export.MBeanExporterTests
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,75 sec

    [junit] Testcase: testWithLocatedMBeanServer took 0,006 sec
    [junit] Testcase: testWithSuppliedMBeanServer took 0,005 sec
    [junit] Testcase: testUserCreatedMBeanRegWithDynamicMBean took 0,017 sec
    [junit] Testcase: testAutodetectMBeans took 0,323 sec
    [junit] Testcase: testAutodetectLazyMBeans took 0,243 sec
    [junit] Testcase: testExportAopProxy took 0,103 sec
    [junit] 	FAILED
    [junit] Should be able to get value from an AOP JDK proxy
    [junit] junit.framework.AssertionFailedError: Should be able to get value from an AOP JDK proxy
    [junit] 	at org.springframework.jmx.export.MBeanExporterTests.testExportAopProxy(MBeanExporterTests.java:155)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] help

[<sel...@ac...>]

help


This message is for the designated recipient only and may contain =
privileged, proprietary, or otherwise private information.  If you have =
received it in error, please notify the sender immediately and delete =
the original.  Any other use of the email by you is prohibited.

Re: [Springframework-developer] WAS 6.0 TransactionManager Lookup

[Mark St G. <stg...@ca...>]

Juergen et al

Was looking a bit more into that Hibernate 3.0.1 changelog entry regarding
WAS 6 Transaction Manager Factory.

Seems to stem from this original Hibernate 3 JIRA issue:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-198

I am using Websphere 6 and I did use the same stock config that I had in
WAS 5.1.
From what I can tell the Transaction Manager Factory class is still:
      com.ibm.ws.Transaction.TransactionManagerFactory

I have started a project (and before downgrading my config back to straight
Hibernate transactions)
it seemed to work for me.

After reading the JIRA issue HHH-198... the user that this stemed from...
it looks like he is using WAS 5.1.2?
Why are they talking about WAS 6?
Anyway, seems a little confusing to me....  I am not sure exactly what
they fixed.

From Gavin's code in
com.hibernate.transaction.WebSphereExtendedTransactionLookup
it looks like they implemented an adapter to the Extended JTA Transaction
Manager and Transaction...

Anyway, I am curious if the Spring transaction management codebase needs an
equivilent change?

Again, from reading the Hibernate JIRA posts.. and from actually using WAS
6 with Hibernate 3.0 and Spring 1.2 RC2...
curious what the issue really is?

Thoughts?

Cheers,
Mark




                                                                           
             "Juergen Hoeller"                                             
             <juergen@interfac                                             
             e21.com>                                                   To 
             Sent by:                  <spr...@li... 
             springframework-d         urceforge.net>                      
             eveloper-admin@li                                          cc 
             sts.sourceforge.n                                             
             et                                                    Subject 
                                       Re: [Springframework-developer] WAS 
                                       6.0 TransactionManager Lookup       
             04/21/2005 07:03                                              
             AM                                                            
                                                                           
                                                                           
             Please respond to                                             
             springframework-d                                             
                 eveloper                                                  
                                                                           
                                                                           




Yes, we should cover WebSphere 6.0 too - I'll do that for 1.2 final.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dmitriy Kopylenko
Sent: Thursday, April 21, 2005 2:01 PM
To: spr...@li...
Subject: Re: [Springframework-developer] WAS 6.0 TransactionManager
Lookup


There is WebSphereTransactionManagerFactoryBean which is used to lookup
jta TransactionManager implementation for WebSphere versions 4, 5.0, and
5.1, not 6.0

May be we should modify it to add 6.0 lookup code?

Dmitriy.


Claus Ibsen wrote:

>Hi
>
>I was reading the changelog for Hibernate 3.01 and discovered:
>* fixed TransactionManager lookup (again) for WAS 6.0
>
>I recall there was something about Spring using a similar strategy to
lookup the
>TM in WAS as Hibernate does.
>
>Just though I would raise a flag if there could be a issue.
>
>
>Kind regards
>
>Claus
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: New Crystal Reports XI.
>Version 11 adds new functionality designed to reduce time involved in
>creating, integrating, and deploying reporting solutions. Free runtime
info,
>new features, or free trial, at: http://www.businessobjects.com/devxi/728
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime
info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime
info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] FAILED BUILD: x86-linux2 (last 30 lines included)

[Darren D. <da...@sh...>]

1114134689
FAILED
    [junit] ------------- Standard Output ---------------
    [junit] com.sun.jmx.mbeanserver.JmxMBeanServer
    [junit] ------------- ---------------- ---------------

    [junit] Testcase: testDatesInJmx took 0,17 sec
    [junit] Testcase: testGetDates took 0,033 sec
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,217 sec
    [junit] Testsuite: org.springframework.jmx.export.LazyInitTests
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,217 sec

    [junit] Testcase: testLazyInit took 0,166 sec
    [junit] Testcase: testInvokeOnLazyInitBean took 0,035 sec
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,345 sec
    [junit] Testsuite: org.springframework.jmx.export.MBeanExporterTests
    [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0,345 sec

    [junit] Testcase: testWithLocatedMBeanServer took 0,04 sec
    [junit] Testcase: testWithSuppliedMBeanServer took 0,005 sec
    [junit] Testcase: testUserCreatedMBeanRegWithDynamicMBean took 0,013 sec
    [junit] Testcase: testAutodetectMBeans took 0,12 sec
    [junit] Testcase: testAutodetectLazyMBeans took 0,136 sec
    [junit] Testcase: testExportAopProxy took 0,011 sec
    [junit] 	FAILED
    [junit] Should be able to get value from an AOP JDK proxy
    [junit] junit.framework.AssertionFailedError: Should be able to get value from an AOP JDK proxy
    [junit] 	at org.springframework.jmx.export.MBeanExporterTests.testExportAopProxy(MBeanExporterTests.java:155)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

Re: [Springframework-developer] EJBs vs POJOs

[Dmitriy K. <dko...@ru...>]

To put simply - if you absolutely require to physically distribute your=20
application, EJB (SLSB facade) would probably be the good choice here.=20
Please note that you still would want to use Spring-EJB support as it=20
transparently exposes your POJO business interfaces as EJB=20
implementations (via proxies) and also frees the application code from=20
low level plumbing code related to EJB programming model e.g. JNDI=20
lookups, etc. Coupled with IoC container (for DI) you get easy testable=20
code with minimal dependence on EJB container.

Regards,
Dmitriy.

Garvey, Paul M (GE Commercial Finance) wrote:

>James,
>      Your response was insightful and you did partially answered my que=
stion.
>Let me try to be a bit clearer, If I had to create an application that n=
eeded to
>be distributed across multiple machines I would normally use EJBs (state=
less Bean + Entity Beans)
>or (stateless beans + DAOs) or (stateless beans + hibernate) etc. Could =
I use Spring
>in this senario? Would it make more sense to stick with the EJB paradigm=
? I want to have a clear picture=20
>in my mind of when to use Spring on a project and when to use EJBs. In o=
ther words,=20
>when does it make most sense to use EJBs instead of Spring and vice vers=
a?
>Are there times when Spring is just not the solution to the problem and =
EBJ is?
>
>Paul
>
>
>
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of James Cook
>Sent: Thursday, April 21, 2005 5:25 PM
>To: spr...@li...
>Subject: RE: [Springframework-developer] EJBs vs POJOs
>
>
>Spring simply provides a convenient fa=E7ade to other persistence
>implementations, including EJB!
>
>You may have meant Entity Beans when you stated EJB. If so, another
>way of wording your question is, "Are there cases when EJB is
>preferred as a persistence mechanism over a POJO persistence
>(Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)
>mechanism?"
>
>Take these with a grain of salt, since I don't have hands-on
>experience with all of the POJO persistence mechanisms. A few benefits
>don't come easily to the world of POJO persistence.
>
>a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
>support distributed security contexts. Even if you were writing an EJB
>implementation, you would want to limit the number of network calls
>your app has to make. But if you really have part of your application
>on one machine, and part on another, you can invoke EJB's on the
>various machines and remain within the same security context.
>
>b) Clustered sessions are still the realm of the J2EE container.
>Distributed caching of persistent object between machines is difficult
>to achieve using POJO persistence.
>
>c) Support for CORBA clients is a standard feature of J2EE.
>
>There may be more. Of course, EJB3 will probably turn this discussion
>on its ear.
>
>If I totally missed your point, and you just wanted to know if Spring
>provided lightweight (sorry Hani) alternatives for the specification
>components that make up Enterprise Java Beans (EJB), namely:
>
>- Stateless Session Bean (yes, via service interfaces, pojos you write)
>- Stateful Session Bean (no)
>- Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)
>- Message Driven Bean (No, AFAIK)
>- Timer Bean (yes, via quartz)
>- Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, m=
aybe
>others)
>
>
>
>
> =20
>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On=20
>>Behalf Of Garvey, Paul M (GE Commercial Finance)
>>Sent: Thursday, April 21, 2005 3:53 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] EJBs vs POJOs
>>
>>All,
>>
>>I fairly new to Spring and I am currently reading some documentation=20
>>on it. I have bought into the concept of the lightweight feature of=20
>>Spring. I do have a quick question, Springs seems to handle every=20
>>scenario that I would
>>use EJBs, is there a few cases where EJBs are unavoidable to use? In ot=
her
>>words
>>are there any scenarios where Spring is just not the best tool to use a=
nd
>>EJBs is
>>the more suited? Any thoughts?
>>
>>Paul
>>
>>
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real=20
>>users. Discover which products truly live up to the hype. Start=20
>>reading now. http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
>>_______________________________________________
>>Springframework-developer mailing list=20
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>   =20
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =20
>

[Springframework-developer] spring Build Failed

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050422001620

Re: [Springframework-developer] EJBs vs POJOs

[Eugene K. <eu...@ja...>]

Paul,

   There is nothing wrong with using EJB as a remore facade. That will 
give you standard access to J2EE services (JTA, remoting, failover, 
clustering). In my current project we are using the following pattern:

   EJB Layer (Stateless and MDB without any business logic)
   Spring managed POJO's (IoC + AOP + componentization)
   Persistance (DAO, CMP beans)

   This way EJB layer is used as a remote facade and all business logic 
is easily testable outside of J2EE container and allow to hook up 
aspects and nicely manage dependencies. We also found that CMP layer 
with caching provided by J2EE container perform quite well in some cases 
(especially when cluster-wide cache between transactions is turned on), 
but in some cases caching aspects allow additional performance improvment.

   regards,
   Eugene


Garvey, Paul M (GE Commercial Finance) wrote:
> James,
>       Your response was insightful and you did partially answered my question.
> Let me try to be a bit clearer, If I had to create an application that needed to
> be distributed across multiple machines I would normally use EJBs (stateless Bean + Entity Beans)
> or (stateless beans + DAOs) or (stateless beans + hibernate) etc. Could I use Spring
> in this senario? Would it make more sense to stick with the EJB paradigm? I want to have a clear picture 
> in my mind of when to use Spring on a project and when to use EJBs. In other words, 
> when does it make most sense to use EJBs instead of Spring and vice versa?
> Are there times when Spring is just not the solution to the problem and EBJ is?
> 
> Paul
> 
> 
> 
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of James Cook
> Sent: Thursday, April 21, 2005 5:25 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] EJBs vs POJOs
> 
> 
> Spring simply provides a convenient façade to other persistence
> implementations, including EJB!
> 
> You may have meant Entity Beans when you stated EJB. If so, another
> way of wording your question is, "Are there cases when EJB is
> preferred as a persistence mechanism over a POJO persistence
> (Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)
> mechanism?"
> 
> Take these with a grain of salt, since I don't have hands-on
> experience with all of the POJO persistence mechanisms. A few benefits
> don't come easily to the world of POJO persistence.
> 
> a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
> support distributed security contexts. Even if you were writing an EJB
> implementation, you would want to limit the number of network calls
> your app has to make. But if you really have part of your application
> on one machine, and part on another, you can invoke EJB's on the
> various machines and remain within the same security context.
> 
> b) Clustered sessions are still the realm of the J2EE container.
> Distributed caching of persistent object between machines is difficult
> to achieve using POJO persistence.
> 
> c) Support for CORBA clients is a standard feature of J2EE.
> 
> There may be more. Of course, EJB3 will probably turn this discussion
> on its ear.
> 
> If I totally missed your point, and you just wanted to know if Spring
> provided lightweight (sorry Hani) alternatives for the specification
> components that make up Enterprise Java Beans (EJB), namely:
> 
> - Stateless Session Bean (yes, via service interfaces, pojos you write)
> - Stateful Session Bean (no)
> - Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)
> - Message Driven Bean (No, AFAIK)
> - Timer Bean (yes, via quartz)
> - Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, maybe
> others)
> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On 
>>Behalf Of Garvey, Paul M (GE Commercial Finance)
>>Sent: Thursday, April 21, 2005 3:53 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] EJBs vs POJOs
>>
>>All,
>>
>>I fairly new to Spring and I am currently reading some documentation 
>>on it. I have bought into the concept of the lightweight feature of 
>>Spring. I do have a quick question, Springs seems to handle every 
>>scenario that I would
>>use EJBs, is there a few cases where EJBs are unavoidable to use? In other
>>words
>>are there any scenarios where Spring is just not the best tool to use and
>>EJBs is
>>the more suited? Any thoughts?
>>
>>Paul
>>

RE: [Springframework-developer] EJBs vs POJOs

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

James,
      Your response was insightful and you did partially answered my =
question.
Let me try to be a bit clearer, If I had to create an application that =
needed to
be distributed across multiple machines I would normally use EJBs =
(stateless Bean + Entity Beans)
or (stateless beans + DAOs) or (stateless beans + hibernate) etc. Could =
I use Spring
in this senario? Would it make more sense to stick with the EJB =
paradigm? I want to have a clear picture=20
in my mind of when to use Spring on a project and when to use EJBs. In =
other words,=20
when does it make most sense to use EJBs instead of Spring and vice =
versa?
Are there times when Spring is just not the solution to the problem and =
EBJ is?

Paul





-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of James Cook
Sent: Thursday, April 21, 2005 5:25 PM
To: spr...@li...
Subject: RE: [Springframework-developer] EJBs vs POJOs


Spring simply provides a convenient fa=E7ade to other persistence
implementations, including EJB!

You may have meant Entity Beans when you stated EJB. If so, another
way of wording your question is, "Are there cases when EJB is
preferred as a persistence mechanism over a POJO persistence
(Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)
mechanism?"

Take these with a grain of salt, since I don't have hands-on
experience with all of the POJO persistence mechanisms. A few benefits
don't come easily to the world of POJO persistence.

a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
support distributed security contexts. Even if you were writing an EJB
implementation, you would want to limit the number of network calls
your app has to make. But if you really have part of your application
on one machine, and part on another, you can invoke EJB's on the
various machines and remain within the same security context.

b) Clustered sessions are still the realm of the J2EE container.
Distributed caching of persistent object between machines is difficult
to achieve using POJO persistence.

c) Support for CORBA clients is a standard feature of J2EE.

There may be more. Of course, EJB3 will probably turn this discussion
on its ear.

If I totally missed your point, and you just wanted to know if Spring
provided lightweight (sorry Hani) alternatives for the specification
components that make up Enterprise Java Beans (EJB), namely:

- Stateless Session Bean (yes, via service interfaces, pojos you write)
- Stateful Session Bean (no)
- Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)
- Message Driven Bean (No, AFAIK)
- Timer Bean (yes, via quartz)
- Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, =
maybe
others)




> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On=20
> Behalf Of Garvey, Paul M (GE Commercial Finance)
> Sent: Thursday, April 21, 2005 3:53 PM
> To: spr...@li...
> Subject: [Springframework-developer] EJBs vs POJOs
>=20
> All,
>=20
> I fairly new to Spring and I am currently reading some documentation=20
> on it. I have bought into the concept of the lightweight feature of=20
> Spring. I do have a quick question, Springs seems to handle every=20
> scenario that I would
> use EJBs, is there a few cases where EJBs are unavoidable to use? In =
other
> words
> are there any scenarios where Spring is just not the best tool to use =
and
> EJBs is
> the more suited? Any thoughts?
>=20
> Paul
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users. Discover which products truly live up to the hype. Start=20
> reading now. http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] EJBs vs POJOs

[James C. <dja...@gm...>]

Spring simply provides a convenient fa=E7ade to other persistence
implementations, including EJB!

You may have meant Entity Beans when you stated EJB. If so, another
way of wording your question is, "Are there cases when EJB is
preferred as a persistence mechanism over a POJO persistence
(Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)
mechanism?"

Take these with a grain of salt, since I don't have hands-on
experience with all of the POJO persistence mechanisms. A few benefits
don't come easily to the world of POJO persistence.

a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
support distributed security contexts. Even if you were writing an EJB
implementation, you would want to limit the number of network calls
your app has to make. But if you really have part of your application
on one machine, and part on another, you can invoke EJB's on the
various machines and remain within the same security context.

b) Clustered sessions are still the realm of the J2EE container.
Distributed caching of persistent object between machines is difficult
to achieve using POJO persistence.

c) Support for CORBA clients is a standard feature of J2EE.

There may be more. Of course, EJB3 will probably turn this discussion
on its ear.

If I totally missed your point, and you just wanted to know if Spring
provided lightweight (sorry Hani) alternatives for the specification
components that make up Enterprise Java Beans (EJB), namely:

- Stateless Session Bean (yes, via service interfaces, pojos you write)
- Stateful Session Bean (no)
- Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)
- Message Driven Bean (No, AFAIK)
- Timer Bean (yes, via quartz)
- Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, mayb=
e
others)




> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On=20
> Behalf Of Garvey, Paul M (GE Commercial Finance)
> Sent: Thursday, April 21, 2005 3:53 PM
> To: spr...@li...
> Subject: [Springframework-developer] EJBs vs POJOs
>=20
> All,
>=20
> I fairly new to Spring and I am currently reading some documentation=20
> on it. I have bought into the concept of the lightweight feature of=20
> Spring. I do have a quick question, Springs seems to handle every=20
> scenario that I would
> use EJBs, is there a few cases where EJBs are unavoidable to use? In othe=
r
> words
> are there any scenarios where Spring is just not the best tool to use and
> EJBs is
> the more suited? Any thoughts?
>=20
> Paul
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users. Discover which products truly live up to the hype. Start=20
> reading now. http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] EJBs vs POJOs

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

All,=20

I fairly new to Spring and I am currently reading some documentation
on it. I have bought into the concept of the lightweight feature of =
Spring.
I do have a quick question, Springs seems to handle every scenario that =
I would=20
use EJBs, is there a few cases where EJBs are unavoidable to use? In =
other words
are there any scenarios where Spring is just not the best tool to use =
and EJBs is
the more suited? Any thoughts?=20

Paul

[Springframework-developer] Re: Major bug not marked for resolution in 1.2

[Matt S. <sga...@us...>]

Cool, thanks!  I just want to make sure these issues don't slip through 
the cracks since Spring 1.2 final is coming out soon :)

Matt

Juergen Hoeller wrote:
> SPR-889 is already fixed, committed to CVS for a couple of hours :-)
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Matt Sgarlata
> Sent: Thursday, April 21, 2005 7:17 PM
> To: spr...@li...
> Subject: [Springframework-developer] Re: Major bug not marked for
> resolution in 1.2
> 
> 
> I would also consider SPR-889, "Dependency checking doesn't work for 
> beans using method injection" as a bug that should be fixed before 
> Spring 1.2 final.
> 
> Matt
> 
> Matt Sgarlata wrote:
> 
>>I view SPR-879 as a major bug in Spring that I would hope could be fixed 
>>before Spring 1.2 final.  The underlying issue is that beans that are 
>>designated for auto-autoproxying don't always get auto-proxied. Instead, 
>>beans that are marked for auto-proxying are only proxied if they aren't 
>>needed before the auto-proxy machinery kicks in.  As a user I would 
>>expect a bean marked for auto-proxying to be auto-proxied. Instead, the 
>>current symantics implemented by Spring are "autoproxy if you can, but 
>>if you can't then swallow the error and leave me scratching my head" ;)  
>>SPR-879 is to at least warn the user that a bean they've marked for 
>>autoproxying isn't going to be autoproxied.
>>
>>Thanks,
>>
>>Matt
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: [Springframework-developer] Any plans to add support for multiple handlers per request

[March, A. <am...@so...>]

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Seth Ladd
> Sent: Thursday, April 21, 2005 11:13 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Any plans to add support for
> multiple handlers per request
>=20
> On 4/21/05, March, Andres <am...@so...> wrote:
> > Thanks for the reply.  I am interested in webflow but wow there is a
lot
> > of stuff in there.  I was not sure that it was focused on multiple
> > actions per request.  I thought it was generally for multipage
actions.
>=20
> Using webflow, you would configure multiple <action>'s to string
> together, finally landing on a <view>.  So it's a simple way to model
> a flow diagram (often coming from management) as a webflow workflow.
> It's actually very simple to setup.  If you understand Spring MVC then
> setting up webflow will be very straight forward.

Cool!

>=20
> > Basically I just want to call 1-to-many service methods for a single
> > request.  I want to be able to configure this in the app-context
> > preferably, so that I don't have to create a controller for every
> > request. I opened  SPR-871 to track this stuff.  I attached some
code
> > that basically does what I want but is kinda ugly.
>=20
> Ahh... so you want to bind N service calls directly to a request
> without a controller?  How would you marshall request parameters into
> the service layer and back?  This is the job for the controller, imho.
>  So the controller is pretty thin, but does glue my service layer to
> the web mvc world.

Definitely the dealing with request parameters is the toughest part but
not insurmountable.  And if you have hundreds of requests that just
return some data, it is well worth the time.  I think the Binder can
solve many of these problem.  The main type of binder I'm interested in
is one that basically creates a HashMap derived object to represent the
query parameters.  This would be able to support multivalued, ranges,
and other constraints.  But other binders could be configurable that
could handle any type of service method parameters.  Although I think
the QueryBinder I created is great for many and complex parameters, a
Binder could be written that inspects the method signature and works the
same way the command objects are bound.  Anyway this could be a long
conversation but I hope this type of thing is valuable to more than just
me.  I already have written stuff for our needs but making it more
generic for others would be nice.=20

>=20
> If this is what you want, webflow will still require you to write an
> Action method for each step along the way.
>=20
> >
> > Then I thought it would be simpler if multiple controllers/handlers
> > could be specified for each request.  I could easily make a generic
> > controller bean that would have a property to know which service
method
> > to call and would just stick the result in the model.  At the end of
all
> > those, a final controller would return the ModelAndView.
>=20
> Again, how do you know what the method parameters would be for each
> service call?

A binder implementation like I describe above.

>=20
> >
> > I guess it would be nice to use webflow if it already has this
> > capability but I hope it is not too much trouble to set up.
>=20
> Now that you have explained this, webflow (afaik) does not have
> exactly this feature.  You will still need to write a method that
> handles the Action, taking a RequestContext and returning an Event.
>=20
I know there would be some work to do but I guess I'm looking for the
best extension point and if it is useful to others.  I'd much rather use
something more people work on then just me.  I tend to have bugs in my
code ;)

I have run across this problem often but I guess if most of your app
deals with POSTs, then this type of thing would not be of much use.  I
think large reporting applications would be a good example of when this
functionality would be useful.

> Seth
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer