springframework-developer — Spring Framework developers list

[Springframework-developer] Regarding multiple around advice intercepters

[Karthikeyani K <kar...@ya...>]

Hi,
          This is regarding multiple around advice interceptors. The "interceptorNames"
property of the ProxyFactoryBean takes a list of String where we can specify the
interceptors.  Each of the interceptors will be invoked in the order they are presented. If
there are two around advice interceptors in the list, how does the invocation.proceed method
work. Will the method be invoked twice? How does spring handle multiple around interceptors
for a given pointcut.
  
 Thanks,
 Karthi


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Springframework-developer] JMS remoting provider available

[<jas...@ma...>]

On 29 Oct 2004, at 17:12, j=FCrgen h=F6ller [werk3AT] wrote:
> James,
>
> OK, I see... I already assumed that it's not feasible to recreate a=20
> QueueRequest for each remote method invocation. However, even if the=20=

> Session auto-reconnects in case of a JMS server restart (as a side=20
> note, is this really provided by all major JMS implementations? my JMS=20=

> experience is too limited to tell),

Most good ones do this. Though BEA doesn't :)

We could add a timeout which closes session/QueueRequestors down if a=20
reply isn't received in a maximum allowed time to recycle the pool.


> a Session is a single-threaded object, isn't it? So if the remote=20
> client side resides in a server (for example a web application talking=20=

> to an external process), we shouldn't use one single Session from=20
> multiple threads... Correct me if I'm wrong in that assumption, of=20
> course.

A session can only be used by one thread at once, yes. Though there's=20
no server side equivalent; the session is a client side, JMS client=20
thing. (To be a pedant, the session is used for transactions on the=20
server side; but other than that its purely a message decorator, to=20
help the JMS client multiplex messaging on the client side).


> So as far as I can tell, we do need some sort of pooling here, to=20
> allow for proper concurrent invocations on a JMS remoting proxy. I=20
> agree that we should pool the QueueRequestors, not just the Sessions,=20=

> to also avoid the recreation of the temporary queue. The idea with the=20=

> TargetSource is interesting; it might still be worthwhile to put the=20=

> pooling configuration into JmsInvokerClientInterceptor itself, though,=20=

> for configuration convenience.

Agreed. Though I guess it depends on the client side stub; if a client=20=

side stub only allows 1 remote request at once on any thread, then=20
there's no absolute need for pooling.

Though using pooling from the start is a good idea; as it means you=20
could have 10,000 remote client stub objects, but only use, say, 5=20
QueueRequestor's concurrently.


> After all, the QueueRequestors need to be pooled once there is more=20
> than one thread accessing the proxy... (and even standalone=20
> applications might use multiple threads doing backend work).

Agreed. I think a bigger reason for pooling is reducing resource load=20
rather than concurrent access to a client stub; so we can have huge=20
numbers of lightweight client stubs, which only use a QueueRequestor=20
from the pool when they are needed.


> Regarding the naming: We use the "xxx invoker" naming mainly if we use=20=

> "xxx" in a special fashion, i.e. if plain "xxx" usually works=20
> differently. So "HTTP invoker" means transferring Spring=20
> RemoteInvocation objects over HTTP; "RMI invoker" means sending such=20=

> Spring RemoteInvocations over RMI (in contrast to standard RMI). In=20
> the case of Hessian and Burlap, we use the native facilities of those=20=

> protocols, i.e. the exposed services are always classic Hessian and=20
> Burlap without Spring specifics - we do not send Spring=20
> RemoteInvocation objects over the wire there. That's why they are not=20=

> named "invoker".

Cool - thanks for the explanation.

James
-------
http://radio.weblogs.com/0112098/

[Springframework-developer] Problems with Hibernate and Spring

[Stefan M. <s....@s2...>]

Hi,

I have encountered the following problems with Spring/Hibernate:

1. 
situation:
- there is a thread bound hibernate session.
- a method A is called and a transactionInterceptor begins a new Transaction
on the thread bound session.
- method A calls method B. The invocation is again intercepted by a
TransactionInterceptor which behavior is PROPAGATION_REQUIRED. The existing
transaction is reused. 
- An exception is thrown in the body of method B.
- The TransactionInterceptor on method B catches the exception and calls
sessionHolder.setRollbackOnly(). 
- The top-level TransactionInterceptor will find that
sessionholder.rollbackOnly=true and rollback the transaction.

problem:
sessionHolder.rollbackOnly is never reset although the transaction is over.
Thus the following transactions on this session will be rolled back as well.

2. 
situation:
- a transaction is begun.
- different objects are persisted or removed from the database.
- the transaction is rolled back.

Problem:
- The database operations are first put into hibernate's session cache. And
they won't be executed/removed until session.flush() or session.clear() are
called. The TransactionInterceptor only issues a rollback on the
Transaction. Therefore flushing the session after the transaction is over
will execute the database operations even though they should have been
rolled back.

I have fixed these issues by making changes to HibernateTransactionManager,
i.e. flushing the session and setting the sessionHolder.rollbackOnly to
false before rollback.

Changes to HibernateTransactionManager:

	protected void doRollback(DefaultTransactionStatus status) {
		HibernateTransactionObject txObject =
(HibernateTransactionObject) status.getTransaction();
		if (status.isDebug()) {
			logger.debug("Rolling back Hibernate transaction on
session [" +
	
txObject.getSessionHolder().getSession() + "]");
		}
		try {
			//unset rollbackOnly. 
			txObject.getSessionHolder().unsetRollbackOnly();
			try 
			{
				//flush before rollback to remove all
pending batch actions
				if (flushBeforeRollback)
txObject.getSessionHolder().getSession().flush();
			} 
			catch (HibernateException e) {
				logger.error("flushing session ["
+txObject.getSessionHolder().getSession() + "] before rollback failed");
			}
	
txObject.getSessionHolder().getTransaction().rollback();
		}
		catch (net.sf.hibernate.TransactionException ex) {
			throw new TransactionSystemException("Could not
rollback Hibernate transaction", ex);
		}
		catch (JDBCException ex) {
			// shouldn't really happen, as a rollback doesn't
cause a flush
			throw
convertJdbcAccessException(ex.getSQLException());
		}
		catch (HibernateException ex) {
			// shouldn't really happen, as a rollback doesn't
cause a flush
			throw convertHibernateAccessException(ex);
		}
	}

Changes to SessionHolder:

Added method sunsetRollbackOnly().



Is there another way?





--
Stefan Meyer
 

Re: [Springframework-developer] JMS remoting provider available

[<jue...@we...>]

James,
=20
OK, I see... I already assumed that it's not feasible to recreate a =
QueueRequest for each remote method invocation. However, even if the =
Session auto-reconnects in case of a JMS server restart (as a side note, =
is this really provided by all major JMS implementations? my JMS =
experience is too limited to tell), a Session is a single-threaded =
object, isn't it? So if the remote client side resides in a server (for =
example a web application talking to an external process), we shouldn't =
use one single Session from multiple threads... Correct me if I'm wrong =
in that assumption, of course.
=20
So as far as I can tell, we do need some sort of pooling here, to allow =
for proper concurrent invocations on a JMS remoting proxy. I agree that =
we should pool the QueueRequestors, not just the Sessions, to also avoid =
the recreation of the temporary queue. The idea with the TargetSource is =
interesting; it might still be worthwhile to put the pooling =
configuration into JmsInvokerClientInterceptor itself, though, for =
configuration convenience. After all, the QueueRequestors need to be =
pooled once there is more than one thread accessing the proxy... (and =
even standalone applications might use multiple threads doing backend =
work).
=20
Regarding the naming: We use the "xxx invoker" naming mainly if we use =
"xxx" in a special fashion, i.e. if plain "xxx" usually works =
differently. So "HTTP invoker" means transferring Spring =
RemoteInvocation objects over HTTP; "RMI invoker" means sending such =
Spring RemoteInvocations over RMI (in contrast to standard RMI). In the =
case of Hessian and Burlap, we use the native facilities of those =
protocols, i.e. the exposed services are always classic Hessian and =
Burlap without Spring specifics - we do not send Spring RemoteInvocation =
objects over the wire there. That's why they are not named "invoker".
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von jas...@ma...
Gesendet: Fr 29.10.2004 09:28
An: spr...@li...
Betreff: Re: [Springframework-developer] JMS remoting provider available




On 28 Oct 2004, at 21:14, j=FCrgen h=F6ller [werk3AT] wrote:
> James,
>
> I've looked at the JmsClientInterceptor in some more detail, and found
> that it uses the JMS QueueRequestor class (which I haven't seen in
> action before).

Its a JMS helper class. Its possible to implement in a slightly more
efficient way with timeouts and re-try support; but its a suitable
first implementation. We could get more advanced later on.


> I've noticed that QueueRequestor takes a Session and a Queue,
> internally creating a temporary queue for responses. However, in the
> current usage style, it would use the same Session for the entire
> lifetime of the JmsClientInterceptor bean (i.e. the entire
> application), and isn't properly closed on shutdown.

Good catch. I've just patched the code to support DisposableBean to
close down the session & queueRequestor.


> While that might not cause any issues in a standalone client
> environment, what about usage of JmsClientInterceptor in a J2EE
> environment, for example a web app invoking some external process? And
> what about the JMS Session used by the QueueRequestor becoming stale,
> for example through a restart of the JMS server?

Most decent JMS providers can handle auto-reconnection to the JMS
server if it goes down and full HA.


> It seems to me that we should get a Session via a given
> ConnectionFactory for each request here. In the J2EE case, this will
> usually be a pooled Session from a pooled Connection. In the
> standalone case, it can be from a single Connection, via Spring's
> SingleConnectionFactory.

Grabbing a session from a pool is a reasonable idea (though there's
also the MessageProducer, MessageConsumer and temporary Queue to
consider). Though creating JMS resources like session, consumer,
producer, each time you need to perform some kind of remote invocation
is a very bad idea - its really slow, since creating a
session/consumer/producer requires an RPC with the JMS server anyway :)

Sessions are pretty lightweight to keep around though; its Connections
that need to be pooled as they are the expensive resource; sessions are
much cheaper, though they are intended to be long lived objects.

In terms of pooling, the best idea is to pool the QueueRequestor; i.e.
pool the Session + temporary Queue + MessageProducer + MessageConsumer.
Then when you grab one from the pool its complete ready to be used -
you don't have to wait for a session or producer or consumer to be
created - all of which are pretty expensive operations, requiring an
RPC with the JMS server.

If further down the road we write a more complex kind of QueueRequestor
object, we could pool that too as a single unit since it'll always have
a Session, MessageProducer, MessageConsumer and temporary Queue.


> The problem with the ConnectionFactory approach is that we'd need to
> recreate a QueueRequestor instance for each request, with a freshly
> fetched Session. Does this mean that the QueueRequestor would create a
> new temporary Queue for each request in such a scenario?

Yes - which is a bad idea too, as creating a temporary queue requires
an RPC with the JMS server.

> I wonder if that's feasible... However, what's the alternative, given
> that we shouldn't keep using the same Session forever?

Well we could use the same session forever. Or we could pool the
QueueRequestor instances.

How about we use the same trick we just used on the JCAContainer - we
create an interface to represent some kind of JMS based QueueRequestor;
then we could use a single one for the duration of the client stub, or
we could introduce a pool using TargetSource?


> We could also add QueueRequestor/TopicRequestor support to
> JmsTemplate, offering "request" methods that throw unchecked
> JmsExceptions, fetching a fresh Session from the configured
> ConnectionFactory underneath. We could also offer a
> "requestAndConvert" method that takes Object as input message and also
> returns Object, analogous to "convertAndSend"/"receiveAndConvert".

Sounds great. I'd be nice to use the same JMS implementation code
underneath.


> Already touching 1.2 RC1 work here, I guess :-)

:)

> P.S.: I'd like to rename JmsClientInterceptor, JmsServiceExporter etc
> to JmsInvokerClientInterceptor respectively JmsInvokerServiceExporter.
> It's about serializing Spring's remote invocations through JMS, not
> about native remoting support in JMS, and I feel that we should
> reflect this in the name. We use the terms "HTTP invoker" and "RMI
> invoker" too, when serializing RemoteInvocations via HTTP or RMI.

Sounds good with me. Shouldn't we rename BurlapClientInterceptor and
HessianClientInterceptor too?

James
-------
http://radio.weblogs.com/0112098/



-------------------------------------------------------
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JMS remoting provider available

[<jas...@ma...>]

On 28 Oct 2004, at 21:14, j=FCrgen h=F6ller [werk3AT] wrote:
> James,
>
> I've looked at the JmsClientInterceptor in some more detail, and found=20=

> that it uses the JMS QueueRequestor class (which I haven't seen in=20
> action before).

Its a JMS helper class. Its possible to implement in a slightly more=20
efficient way with timeouts and re-try support; but its a suitable=20
first implementation. We could get more advanced later on.


> I've noticed that QueueRequestor takes a Session and a Queue,=20
> internally creating a temporary queue for responses. However, in the=20=

> current usage style, it would use the same Session for the entire=20
> lifetime of the JmsClientInterceptor bean (i.e. the entire=20
> application), and isn't properly closed on shutdown.

Good catch. I've just patched the code to support DisposableBean to=20
close down the session & queueRequestor.


> While that might not cause any issues in a standalone client=20
> environment, what about usage of JmsClientInterceptor in a J2EE=20
> environment, for example a web app invoking some external process? And=20=

> what about the JMS Session used by the QueueRequestor becoming stale,=20=

> for example through a restart of the JMS server?

Most decent JMS providers can handle auto-reconnection to the JMS=20
server if it goes down and full HA.


> It seems to me that we should get a Session via a given=20
> ConnectionFactory for each request here. In the J2EE case, this will=20=

> usually be a pooled Session from a pooled Connection. In the=20
> standalone case, it can be from a single Connection, via Spring's=20
> SingleConnectionFactory.

Grabbing a session from a pool is a reasonable idea (though there's=20
also the MessageProducer, MessageConsumer and temporary Queue to=20
consider). Though creating JMS resources like session, consumer,=20
producer, each time you need to perform some kind of remote invocation=20=

is a very bad idea - its really slow, since creating a=20
session/consumer/producer requires an RPC with the JMS server anyway :)

Sessions are pretty lightweight to keep around though; its Connections=20=

that need to be pooled as they are the expensive resource; sessions are=20=

much cheaper, though they are intended to be long lived objects.

In terms of pooling, the best idea is to pool the QueueRequestor; i.e.=20=

pool the Session + temporary Queue + MessageProducer + MessageConsumer.=20=

Then when you grab one from the pool its complete ready to be used -=20
you don't have to wait for a session or producer or consumer to be=20
created - all of which are pretty expensive operations, requiring an=20
RPC with the JMS server.

If further down the road we write a more complex kind of QueueRequestor=20=

object, we could pool that too as a single unit since it'll always have=20=

a Session, MessageProducer, MessageConsumer and temporary Queue.


> The problem with the ConnectionFactory approach is that we'd need to=20=

> recreate a QueueRequestor instance for each request, with a freshly=20
> fetched Session. Does this mean that the QueueRequestor would create a=20=

> new temporary Queue for each request in such a scenario?

Yes - which is a bad idea too, as creating a temporary queue requires=20
an RPC with the JMS server.

> I wonder if that's feasible... However, what's the alternative, given=20=

> that we shouldn't keep using the same Session forever?

Well we could use the same session forever. Or we could pool the=20
QueueRequestor instances.

How about we use the same trick we just used on the JCAContainer - we=20
create an interface to represent some kind of JMS based QueueRequestor;=20=

then we could use a single one for the duration of the client stub, or=20=

we could introduce a pool using TargetSource?


> We could also add QueueRequestor/TopicRequestor support to=20
> JmsTemplate, offering "request" methods that throw unchecked=20
> JmsExceptions, fetching a fresh Session from the configured=20
> ConnectionFactory underneath. We could also offer a=20
> "requestAndConvert" method that takes Object as input message and also=20=

> returns Object, analogous to "convertAndSend"/"receiveAndConvert".

Sounds great. I'd be nice to use the same JMS implementation code=20
underneath.


> Already touching 1.2 RC1 work here, I guess :-)

:)

> P.S.: I'd like to rename JmsClientInterceptor, JmsServiceExporter etc=20=

> to JmsInvokerClientInterceptor respectively JmsInvokerServiceExporter.=20=

> It's about serializing Spring's remote invocations through JMS, not=20
> about native remoting support in JMS, and I feel that we should=20
> reflect this in the name. We use the terms "HTTP invoker" and "RMI=20
> invoker" too, when serializing RemoteInvocations via HTTP or RMI.

Sounds good with me. Shouldn't we rename BurlapClientInterceptor and=20
HessianClientInterceptor too?

James
-------
http://radio.weblogs.com/0112098/

[Springframework-developer] Re: message driven POJOs, a lightweight JCA container available

[Chris N. <ch...@si...>]

jas...@ma... wrote:
> java.lang.IllegalStateException: Unknown callback class
> org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedIntercept
> or at
> net.sf.cglib.proxy.CallbackUtils.getGenerator(CallbackUtils.java:102) 

Seems like you've worked around this, but FWIW this was a known bug in an
older version of CGLIB (the CallbackUtils class does not exist anymore).
Not sure where you're pulling your jar from, but perhaps you could point
them to the latest version (2.0.2).

Chris

RE: [Springframework-developer] Re: FishEye for Jira page

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

On Fri, October 29, 2004 0:34, Nick Lothian said:

> (OT) What was the response on installing the JDK?

basically they sent a blanket mail to anyone with an outstanding installa=
tion
request saying in essence;

 - lots of recent upgrades took place - check to see if your requested
software is now available (which it isn't, at least on the 3 machines I
looked at)

 - you may be able to install whatever into your home directory on the CF
servers under new installation policies (which is unlikely given the size=
 of
it and the restriction on space in home dirs on their CF boxes)


I need to check out the options in their docs and then get back to them t=
o let
them know it's still an outstanding request.

What I'm trying to do is get a JDK and a local anonymous copy of the CVS =
tree
and then run the autobuilds stuff via CruiseControl or something on sever=
al
different machines every time a checkin occurs.  If they would install th=
e JDK
as a server install, the rest should be possible.

Cheers,
--=20
Darren Davison
Public Key: #DD356B0D

RE: [Springframework-developer] Re: FishEye for Jira page

[Nick L. <nic...@es...>]

> 
> OK, I can do that, but they're not quick to respond to stuff 
> like this.  I 
> raised an official request for JDK installations on their 
> compile farm 
> servers back in July.  I got a response earlier this week.
> 

(OT) What was the response on installing the JDK?

[Springframework-developer] spring build.136 Build Successful

[<al...@jt...>]

<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
 { background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#FF0000; }.checkstyle-oddrow { bac=
kground-color:#CCCCCC }.checkstyle-data { font-family:arial,helvetica,sans-=
serif; font-size:8pt; color:#000000; }.checkstyle-sectionheader { backgroun=
d-color:#000066; font-family:arial,helvetica,sans-serif; font-size:10pt; co=
lor:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE&nbsp;-&nbsp;     =
               build.136</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>10/29/2004 00:16:58</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 24 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>10/28/2004 17:57:02</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>MessageSource speed optimizations</td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"/><p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
 overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (1470)                </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data">                failure            =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2">&nbsp;</td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader">             =
       &nbsp;Unit Test Error Details:&nbsp;(1)                </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2">                Test:&nbsp;test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2">          =
      Class:&nbsp;org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2">                Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2">                Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
">&nbsp;</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"modifications-sectionheader">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (9)                </td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">j=
hoeller</td><td class=3D"modifications-data">/changelog.txt</td><td class=
=3D"modifications-data">MessageSource speed optimizations</td></tr><tr clas=
s=3D"modifications-oddrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">src/org/springframework/context/support/ReloadableResourceBundleMessageSo=
urce.java</td><td class=3D"modifications-data">introduced "resolveCodeWitho=
utArguments", speed optimizations</td></tr><tr class=3D"modifications-evenr=
ow"><td class=3D"modifications-data">modified</td><td class=3D"modification=
s-data">jhoeller</td><td class=3D"modifications-data">src/org/springframewo=
rk/context/support/ResourceBundleMessageSource.java</td><td class=3D"modifi=
cations-data">introduced "resolveCodeWithoutArguments", speed optimizations=
</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-dat=
a">modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"=
modifications-data">src/org/springframework/context/support/AbstractMessage=
Source.java</td><td class=3D"modifications-data">introduced "resolveCodeWit=
houtArguments", speed optimizations</td></tr><tr class=3D"modifications-eve=
nrow"><td class=3D"modifications-data">modified</td><td class=3D"modificati=
ons-data">jhoeller</td><td class=3D"modifications-data">src/org/springframe=
work/web/servlet/tags/MessageTag.java</td><td class=3D"modifications-data">=
allow Collection as arguments</td></tr><tr class=3D"modifications-oddrow"><=
td class=3D"modifications-data">modified</td><td class=3D"modifications-dat=
a">jhoeller</td><td class=3D"modifications-data">src/org/springframework/we=
b/servlet/tags/RequestContextAwareTag.java</td><td class=3D"modifications-d=
ata">added HttpServletRequest check</td></tr><tr class=3D"modifications-eve=
nrow"><td class=3D"modifications-data">modified</td><td class=3D"modificati=
ons-data">jstrachan</td><td class=3D"modifications-data">/project.xml</td><=
td class=3D"modifications-data">added myself to the developer list, even th=
ough I've only ever written stuff thats being moved back into the sandbox :=
)</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-da=
ta">modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D=
"modifications-data">src/org/springframework/ejb/access/AbstractRemoteSlsbI=
nvokerInterceptor.java</td><td class=3D"modifications-data">added null chec=
k to removeSessionBeanInstance</td></tr><tr class=3D"modifications-evenrow"=
><td class=3D"modifications-data">modified</td><td class=3D"modifications-d=
ata">jhoeller</td><td class=3D"modifications-data">src/org/springframework/=
ejb/access/LocalSlsbInvokerInterceptor.java</td><td class=3D"modifications-=
data">added null check to removeSessionBeanInstance</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader">                =
        &nbsp;Deployments by this build:&nbsp;(8)                    </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html>

Re: [Springframework-developer] Re: FishEye for Jira page

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

On Thursday 28 October 2004 23:04, Matt Quail wrote:
> Hi guys,
>
> (FYI: I'm from Cenqua.)

Hi Matt - great looking product you guys have.

> We intend to apporach them about this, but having it requested directly
> by projects might make sf.net more willing to investigate it. Feel free
> to email sf.net asking that they look at installing FishEye.

OK, I can do that, but they're not quick to respond to stuff like this.  I 
raised an official request for JDK installations on their compile farm 
servers back in July.  I got a response earlier this week.

I reckon they'll take more notice if you approached them - it would give 
them something of a better value proposition for attracting more users (and 
thereby higher advertising and sponsorship revenues)

All the best,

-- 
Darren Davison
Public Key: #DD356B0D

[Springframework-developer] Re: FishEye for Jira page

[Matt Q. <ma...@ce...>]

Hi guys,

(FYI: I'm from Cenqua.)

Firstly, I can confirm that we do give zero-cost licenses for FishEye to 
Open Source projects. Infact IIRC, you guys already have a license for 
Clover, one of our other products.

> cool.  Definitely worth investigating then - is it something SF are willing to
> install on their servers do you know?

If sf.net were willing to run FishEye alongside viewcvs, we would be 
more than happy to give sf.net a license to do so: for all projects at 
sf.net.

We intend to apporach them about this, but having it requested directly 
by projects might make sf.net more willing to investigate it. Feel free 
to email sf.net asking that they look at installing FishEye.

Having said that, there is one "hack" you can do to get FishEye running 
on your sf.net project. Simply run FishEye on your own server, and 
replicate the CVS repository to your own server using the nightly CVS 
tarball:
http://sourceforge.net/docman/display_doc.php?docid=768&group_id=1#nightlytarballs

Lastly, we do intend to eventually support pserver access in FishEye. 
However, it won't be the most performant way to access a CVS repository, 
and it is probably not a good idea to overload sf.net's 
already-overloaded CVS servers.

=Matt

Darren Davison wrote:
> On Thu, October 28, 2004 15:46, Matthew E. Porter said:
> 
>>According to the TSS announcement
>>(http://theserverside.com/news/thread.tss?thread_id=29560) , they do
>>offer a free license for open source projects.
>>
>>http://www.cenqua.com/freelicenserequest!default.jspa
> 
> 
> cool.  Definitely worth investigating then - is it something SF are willing to
> install on their servers do you know?
> 

Re: [Springframework-developer] JMS remoting provider available

[<jue...@we...>]

James,
=20
I've looked at the JmsClientInterceptor in some more detail, and found =
that it uses the JMS QueueRequestor class (which I haven't seen in =
action before).
=20
I've noticed that QueueRequestor takes a Session and a Queue, internally =
creating a temporary queue for responses. However, in the current usage =
style, it would use the same Session for the entire lifetime of the =
JmsClientInterceptor bean (i.e. the entire application), and isn't =
properly closed on shutdown.=20
=20
While that might not cause any issues in a standalone client =
environment, what about usage of JmsClientInterceptor in a J2EE =
environment, for example a web app invoking some external process? And =
what about the JMS Session used by the QueueRequestor becoming stale, =
for example through a restart of the JMS server?
=20
It seems to me that we should get a Session via a given =
ConnectionFactory for each request here. In the J2EE case, this will =
usually be a pooled Session from a pooled Connection. In the standalone =
case, it can be from a single Connection, via Spring's =
SingleConnectionFactory.
=20
The problem with the ConnectionFactory approach is that we'd need to =
recreate a QueueRequestor instance for each request, with a freshly =
fetched Session. Does this mean that the QueueRequestor would create a =
new temporary Queue for each request in such a scenario? I wonder if =
that's feasible... However, what's the alternative, given that we =
shouldn't keep using the same Session forever?
=20
We could also add QueueRequestor/TopicRequestor support to JmsTemplate, =
offering "request" methods that throw unchecked JmsExceptions, fetching =
a fresh Session from the configured ConnectionFactory underneath. We =
could also offer a "requestAndConvert" method that takes Object as input =
message and also returns Object, analogous to =
"convertAndSend"/"receiveAndConvert".
=20
Already touching 1.2 RC1 work here, I guess :-)
=20
Looking forward to your thoughts,
=20
Juergen
=20
=20
P.S.: I'd like to rename JmsClientInterceptor, JmsServiceExporter etc to =
JmsInvokerClientInterceptor respectively JmsInvokerServiceExporter. It's =
about serializing Spring's remote invocations through JMS, not about =
native remoting support in JMS, and I feel that we should reflect this =
in the name. We use the terms "HTTP invoker" and "RMI invoker" too, when =
serializing RemoteInvocations via HTTP or RMI.
=20

________________________________

Von: spr...@li... im Auftrag =
von jas...@ma...
Gesendet: Mi 27.10.2004 20:56
An: spr...@li...
Betreff: Re: [Springframework-developer] JMS remoting provider available



On 27 Oct 2004, at 19:40, j=FCrgen h=F6ller [werk3AT] wrote:
> OK - thanks for the prompt response, James. I fully understand the
> effect of the JCAContainer; it's just that this is big enough to
> warrant Spring 1.2 :-) I'd prefer to publically introduce all those
> JMS-related new features in Spring 1.2 RC1, rather than in a 1.1.x
> point release. 1.2 RC1 is scheduled for early January, so isn't too
> far away...

Sounds great with me. We can have it all nicely documented by January
with a few more examples.

James
-------
http://radio.weblogs.com/0112098/



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [activemq-dev] Re: [Springframework-developer] Re: [activemq-dev] Re: message driven POJOs, a lightweight JCA container available

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

jas...@ma... wrote:

>>   I was thinking on doing somehow opposite thing. Use custom 
>> interceptor, which will transparently serializes all parameters and 
>> send them together with POJO name to JMS queue, which has pool of 
>> consumers (MDB's in my case) that are asynchronously executing that 
>> call on given POJO instance. :-)
> 
> Unless I'm missing something, that sounds exactly like Spring JMS 
> Remoting :). The only difference is to use pooling, we'd probably use 
> 'message driven pojos'.

   Similar, but POJO defined only once in a local Spring context and 
from client point of view it is not different in both cases:

   MyBean b = (MyBean) SpringContext.getBean( "asyncPojo");
   b.someMethod();  // executed asynchronously (no return)

   regards,
   Eugene

Re: [activemq-dev] Re: [Springframework-developer] Re: [activemq-dev] Re: message driven POJOs, a lightweight JCA container available

[<jas...@ma...>]

On 28 Oct 2004, at 17:54, Eugene Kuleshov wrote:
> Jason Carreira wrote:
>
>>>   Are you suggesting to replace Spring with XWork? :-)
>
>> No, not at all... The project I was discussing uses Spring to wire 
>> everything together. I was just suggesting that you can have Action 
>> classes (really command objects) which don't have to know anything 
>> about JMS, and could even be reused across JMS, Web, or even command 
>> line. I like my components to be decoupled from the deployment 
>> technologies.
>
>   Still can't see why XWork action wold be better then POJO's managed 
> by Spring. In my case MDB is basically delegating all processing to 
> given POJO's.
>
>   I was thinking on doing somehow opposite thing. Use custom 
> interceptor, which will transparently serializes all parameters and 
> send them together with POJO name to JMS queue, which has pool of 
> consumers (MDB's in my case) that are asynchronously executing that 
> call on given POJO instance. :-)

Unless I'm missing something, that sounds exactly like Spring JMS 
Remoting :). The only difference is to use pooling, we'd probably use 
'message driven pojos'.

James
-------
http://radio.weblogs.com/0112098/

Re: [Springframework-developer] FishEye for Jira page

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

On Thu, October 28, 2004 15:46, Matthew E. Porter said:
> According to the TSS announcement
> (http://theserverside.com/news/thread.tss?thread_id=3D29560) , they do
> offer a free license for open source projects.
>
> http://www.cenqua.com/freelicenserequest!default.jspa

cool.  Definitely worth investigating then - is it something SF are willi=
ng to
install on their servers do you know?

--=20
Darren Davison
Public Key: #DD356B0D

Re: [activemq-dev] Re: [Springframework-developer] Re: [activemq-dev] Re: message driven POJOs, a lightweight JCA container available

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

Jason Carreira wrote:

>>   Are you suggesting to replace Spring with XWork? :-)

> No, not at all... The project I was discussing uses Spring to wire 
> everything together. I was just suggesting that you can have Action 
> classes (really command objects) which don't have to know anything about 
> JMS, and could even be reused across JMS, Web, or even command line. I 
> like my components to be decoupled from the deployment technologies.

   Still can't see why XWork action wold be better then POJO's managed 
by Spring. In my case MDB is basically delegating all processing to 
given POJO's.

   I was thinking on doing somehow opposite thing. Use custom 
interceptor, which will transparently serializes all parameters and send 
them together with POJO name to JMS queue, which has pool of consumers 
(MDB's in my case) that are asynchronously executing that call on given 
POJO instance. :-)
   The only issue there is to detect in interceptor where POJO has been 
called from (skip interceptor if it is called from message 
consumer/MDB). Spring AOP documentation is saying that it is not 
recommended/slow to use control flow pointcuts, so other options would 
be to use custom pointcut or even AW or AspectJ.

   regards,
   Eugene

Re: [Springframework-developer] message driven POJOs, a lightweight JCA container available

[<jas...@ma...>]

On 28 Oct 2004, at 16:36, j=FCrgen h=F6ller [werk3AT] wrote:
> I guess all you're missing here is an interface that ProxyFactoryBean=20=

> should you use for the proxy:

DOH! It might be worth mentioning this in the manual; I tried my best=20
to figure it out from the docs.


> This will also remove the implicit CGLIB dependency, automatically=20
> using a JDK dynamic proxy instead.
>
> <bean id=3D"pooledEchoBean"=20
> class=3D"org.springframework.aop.framework.ProxyFactoryBean">
>   <property name=3D"proxyInterfaces">
>     <value>javax.jms.MessageListener</value>
>   </property>
>   <property name=3D"targetSource">
>     <ref local=3D"pooledEchoBeanTargetSource"/>
>   </property>
> </bean>
>
> ProxyFactoryBean can work without explicitly specified=20
> "proxyInterfaces", but just if there's a direct target object to=20
> analyze: It will proxy all interfaces implemented by the target then,=20=

> or create a CGLIB proxy for the target if there are no interfaces.

Fantastic!

Many thanks j=FCrgen again. I've made this change in CVS and its all=20
working well now.

James
-------
http://radio.weblogs.com/0112098/

RE: [Springframework-developer] message driven POJOs, a lightweight JCA container available

[<jue...@we...>]

I guess all you're missing here is an interface that ProxyFactoryBean =
should you use for the proxy: This will also remove the implicit CGLIB =
dependency, automatically using a JDK dynamic proxy instead.

<bean id=3D"pooledEchoBean" =
class=3D"org.springframework.aop.framework.ProxyFactoryBean">
  <property name=3D"proxyInterfaces">
    <value>javax.jms.MessageListener</value>
  </property>
  <property name=3D"targetSource">
    <ref local=3D"pooledEchoBeanTargetSource"/>
  </property>
</bean>

ProxyFactoryBean can work without explicitly specified =
"proxyInterfaces", but just if there's a direct target object to =
analyze: It will proxy all interfaces implemented by the target then, or =
create a CGLIB proxy for the target if there are no interfaces.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jas...@ma...
Sent: Thursday, October 28, 2004 4:37 PM
To: spr...@li...
Subject: Re: [Springframework-developer] message driven POJOs, a
lightweight JCA container available


On 28 Oct 2004, at 09:52, j=FCrgen h=F6ller [werk3AT] wrote:
> If there's an actual need to pool those target listeners, this could =20
> always be achieved through a ProxyFactoryBean with a pooling =20
> TargetSource, with the proxy implementing the MessageListener =20
> interface: From the point of view of the ActiveMQ message dispatcher,  =

> it would simply keep calling the shared MessageListener onMessage =20
> method, but this time on the proxy which will delegate to one of the =20
> instances in its backend pool.

I went a head and refactored to just use a MessageListener and so then =20
its up to the MessageListener instance to handle pooling - if its =20
needed. This makes the code much cleaner - great suggestion j=FCrgen.


I tried using the ProxyFactoryBean. Firstly this introduced a new =20
runtime dependency on cglib. Secondly it created this exception..

org.springframework.beans.factory.BeanCreationException: Error creating  =

bean with name 'inboundMessageB' defined in class path resource =20
[spring-with-proxyfactory.xml]: Can't resolve reference to bean =20
'pooledEchoBean' while setting property 'messageListener'; nested =20
exception is org.springframework.beans.factory.BeanCreationException: =20
Error creating bean with name 'pooledEchoBean' defined in class path =20
resource [spring-with-proxyfactory.xml]: Initialization of bean failed;  =

nested exception is org.aopalliance.aop.AspectException: null
org.springframework.beans.factory.BeanCreationException: Error creating  =

bean with name 'pooledEchoBean' defined in class path resource =20
[spring-with-proxyfactory.xml]: Initialization of bean failed; nested =20
exception is org.aopalliance.aop.AspectException: null
java.lang.IllegalStateException: Unknown callback class =20
org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedIntercept =

or
	at =20
net.sf.cglib.proxy.CallbackUtils.getGenerator(CallbackUtils.java:102)

The XML config file I was using is here...

http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20
container/src/test/org/codehaus/activemq/jca/spring-with-=20
proxyfactory.xml?r=3D1.1

and the test case is JCAContainerWithProxyFactoryTest.

Any ideas why I get this error? Its OK to use a ProxyFactoryBean with a  =

pooled TargetSource without using any AOP advice right?


As a work around and to avoid the cglib dependency, I've added a little  =

TargetSourceMessageListener helper class which works in a similar =20
way...

http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20
container/src/test/org/codehaus/activemq/jca/spring.xml?r=3D1.3
In terms of simplicity in the XML configuration file they're of similar  =

order.


Incidentally there's also an XA based test case to show how to use XA =20
based message consumption; you basically just ocnfigure the =20
TransactionManager to use.

http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20
container/src/test/org/codehaus/activemq/jca/spring-with-xa.xml?r=3D1.1

In this particular test case,  JCAContainerUsingXATest  we just use =20
JOTM directly.

James
-------
http://radio.weblogs.com/0112098/



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Re: Spring MDB / Message Driven POJOs

[James C. <jim...@do...>]

> > How does a combination of Spring + JOTM + JCA Container compare to
> > a J2EE/EJB Server?
>=20
> The biggest difference is there's no EJB :)

Spring is all about J2EE development, except without the EJB part. =
Spring
does a lot of other nice things for you along the way also.

The programming model is much simpler and "natural" as compared to EJB.=20

The Spring framework turns J2EE on its ear somewhat and provides =
alternative
mindsets (IoC vs. JNDI lookup) for many of the major J2EE features. It =
does
this without compromising your domain model the way that EJB does.=20

One of the few upsides (IMO) to a full-fledged EJB application are the
deployment offerings. If you need a cluster of app servers with seamless
failover support for all server resources (web sessions, SFSB, HA stubs,
federated JNDI, etc.) then a commercial J2EE vendor (or jBoss) is closer =
to
your needs.

[Note: that clustering and failover do not imply scalability -- actually
they work against scalability in some respects. If your enterprise
application need to scale, you can certainly develop them using =
Spring/J2EE
without EJB]

Re: [activemq-dev] Re: [Springframework-developer] Re: [activemq-dev] Re: message driven POJOs, a lightweight JCA container available

[Jason C. <ja...@ze...>]

Eugene Kuleshov wrote:

> jas...@ma... wrote:
>
>> Another idea to reuse legacy containers would be to just write a MDB 
>> wrapper which delegated to Spring to create the POJO. While its more 
>> painful to configure, it would allow you to reuse the legacy MDB 
>> infrastructure and use Spring for Dependency Injection.
>
>
>   That is exactly what we are using for a while. MDB and SSLB's for 
> remoting/facades/CMT and all internals is managed by Spring (pojo's, 
> IOC, AOP, pooling...). The only uglines is that to start nested 
> transactions we can't use Spring's TX wrappers and have to use helper 
> SSLB's to plug in into CMT.
>
>   regards,
>   Eugene
>
This is kind of like what I built... I built a JMS dispatcher for XWork 
which is all wired together with Spring. The components you write are 
just XWork Actions (just POJOs which implement the Action interface) and 
the rest of what happens, whether it's sending a response Message or 
sending 100 messages, one for each Object in a List, is handled by the 
framework outside the Action based on configuration. I made the 
Dispatcher a MessageListener and created a sub-class which is an MDB. 
I'm very interested in seeing how this Spring MDB replacement goes with 
transactional semantics, 'cause then this could be deployed in a very 
light container.

If anyone's interested in trying this out in a "real app" let me know, 
for now it's just been an interesting intellectual challenge and an 
example to use for the WebWork book of how XWork can be used outside the 
web...

Jason

Re: [Springframework-developer] FishEye for Jira page

[Matthew E. P. <mat...@me...>]

According to the TSS announcement 
(http://theserverside.com/news/thread.tss?thread_id=29560) , they do 
offer a free license for open source projects.

http://www.cenqua.com/freelicenserequest!default.jspa


Cheers,
   Matthew


On Oct 28, 2004, at 1:00 AM, Darren Davison wrote:

> On Wednesday 27 October 2004 22:38, jbetancourt wrote:
>> FishEye for Spring's Jira page?  Just a thought.
>>
>> http://fisheye.thecortex.net/
>
> I think it's a CVS viewer isn't it?  And AFAIK, there's no non 
> commercial
> license.  It does look like a very nice product though - some of the
> codehaus servers have it on a beta test.
>
> -- 
> Darren Davison
> Public Key: #DD356B0D
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Spring MDB / Message Driven POJOs

[<jas...@ma...>]

On 28 Oct 2004, at 09:24, Oliver Geisser wrote:
> Hi
>
> jas...@ma... wrote:
> [...]
>
>> As part of the ActiveMQ project we've written a small, Spring based & 
>>  easily embedded JCA container. Its just a few classes and is easy to 
>>  use on any project, just depending on Spring and the JCA APIs.
>> http://activemq.codehaus.org/JCA+Container
> [...]
>
> I understand that this is mainly targeted at integrating JMS.
>
> But I wonder how to combine this with a TM like JOTM?

FWIW there's an example in CVS now which uses JOTM directly for its 
TransactionManager. Just set the transactionManager property on the 
JCAContainer.


> And a related question: does the JCA Container support JDBC CA 
> Datasources, too?

The JCAContainer & JCAConnector classes have no JMS dependencies and so 
should work with any JCA ResourceAdapter. The only thing we've done is 
provide a default EndpointFactory which uses JMS by default; just set a 
different EndpointFactory on the JCAConnector bean and hey presto 
you're using anything else you like.


> With other words:
>
> How does a combination of Spring + JOTM + JCA Container compare to
> a J2EE/EJB Server?

The biggest difference is there's no EJB :)

James
-------
http://radio.weblogs.com/0112098/

Re: [Springframework-developer] message driven POJOs, a lightweight JCA container available

[<jas...@ma...>]

On 28 Oct 2004, at 09:52, j=FCrgen h=F6ller [werk3AT] wrote:
> If there's an actual need to pool those target listeners, this could =20=

> always be achieved through a ProxyFactoryBean with a pooling =20
> TargetSource, with the proxy implementing the MessageListener =20
> interface: =46rom the point of view of the ActiveMQ message =
dispatcher, =20
> it would simply keep calling the shared MessageListener onMessage =20
> method, but this time on the proxy which will delegate to one of the =20=

> instances in its backend pool.

I went a head and refactored to just use a MessageListener and so then =20=

its up to the MessageListener instance to handle pooling - if its =20
needed. This makes the code much cleaner - great suggestion j=FCrgen.


I tried using the ProxyFactoryBean. Firstly this introduced a new =20
runtime dependency on cglib. Secondly it created this exception..

org.springframework.beans.factory.BeanCreationException: Error creating =20=

bean with name 'inboundMessageB' defined in class path resource =20
[spring-with-proxyfactory.xml]: Can't resolve reference to bean =20
'pooledEchoBean' while setting property 'messageListener'; nested =20
exception is org.springframework.beans.factory.BeanCreationException: =20=

Error creating bean with name 'pooledEchoBean' defined in class path =20
resource [spring-with-proxyfactory.xml]: Initialization of bean failed; =20=

nested exception is org.aopalliance.aop.AspectException: null
org.springframework.beans.factory.BeanCreationException: Error creating =20=

bean with name 'pooledEchoBean' defined in class path resource =20
[spring-with-proxyfactory.xml]: Initialization of bean failed; nested =20=

exception is org.aopalliance.aop.AspectException: null
java.lang.IllegalStateException: Unknown callback class =20
org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedIntercept=20=

or
	at =20
net.sf.cglib.proxy.CallbackUtils.getGenerator(CallbackUtils.java:102)

The XML config file I was using is here...

http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20
container/src/test/org/codehaus/activemq/jca/spring-with-=20
proxyfactory.xml?r=3D1.1

and the test case is JCAContainerWithProxyFactoryTest.

Any ideas why I get this error? Its OK to use a ProxyFactoryBean with a =20=

pooled TargetSource without using any AOP advice right?


As a work around and to avoid the cglib dependency, I've added a little =20=

TargetSourceMessageListener helper class which works in a similar =20
way...

http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20
container/src/test/org/codehaus/activemq/jca/spring.xml?r=3D1.3
In terms of simplicity in the XML configuration file they're of similar =20=

order.


Incidentally there's also an XA based test case to show how to use XA =20=

based message consumption; you basically just ocnfigure the =20
TransactionManager to use.

http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20
container/src/test/org/codehaus/activemq/jca/spring-with-xa.xml?r=3D1.1

In this particular test case,  JCAContainerUsingXATest  we just use =20
JOTM directly.

James
-------
http://radio.weblogs.com/0112098/

Re: [Springframework-developer] message driven POJOs, a lightweight JCA container available

[Rod J. <ro...@in...>]

> Regarding pooling of the MessageListener objects: In many cases, this won't be necessary, as the MessageListener implementation will be thread-safe anyway - similar to the DAO and service object case, where a shared singleton instance is fine in 99% of the cases, so there's no need to pool them (like Stateless Session Beans force you to).
> 
> This means that in many cases, there's no need for a pool of listeners, i.e. there's no need to specify a TargetSource as message handler - a plain target object will do, specified as shared MessageListener bean.
> 
> If there's an actual need to pool those target listeners, this could always be achieved through a ProxyFactoryBean with a pooling TargetSource, with the proxy implementing the MessageListener interface: >From the point of view of the ActiveMQ message dispatcher, it would simply keep calling the shared MessageListener onMessage method, but this time on the proxy which will delegate to one of the instances in its backend pool.
Indeed. Transparent, and enabling the simplest thing that can possibly work.

We shouldn't slip into EJB-think--"pooling is always necessary".

R

Re: [Springframework-developer] message driven POJOs, a lightweight JCA container available

[<jas...@ma...>]

On 28 Oct 2004, at 09:52, j=FCrgen h=F6ller [werk3AT] wrote:
> James,
>
> Regarding pooling of the MessageListener objects: In many cases, this=20=

> won't be necessary, as the MessageListener implementation will be=20
> thread-safe anyway - similar to the DAO and service object case, where=20=

> a shared singleton instance is fine in 99% of the cases, so there's no=20=

> need to pool them (like Stateless Session Beans force you to).
>
> This means that in many cases, there's no need for a pool of=20
> listeners, i.e. there's no need to specify a TargetSource as message=20=

> handler - a plain target object will do, specified as shared=20
> MessageListener bean.

Agreed. I guess it depends if the MessageListener is stateful /=20
thread-safe or not.  Most of the MessageListener instances I write are=20=

not thread safe but that could be just me; though I can imagine ones=20
that are thread safe.


> If there's an actual need to pool those target listeners, this could=20=

> always be achieved through a ProxyFactoryBean with a pooling=20
> TargetSource, with the proxy implementing the MessageListener=20
> interface: =46rom the point of view of the ActiveMQ message =
dispatcher,=20
> it would simply keep calling the shared MessageListener onMessage=20
> method, but this time on the proxy which will delegate to one of the=20=

> instances in its backend pool.

Great idea.

> Essentially, it seems to me that the ActiveMQ container does not have=20=

> to be aware of Spring's TargetSource mechanism: Just invoking a=20
> provided MessageListener reference should be enough, without worrying=20=

> about the backend.
>
> Of course, the above argument does not affect the pooling of JMS=20
> Sessions in the background: That's the core of what ActiveMQ does=20
> here. I'm just talking about the need to pool the MessageListener=20
> implementation beans, which is probably as rare as the need to pool=20
> DAOs.

I guess it'd make things simpler if we assumed no pooling was needed=20
and then used the ProxyBeanFactory to add pooling when we need it.=20
Though the JCA ResourceAdapter already has to pool Endpoint objects=20
anyways in case they are stateful, so I figured it was easier to just=20
let the Endpoint talk to Spring's pool - but you're right, it'd be=20
cleaner to use the ProxyBeanFactory to add pooling when its required.=20
If nothing else it'd make it easier to use thread safe listeners=20
easier.

James
-------
http://radio.weblogs.com/0112098/