springframework-developer — Spring Framework developers list

Re: [Springframework-developer] new controller type

[John K.W. <jo...@sl...>]

Your css is quite broken in Safari, btw.  The page contents are all off 
screen...
	John

On Jan 30, 2004, at 3:56 AM, Ronald Haring wrote:

> Hello all,
>
> last months I have been looking around in the springframework, and I
> really liked what I saw. So I thought to merge my own workflow system 
> with
> the spring framework. After some time of working on it, it is now
> available as open source for all of you to enjoy.
>
> The main features of the workflow system that I have made is the
> navigation aspect on the html level. Many jsp pages have a common menu 
> to
> navigate the site. To show all the correct menu items on a page, you 
> have
> to be aware of the page you are working on and update the menu on each
> page. With the workflow system that I have made up, you only have to 
> have
> one include.jsp with all of the navigation actions that are allowed. 
> Based
> on the settings of an configuration xml file, the system will determine
> which actions should be available to users and which not. This is also
> dependant on the role of a logged in user. Also with the workflow 
> system,
> you can stack multiple controllers and let them perform their methods
> before returning a page.
>
> The website is available at www.competities.com/springworkflow and in
> sourceforge.net you can download the cvs sources. The sources come 
> with a
> demo rss reader in which all the aspects of the workflow system are
> (hopefully) demonstrated.
>
> Hopefully this is interesting enough for other people and maybe even
> usefull enought to get incorporated into the main spring mvc system.
>
> Gr
> Ronald
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Re: Proxying target classes

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

Les A. Hazlewood wrote:
> The problem is that java.security.ProtectionDomain of the CGLIB generated
> class is _not_ the same of the application classes loaded by the trusted
> classloader. Because of this, Exceptions are thrown all over the place 
> when we try to use that runtime-generated class.
> 
> java.lang.reflect.Proxy does not have this problem.  From the 1.4.2 J2SE
> API:
> 
> "The java.security.ProtectionDomain of a proxy class is the same as that
> of system classes loaded by the bootstrap class loader, such as
> java.lang.Object, because the code for a proxy class is generated by
> trusted system code. This protection domain will typically be granted
> java.security.AllPermission"
[snip]
> This is clearly a CGLIB problem.  Has anyone on the Spring team addressed
> this issue?  Do you know if there is a newer version of the CGLIB 
> distribution that solves this problem?

It is a problem, but I'm not sure there is a good answer.
java.lang.reflect.Proxy is allowed to belong to the ProtectionDomain of the
system classes because Sun wrote it. Short of CGLIB becoming part of the
JDK (haha) you will not be able to sign dynamically generated classes.
This will be more and more of a problem going forward as runtime bytecode
generation becomes more popular.

One option that has been discussed is the ability to spit out all of the
CGLIB classes to disk. You could then jar them up and sign them yourself.
CGLIB would have to be modified to look for the pre-generated classes
before generating new ones. There are some technical issues with doing this
properly, and it would be hard to guarantee that you've generated all the
necessary code offline, so I hope a different solution can be found.

Chris

Re: [Springframework-developer] Re: Proxying target classes

[Les A. H. <le...@ha...>]

> Colin Sampaleanu wrote:
> > The class is not final, and there are no final methods. And I was wrong,
> > it actually already implemented one interface, InitializingBean.
>
> I sent a reply before but it didn't show up. I'm pretty sure this is a bug
> that was fixed recently in CGLIB CVS. If you could try with a newer jar
> file I would appreciate it, otherwise let me know how to reproduce the
> problem.

As I've missed the beginning of this thread, I apologize if what I'm about to
ask was the exact same question about Proxying via CGLIB ;)  If not, it still
is related.

We recently came across an issue that might prevent us from using Spring
(because of CGLIB dependencies) in client-tier swing/webstart/applet
deployments.

We have to sign our swing deployment jars.  After the user accepts the signed
application, it is then assigned its own protection domain for that codesource,
as per J2SE security specs.  In some of our classes, we use a custom CGLIB
proxy to wrap access to ejb handles.  We're using the CGLIB jar that came with
the SpringFramework v. 1.0 M4.

The problem is that java.security.ProtectionDomain of the CGLIB generated class
is _not_ the same of the application classes loaded by the trusted classloader.
 Because of this, Exceptions are thrown all over the place when we try to use
that runtime-generated class.

java.lang.reflect.Proxy does not have this problem.  From the 1.4.2 J2SE API:

"The java.security.ProtectionDomain of a proxy class is the same as that of
system classes loaded by the bootstrap class loader, such as java.lang.Object,
because the code for a proxy class is generated by trusted system code. This
protection domain will typically be granted java.security.AllPermission"

This implies that any generated classes created by Spring's use of CGLIB would
not work either in a signed environment.

Our application server (which also uses CGLIB in some cases) does not have this
problem because it is granted the AllPermission upon startup, so we are happily
using Spring there.

This is clearly a CGLIB problem.  Has anyone on the Spring team addressed this
issue?  Do you know if there is a newer version of the CGLIB distribution that
solves this problem?

Luckily, a java.lang.reflect.Proxy conversion from our CGLIB implementation went
smoothly, but I consider that a workaround.  Just looking for information, and
seeing what you folks know about the problem...

Regards,

Les

Re: [Springframework-developer] Reworked transaction infrastructure

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

Yep. I think it's the most intuitive thing do to: The first =
("upper-most") transaction manager will drive synchronization. After =
all, there's hardly any need to use multiple transaction managers (that =
are active at the same time) now anyway, as transaction suspension =
should cover most of those scenarios.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Sa 31.01.2004 06:26
An: spr...@li...
Betreff: Re: [Springframework-developer] Reworked transaction =
infrastructure



Juergen,

I was looking a bit through the new code (although not enough), and was
wondering a bit about the transaction synchronization. The bug in
DataSourceTransactionManager/DataSourceUtils not allowing even one TM to
have synchronization on if there is more than one TM is of course no
longer there, and if there are multiple TMs and all except one have
synchronization turned off, all will be ok.

However,  I am not 100% clear on what happens if more than one has it
turned on (which will be the default when people use multiple TMs and
don't play with the flags). I am not talking about the
RequiresNew/Suspend situation, when it gets taken care of, but rather
with a simple PROPOGATION_REQUIRED. As I read the new code there will
not really be any ill effects, but rather the first TM to be involved
will handle all synchronization, e.g.
    private TransactionStatus newTransactionStatus(Object transaction,
boolean newTransaction,
                                                   boolean
newSynchronization, boolean debug,
                                                   Object
suspendedResources) {
        boolean actualNewSynchronization =3D newSynchronization &&
              =20
!TransactionSynchronizationManager.isSynchronizationActive();
        if (actualNewSynchronization) {
            TransactionSynchronizationManager.initSynchronization();
        }
        return new DefaultTransactionStatus(transaction, newTransaction,
actualNewSynchronization,
                                            debug, suspendedResources);
    }

Is this a correct assessment?

Regards,
Colin


j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>
>I've significantly reworked our transaction infrastructure last week, =
to effectively provide the same support for transaction suspension as =
EJB CMT does.  Accordingly, I've introduced propagation behaviors =
"REQUIRES_NEW", "NOT_SUPPORTED", and "NEVER" for all our =
PlatformTransactionManagers. I've committed this yesterday evening, now =
that CVS seems to work again.
>
>JtaTransactionManager needs to access the =
javax.transaction.TransactionManager for transaction suspension; =
unfortunately, the TransactionManager location is not defined by J2EE =
(O/R mappers have a similar problem for cache callbacks in a JTA =
environment). Thus, I've introduced a JtaDialect interface (analogous to =
our JdoDialect), containing "getInternalTransactionManager" and =
"applyIsolationLevel" methods (the latter factored out from =
JtaTransactionManager's template method into this strategy).
>
>The default dialect implementations is JndiLookupJtaDialect, with a =
configurable "templateManagerName" JNDI location (not doing anything =
about the isolation level); its Javadoc states a couple of well-known =
JTA TransactionManager locations in popular application servers. =
Additionally, I've added JotmJtaDialect and WebSphereJtaDialect, which =
both require specific static accessor methods to obtain the JTA =
TransactionManager. I've simply taken the corresponding code from =
Hibernate's TransactionManagerLookups.
>
>There's also a new "jtaDialect" property in LocalSessionFactoryBean, =
allowing to use a Spring-configured JtaDialect for Hibernate's =
TransactionManagerLookup. This avoids double configuration of the =
server-specific lookup strategy. As when providing a DataSource, the =
corresponding Hibernate property will be set implictly when a JtaDialect =
is provided.
>
>I've tested transaction suspension with HibernateTransactionManager and =
DataSourceTransactionManager in Tomcat, Resin, and JBoss; with =
JtaTransactionManager and a corresponding JndiLookupJtaDialect, in Resin =
and JBoss. Works nicely in all cases: I'd be happy if someone else tried =
WebLogic, WebSphere, JOTM, etc (there's nothing to worry about there, =
just validating the TransactionManager lookup strategies).
>
>I've also added a ClobStringType for Hibernate, using a =
LocalSessionFactoryBean-specified LobHandler for mapping Strings to =
CLOBs. You can specify ClobStringType for such fields in your Hibernate =
mappings even if just using CLOBs in certain environments: =
DefaultLobHandler will simply delegate to =
PreparedStatement.setString/ResultSet.getString anyway. On Oracle, =
simply configure OracleLobHandler in your application context - the =
Hibernate mapping file does not have to change.
>
>ClobStringType is particularly useful if you need Strings with more =
than 4000 characters in Oracle mapped to persistent objects via =
Hibernate. You need to use CLOBs for such long texts in Oracle; and due =
to Oracle's peculiar handling of LOBs, you need a special strategy like =
OracleLobHandler. On other databases like MySQL, type "longtext" is =
fine, to be used like normal String values. Our LobHandler abstraction =
allows to turn this into a configuration issue.
>
>If you get the chance, please check this out promptly, as we intend to =
release 1.0 RC1 this weekend!
>
>Juergen
>
>




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Proxying target classes

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

Colin Sampaleanu wrote:
> The class is not final, and there are no final methods. And I was wrong,
> it actually already implemented one interface, InitializingBean.

I sent a reply before but it didn't show up. I'm pretty sure this is a bug
that was fixed recently in CGLIB CVS. If you could try with a newer jar
file I would appreciate it, otherwise let me know how to reproduce the
problem.

Thanks,
Chris

[Springframework-developer] Spring references: Compiere, Jasper ?

[Double D. <dou...@ya...>]

Rod, Juergen,

Now that Spring is getting recognition as the leading
Opensource Java Framework for Enterprise Applications
(assuming Spring 1.1 will handle Security).

So, what are needed next are real REFERENCES for real
enterprise applications.  Internal Corporate
applications would be nice references, but those would
just be words.  

Much more powerful references would be to get the
leading Opensource Enterprise Applications to use
Spring.  Perhaps the Spring community can evangelize
to the projects below.

ERP e.g. http://sourceforge.net/projects/compiere/
Reports e.g.
http://sourceforge.net/projects/jasperreports/
EIP e.g.
http://jakarta.apache.org/jetspeed/site/index.html
RDBMS e.g.
http://incubator.apache.org/projects/axion.html

In particular, the ultimate reference would be to get
Compiere ERP to use Spring.  Compiere is very popular
(see download stats on SourceForge).  It is 100% Java
and uses the Mozilla License.  The current
LinuxMagazine has a nice interview with the founders
of the project, but I can’t find it.  Since they are
building an ERP, they are conservative (until now,
they only target Oracle).  Their next major task is to
support other databases.  A nice way for Spring to
help.

Cheers,
DD.


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: [Springframework-developer] Reworked transaction infrastructure

[Colin S. <col...@ex...>]

Juergen,

I was looking a bit through the new code (although not enough), and was 
wondering a bit about the transaction synchronization. The bug in 
DataSourceTransactionManager/DataSourceUtils not allowing even one TM to 
have synchronization on if there is more than one TM is of course no 
longer there, and if there are multiple TMs and all except one have 
synchronization turned off, all will be ok.

However,  I am not 100% clear on what happens if more than one has it 
turned on (which will be the default when people use multiple TMs and 
don't play with the flags). I am not talking about the 
RequiresNew/Suspend situation, when it gets taken care of, but rather 
with a simple PROPOGATION_REQUIRED. As I read the new code there will 
not really be any ill effects, but rather the first TM to be involved 
will handle all synchronization, e.g.
    private TransactionStatus newTransactionStatus(Object transaction, 
boolean newTransaction,
                                                   boolean 
newSynchronization, boolean debug,
                                                   Object 
suspendedResources) {
        boolean actualNewSynchronization = newSynchronization &&
                
!TransactionSynchronizationManager.isSynchronizationActive();
        if (actualNewSynchronization) {
            TransactionSynchronizationManager.initSynchronization();
        }
        return new DefaultTransactionStatus(transaction, newTransaction, 
actualNewSynchronization,
                                            debug, suspendedResources);
    }

Is this a correct assessment?

Regards,
Colin


jürgen höller [werk3AT] wrote:

>Everybody,
> 
>I've significantly reworked our transaction infrastructure last week, to effectively provide the same support for transaction suspension as EJB CMT does.  Accordingly, I've introduced propagation behaviors "REQUIRES_NEW", "NOT_SUPPORTED", and "NEVER" for all our PlatformTransactionManagers. I've committed this yesterday evening, now that CVS seems to work again.
>
>JtaTransactionManager needs to access the javax.transaction.TransactionManager for transaction suspension; unfortunately, the TransactionManager location is not defined by J2EE (O/R mappers have a similar problem for cache callbacks in a JTA environment). Thus, I've introduced a JtaDialect interface (analogous to our JdoDialect), containing "getInternalTransactionManager" and "applyIsolationLevel" methods (the latter factored out from JtaTransactionManager's template method into this strategy).
>
>The default dialect implementations is JndiLookupJtaDialect, with a configurable "templateManagerName" JNDI location (not doing anything about the isolation level); its Javadoc states a couple of well-known JTA TransactionManager locations in popular application servers. Additionally, I've added JotmJtaDialect and WebSphereJtaDialect, which both require specific static accessor methods to obtain the JTA TransactionManager. I've simply taken the corresponding code from Hibernate's TransactionManagerLookups.
>
>There's also a new "jtaDialect" property in LocalSessionFactoryBean, allowing to use a Spring-configured JtaDialect for Hibernate's TransactionManagerLookup. This avoids double configuration of the server-specific lookup strategy. As when providing a DataSource, the corresponding Hibernate property will be set implictly when a JtaDialect is provided. 
> 
>I've tested transaction suspension with HibernateTransactionManager and DataSourceTransactionManager in Tomcat, Resin, and JBoss; with JtaTransactionManager and a corresponding JndiLookupJtaDialect, in Resin and JBoss. Works nicely in all cases: I'd be happy if someone else tried WebLogic, WebSphere, JOTM, etc (there's nothing to worry about there, just validating the TransactionManager lookup strategies).
> 
>I've also added a ClobStringType for Hibernate, using a LocalSessionFactoryBean-specified LobHandler for mapping Strings to CLOBs. You can specify ClobStringType for such fields in your Hibernate mappings even if just using CLOBs in certain environments: DefaultLobHandler will simply delegate to PreparedStatement.setString/ResultSet.getString anyway. On Oracle, simply configure OracleLobHandler in your application context - the Hibernate mapping file does not have to change.
> 
>ClobStringType is particularly useful if you need Strings with more than 4000 characters in Oracle mapped to persistent objects via Hibernate. You need to use CLOBs for such long texts in Oracle; and due to Oracle's peculiar handling of LOBs, you need a special strategy like OracleLobHandler. On other databases like MySQL, type "longtext" is fine, to be used like normal String values. Our LobHandler abstraction allows to turn this into a configuration issue.
> 
>If you get the chance, please check this out promptly, as we intend to release 1.0 RC1 this weekend!
> 
>Juergen
> 
>

Re: [Springframework-developer] Reworked transaction infrastructure

[Colin S. <col...@ex...>]

Everything is set as PROPOGATION_REQUIRED. I wouldn't be too surprised 
if this is a JBoss bug; i.e. its transaction manager is getting confused 
by the multiple levels of nesting.   Hopefully I can get some time in 
the next week or so to trace though this, although I don't relish the 
thought of going into the JBoss source...


jürgen höller [werk3AT] wrote:

>Hmmm, I don't see how Spring's transaction infrastructure could cause such behavior... Are you using transaction suspension here (i.e. PROPAGATION_REQUIRES_NEW) at all? If not, there's hardly anything that Spring could mess up. Better to double-check this, though: I guess the debugger is your friend here ;-)
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Mi 28.01.2004 18:21
>An: spr...@li...; jürgen höller [werk3AT]
>Betreff: Re: [Springframework-developer] Reworked transaction infrastructure
>
>
>
>I've been using the new code for a few days with generaly no issues.
>I've come upon a problem now which may or may not have been there
>before; it's hard for me to tell, and I can't roll back to the previous
>spring version since I need some of the new features elsewhere.
>
>The use case is fairly complex. There is a hierarchical appcontext
>(although that is irrelevant), with a number of service beans in there
>wrapped transactionally with an interceptor using JTATransactionManager
>and with the Hibernate interceptor, via BeanNameAutoProxyCreator. There
>is also usage of CMT Session Beans, which get called from Spring
>objects, and call to Spring objects. So I have a problem with the
>following sequence:
>
>- JMS call to MessageDrivenBean, DispatcherBean
>- DispatcherBean gets real POJO service object,
>PackagingMessageHandlerImpl, from a context it locates, and delegates to
>it. PackagingMessageHandlerImpl is transactionally wrapped by the context.
>- PackagingMessageHandlerImpl calls out to ApplicationController, a
>Session Bean (with CMT)
>- ApplicationController gets real POJO service object from context,
>ApplicationControllerServiceImpl, and delegates to it.
>- ApplicationControllerServiceImpl does some work using some
>Hibernate-based Mappers/DAOs.
>- ApplicationControllerServiceImpl returns
>- transaction manager calls commit, but no commit actually done since
>not a new transaction, return continues
>- ApplicationController (sessionBean) returns
>
>then I get the following blowup, where JBoss is pretty confused. Looks
>like an unknown connection is attempted to be closed, and the real one
>isn't (as per the subsequent error about closing connections yourself).
>Hard to tell who is at fault here. I will try to dig into this deeper
>myself, but if you have any ideas they would be much appreciated:
>
>2004-01-28 10:54:38,934 DEBUG
>[org.springframework.transaction.interceptor.TransactionInterceptor]
>Invoking commit for transaction on method 'uploadDistribution'
>2004-01-28 10:54:38,934 DEBUG
>[org.springframework.orm.hibernate.HibernateInterceptor] Not closing
>pre-bound Hibernate session after interceptor
>2004-01-28 10:54:38,934 INFO 
>[org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener]
>throwable from unregister connection
>java.lang.IllegalStateException: Trying to return an unknown
>connection2! org.jboss.resource.adapter.jdbc.WrappedConnection@5cd34e
>    at
>org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:275)
>    at
>org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:550)
>    at
>org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:287)
>    at
>org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:127)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:324)
>    at
>org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:375)
>    at
>org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199)
>    at
>org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190)
>    at
>org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72)
>    at
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
>    at
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267)
>    at
>org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
>    at
>org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118)
>    at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
>    at
>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
>    at
>org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331)
>    at org.jboss.ejb.Container.invoke(Container.java:700)
>    at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
>    at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:324)
>    at
>org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>    at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101)
>    at
>org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90)
>    at
>org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
>    at
>org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45)
>    at
>org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:100)
>    at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
>    at $Proxy99.uploadDistribution(Unknown Source)
>    at
>com.whatever.coreserv.services.messaging.PackagingMessageHandlerImpl.onMessage(PackagingMessageHandlerImpl.java:156)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:324)
>    at
>org.springframework.aop.framework.AopProxyUtils.invokeJoinpointUsingReflection(AopProxyUtils.java:59)
>    at
>org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:201)
>    at
>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
>    at
>org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:156)
>    at
>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:196)
>    at
>org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInterceptor.java:84)
>    at
>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:196)
>    at
>org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:135)
>    at $Proxy114.onMessage(Unknown Source)
>    at
>com.whatever.coreserv.services.messaging.DispatcherBean.onMessage(DispatcherBean.java:96)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:324)
>    at
>org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:460)
>    at
>org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
>    at
>org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:62)
>    at
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
>    at
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:240)
>    at
>org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
>    at
>org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:90)
>    at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
>    at
>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
>    at
>org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:374)
>    at org.jboss.ejb.Container.invoke(Container.java:700)
>    at
>org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:827)
>    at
>org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1117)
>    at
>org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:256)
>    at
>org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:633)
>    at
>org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:433)
>    at org.jboss.mq.SpySession.run(SpySession.java:298)
>    at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:180)
>    at
>EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:727)
>    at java.lang.Thread.run(Thread.java:534)
>2004-01-28 10:54:39,167 INFO 
>[org.jboss.resource.connectionmanager.CachedConnectionManager]
>Successfully closed a connection for you.  Please close them yourself:
>org.jboss.resource.adapter.jdbc.WrappedConnection@5cd34e
>java.lang.Exception: Stack Trace
>    at
>org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:376)
>    at
>org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199)
>    at
>org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190)
>    at
>org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72)
>    at
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
>    at
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267)
>    at
>org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
>    at
>org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118)
>    at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
>    at
>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
>    at
>org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331)
>    at org.jboss.ejb.Container.invoke(Container.java:700)
>    at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
>    at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:324)
>    at
>org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>    at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101)
>    at
>org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90)
>    at
>org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
>    at
>org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45)
>    at
>org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:100)
>    at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
>    at $Proxy99.uploadDistribution(Unknown Source)
>    at
>com.whatever.coreserv.services.messaging.PackagingMessageHandlerImpl.onMessage(PackagingMessageHandlerImpl.java:156)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:324)
>    at
>org.springframework.aop.framework.AopProxyUtils.invokeJoinpointUsingReflection(AopProxyUtils.java:59)
>    at
>org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:201)
>    at
>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
>    at
>org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:156)
>    at
>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:196)
>    at
>org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInterceptor.java:84)
>    at
>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:196)
>    at
>org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:135)
>    at $Proxy114.onMessage(Unknown Source)
>    at
>com.whatever.coreserv.services.messaging.DispatcherBean.onMessage(DispatcherBean.java:96)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:324)
>    at
>org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:460)
>    at
>org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
>    at
>org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:62)
>    at
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
>    at
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:240)
>    at
>org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
>    at
>org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:90)
>    at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
>    at
>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
>    at
>org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:374)
>    at org.jboss.ejb.Container.invoke(Container.java:700)
>    at
>org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:827)
>    at
>org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1117)
>    at
>org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:256)
>    at
>org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:633)
>    at
>org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:433)
>    at org.jboss.mq.SpySession.run(SpySession.java:298)
>    at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:180)
>    at
>EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:727)
>    at java.lang.Thread.run(Thread.java:534)
>
>
>
>
>
>
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Everybody,
>>
>>I've significantly reworked our transaction infrastructure last week, to effectively provide the same support for transaction suspension as EJB CMT does.  Accordingly, I've introduced propagation behaviors "REQUIRES_NEW", "NOT_SUPPORTED", and "NEVER" for all our PlatformTransactionManagers. I've committed this yesterday evening, now that CVS seems to work again.
>>
>>JtaTransactionManager needs to access the javax.transaction.TransactionManager for transaction suspension; unfortunately, the TransactionManager location is not defined by J2EE (O/R mappers have a similar problem for cache callbacks in a JTA environment). Thus, I've introduced a JtaDialect interface (analogous to our JdoDialect), containing "getInternalTransactionManager" and "applyIsolationLevel" methods (the latter factored out from JtaTransactionManager's template method into this strategy).
>>
>>The default dialect implementations is JndiLookupJtaDialect, with a configurable "templateManagerName" JNDI location (not doing anything about the isolation level); its Javadoc states a couple of well-known JTA TransactionManager locations in popular application servers. Additionally, I've added JotmJtaDialect and WebSphereJtaDialect, which both require specific static accessor methods to obtain the JTA TransactionManager. I've simply taken the corresponding code from Hibernate's TransactionManagerLookups.
>>
>>There's also a new "jtaDialect" property in LocalSessionFactoryBean, allowing to use a Spring-configured JtaDialect for Hibernate's TransactionManagerLookup. This avoids double configuration of the server-specific lookup strategy. As when providing a DataSource, the corresponding Hibernate property will be set implictly when a JtaDialect is provided.
>>
>>I've tested transaction suspension with HibernateTransactionManager and DataSourceTransactionManager in Tomcat, Resin, and JBoss; with JtaTransactionManager and a corresponding JndiLookupJtaDialect, in Resin and JBoss. Works nicely in all cases: I'd be happy if someone else tried WebLogic, WebSphere, JOTM, etc (there's nothing to worry about there, just validating the TransactionManager lookup strategies).
>>
>>I've also added a ClobStringType for Hibernate, using a LocalSessionFactoryBean-specified LobHandler for mapping Strings to CLOBs. You can specify ClobStringType for such fields in your Hibernate mappings even if just using CLOBs in certain environments: DefaultLobHandler will simply delegate to PreparedStatement.setString/ResultSet.getString anyway. On Oracle, simply configure OracleLobHandler in your application context - the Hibernate mapping file does not have to change.
>>
>>ClobStringType is particularly useful if you need Strings with more than 4000 characters in Oracle mapped to persistent objects via Hibernate. You need to use CLOBs for such long texts in Oracle; and due to Oracle's peculiar handling of LOBs, you need a special strategy like OracleLobHandler. On other databases like MySQL, type "longtext" is fine, to be used like normal String values. Our LobHandler abstraction allows to turn this into a configuration issue.
>>
>>If you get the chance, please check this out promptly, as we intend to release 1.0 RC1 this weekend!
>>
>>Juergen
>>
>>    
>>

[Springframework-developer] new controller type

[Ronald H. <rh...@co...>]

Hello all,

last months I have been looking around in the springframework, and I
really liked what I saw. So I thought to merge my own workflow system with
the spring framework. After some time of working on it, it is now
available as open source for all of you to enjoy.

The main features of the workflow system that I have made is the
navigation aspect on the html level. Many jsp pages have a common menu to
navigate the site. To show all the correct menu items on a page, you have
to be aware of the page you are working on and update the menu on each
page. With the workflow system that I have made up, you only have to have
one include.jsp with all of the navigation actions that are allowed. Based
on the settings of an configuration xml file, the system will determine
which actions should be available to users and which not. This is also
dependant on the role of a logged in user. Also with the workflow system,
you can stack multiple controllers and let them perform their methods
before returning a page.

The website is available at www.competities.com/springworkflow and in
sourceforge.net you can download the cvs sources. The sources come with a
demo rss reader in which all the aspects of the workflow system are
(hopefully) demonstrated.

Hopefully this is interesting enough for other people and maybe even
usefull enought to get incorporated into the main spring mvc system.

Gr
Ronald

[Springframework-developer] PropertyEditor question

[Les A. H. <le...@ha...>]

Gents,

Using the Spring web mvc stuff, I understand we need PropertyEditors for certain
fields.  I've been ok using them up until now, but now I seem to be stuck.

I have a form which lists ip addresses, one field per ip, all named
"ipAddresses" (thereby making the request parameter a String[] with the values
from all fields).  I have a JavaBean that requires a java.util.Set of
InetAddresses.

in the initBinder() method I specify my custom InetAddressSetEditor which takes
in a comma-delimited string of ip addresses in the setAsText method.

All I do is tokenize that string, call InetAddres.getHostName() for each
returned token and finally call setValue(myNewlyConstructedSet) and return.

I turned on the DEBUG info level in Spring and see that it never acquired my
PropertyEditor in the BeanWrapperImpl class, specifically in the

public Object doTypeConversionIfNecessary

method starting on line 678.  The failure occurs on one of the checks to see if
my property editor is null (starting on line 712).

Here's my debug output:
DEBUG [BeanWrapperImpl] Convert: StringArray to CommaDelimitedString
[10.0.0.1,127.0.0.1]
DEBUG [BeanWrapperImpl] Convert: String to [interface java.util.Set]
DEBUG [BeanWrapperImpl] Using property editor [null]


How come my property editor isn't being set?

My method from my subclass of SimpleFormController:

protected void initBinder( HttpServletRequest request,
                           ServletRequestDataBinder binder ) {
    binder.registerCustomEditor(java.util.Set.class,
                                new InetAddressSetEditor());
}

What gives?  What did I do wrong?

Thanks very much for any early replies...I'm hitting a deadline later today and
this is all that holds me up....

Regards,

Les

P.S.  I understand this is a general user question, but because of the code
references, I figured it would be better suited to the developers list.

Re: [Springframework-developer] Reworked transaction infrastructure

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

Hmmm, I don't see how Spring's transaction infrastructure could cause =
such behavior... Are you using transaction suspension here (i.e. =
PROPAGATION_REQUIRES_NEW) at all? If not, there's hardly anything that =
Spring could mess up. Better to double-check this, though: I guess the =
debugger is your friend here ;-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mi 28.01.2004 18:21
An: spr...@li...; j=FCrgen h=F6ller =
[werk3AT]
Betreff: Re: [Springframework-developer] Reworked transaction =
infrastructure



I've been using the new code for a few days with generaly no issues.
I've come upon a problem now which may or may not have been there
before; it's hard for me to tell, and I can't roll back to the previous
spring version since I need some of the new features elsewhere.

The use case is fairly complex. There is a hierarchical appcontext
(although that is irrelevant), with a number of service beans in there
wrapped transactionally with an interceptor using JTATransactionManager
and with the Hibernate interceptor, via BeanNameAutoProxyCreator. There
is also usage of CMT Session Beans, which get called from Spring
objects, and call to Spring objects. So I have a problem with the
following sequence:

- JMS call to MessageDrivenBean, DispatcherBean
- DispatcherBean gets real POJO service object,
PackagingMessageHandlerImpl, from a context it locates, and delegates to
it. PackagingMessageHandlerImpl is transactionally wrapped by the =
context.
- PackagingMessageHandlerImpl calls out to ApplicationController, a
Session Bean (with CMT)
- ApplicationController gets real POJO service object from context,
ApplicationControllerServiceImpl, and delegates to it.
- ApplicationControllerServiceImpl does some work using some
Hibernate-based Mappers/DAOs.
- ApplicationControllerServiceImpl returns
- transaction manager calls commit, but no commit actually done since
not a new transaction, return continues
- ApplicationController (sessionBean) returns

then I get the following blowup, where JBoss is pretty confused. Looks
like an unknown connection is attempted to be closed, and the real one
isn't (as per the subsequent error about closing connections yourself).
Hard to tell who is at fault here. I will try to dig into this deeper
myself, but if you have any ideas they would be much appreciated:

2004-01-28 10:54:38,934 DEBUG
[org.springframework.transaction.interceptor.TransactionInterceptor]
Invoking commit for transaction on method 'uploadDistribution'
2004-01-28 10:54:38,934 DEBUG
[org.springframework.orm.hibernate.HibernateInterceptor] Not closing
pre-bound Hibernate session after interceptor
2004-01-28 10:54:38,934 INFO=20
[org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEve=
ntListener]
throwable from unregister connection
java.lang.IllegalStateException: Trying to return an unknown
connection2! org.jboss.resource.adapter.jdbc.WrappedConnection@5cd34e
    at
org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterCo=
nnection(CachedConnectionManager.java:275)
    at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEven=
tListener.connectionClosed(TxConnectionManager.java:550)
    at
org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(=
BaseWrapperManagedConnection.java:287)
    at
org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection=
.java:127)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(Cac=
hedConnectionManager.java:375)
    at
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAware=
Object(CachedConnectionManager.java:199)
    at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:190)
    at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Stateles=
sSessionInstanceInterceptor.java:72)
    at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
    at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:267)
    at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
    at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java=
:118)
    at =
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
    at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
    at
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionCo=
ntainer.java:331)
    at org.jboss.ejb.Container.invoke(Container.java:700)
    at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDis=
patcher.java:284)
    at =
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
    at =
org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101)
    at
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90=
)
    at
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java=
:46)
    at
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45)
    at
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionIn=
terceptor.java:100)
    at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
    at $Proxy99.uploadDistribution(Unknown Source)
    at
com.whatever.coreserv.services.messaging.PackagingMessageHandlerImpl.onMe=
ssage(PackagingMessageHandlerImpl.java:156)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at
org.springframework.aop.framework.AopProxyUtils.invokeJoinpointUsingRefle=
ction(AopProxyUtils.java:59)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpo=
int(ReflectiveMethodInvocation.java:201)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:176)
    at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke=
(TransactionInterceptor.java:156)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
    at
org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateIn=
terceptor.java:84)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
    at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAop=
Proxy.java:135)
    at $Proxy114.onMessage(Unknown Source)
    at
com.whatever.coreserv.services.messaging.DispatcherBean.onMessage(Dispatc=
herBean.java:96)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at
org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageD=
rivenContainer.java:460)
    at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:186)
    at
org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDriv=
enInstanceInterceptor.java:62)
    at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
    at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:240)
    at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
    at
org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterc=
eptor.java:90)
    at =
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
    at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
    at
org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContaine=
r.java:374)
    at org.jboss.ejb.Container.invoke(Container.java:700)
    at
org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.=
java:827)
    at
org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessa=
ge(JMSContainerInvoker.java:1117)
    at
org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:256)
    at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageC=
onsumer.java:633)
    at
org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:433)
    at org.jboss.mq.SpySession.run(SpySession.java:298)
    at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:180)
    at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor=
.java:727)
    at java.lang.Thread.run(Thread.java:534)
2004-01-28 10:54:39,167 INFO=20
[org.jboss.resource.connectionmanager.CachedConnectionManager]
Successfully closed a connection for you.  Please close them yourself:
org.jboss.resource.adapter.jdbc.WrappedConnection@5cd34e
java.lang.Exception: Stack Trace
    at
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(Cac=
hedConnectionManager.java:376)
    at
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAware=
Object(CachedConnectionManager.java:199)
    at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:190)
    at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Stateles=
sSessionInstanceInterceptor.java:72)
    at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
    at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:267)
    at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
    at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java=
:118)
    at =
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
    at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
    at
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionCo=
ntainer.java:331)
    at org.jboss.ejb.Container.invoke(Container.java:700)
    at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDis=
patcher.java:284)
    at =
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
    at =
org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101)
    at
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90=
)
    at
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java=
:46)
    at
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45)
    at
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionIn=
terceptor.java:100)
    at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
    at $Proxy99.uploadDistribution(Unknown Source)
    at
com.whatever.coreserv.services.messaging.PackagingMessageHandlerImpl.onMe=
ssage(PackagingMessageHandlerImpl.java:156)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at
org.springframework.aop.framework.AopProxyUtils.invokeJoinpointUsingRefle=
ction(AopProxyUtils.java:59)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpo=
int(ReflectiveMethodInvocation.java:201)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:176)
    at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke=
(TransactionInterceptor.java:156)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
    at
org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateIn=
terceptor.java:84)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
    at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAop=
Proxy.java:135)
    at $Proxy114.onMessage(Unknown Source)
    at
com.whatever.coreserv.services.messaging.DispatcherBean.onMessage(Dispatc=
herBean.java:96)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at
org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageD=
rivenContainer.java:460)
    at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:186)
    at
org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDriv=
enInstanceInterceptor.java:62)
    at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
    at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:240)
    at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
    at
org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterc=
eptor.java:90)
    at =
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
    at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
    at
org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContaine=
r.java:374)
    at org.jboss.ejb.Container.invoke(Container.java:700)
    at
org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.=
java:827)
    at
org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessa=
ge(JMSContainerInvoker.java:1117)
    at
org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:256)
    at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageC=
onsumer.java:633)
    at
org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:433)
    at org.jboss.mq.SpySession.run(SpySession.java:298)
    at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:180)
    at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor=
.java:727)
    at java.lang.Thread.run(Thread.java:534)








j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>
>I've significantly reworked our transaction infrastructure last week, =
to effectively provide the same support for transaction suspension as =
EJB CMT does.  Accordingly, I've introduced propagation behaviors =
"REQUIRES_NEW", "NOT_SUPPORTED", and "NEVER" for all our =
PlatformTransactionManagers. I've committed this yesterday evening, now =
that CVS seems to work again.
>
>JtaTransactionManager needs to access the =
javax.transaction.TransactionManager for transaction suspension; =
unfortunately, the TransactionManager location is not defined by J2EE =
(O/R mappers have a similar problem for cache callbacks in a JTA =
environment). Thus, I've introduced a JtaDialect interface (analogous to =
our JdoDialect), containing "getInternalTransactionManager" and =
"applyIsolationLevel" methods (the latter factored out from =
JtaTransactionManager's template method into this strategy).
>
>The default dialect implementations is JndiLookupJtaDialect, with a =
configurable "templateManagerName" JNDI location (not doing anything =
about the isolation level); its Javadoc states a couple of well-known =
JTA TransactionManager locations in popular application servers. =
Additionally, I've added JotmJtaDialect and WebSphereJtaDialect, which =
both require specific static accessor methods to obtain the JTA =
TransactionManager. I've simply taken the corresponding code from =
Hibernate's TransactionManagerLookups.
>
>There's also a new "jtaDialect" property in LocalSessionFactoryBean, =
allowing to use a Spring-configured JtaDialect for Hibernate's =
TransactionManagerLookup. This avoids double configuration of the =
server-specific lookup strategy. As when providing a DataSource, the =
corresponding Hibernate property will be set implictly when a JtaDialect =
is provided.
>
>I've tested transaction suspension with HibernateTransactionManager and =
DataSourceTransactionManager in Tomcat, Resin, and JBoss; with =
JtaTransactionManager and a corresponding JndiLookupJtaDialect, in Resin =
and JBoss. Works nicely in all cases: I'd be happy if someone else tried =
WebLogic, WebSphere, JOTM, etc (there's nothing to worry about there, =
just validating the TransactionManager lookup strategies).
>
>I've also added a ClobStringType for Hibernate, using a =
LocalSessionFactoryBean-specified LobHandler for mapping Strings to =
CLOBs. You can specify ClobStringType for such fields in your Hibernate =
mappings even if just using CLOBs in certain environments: =
DefaultLobHandler will simply delegate to =
PreparedStatement.setString/ResultSet.getString anyway. On Oracle, =
simply configure OracleLobHandler in your application context - the =
Hibernate mapping file does not have to change.
>
>ClobStringType is particularly useful if you need Strings with more =
than 4000 characters in Oracle mapped to persistent objects via =
Hibernate. You need to use CLOBs for such long texts in Oracle; and due =
to Oracle's peculiar handling of LOBs, you need a special strategy like =
OracleLobHandler. On other databases like MySQL, type "longtext" is =
fine, to be used like normal String values. Our LobHandler abstraction =
allows to turn this into a configuration issue.
>
>If you get the chance, please check this out promptly, as we intend to =
release 1.0 RC1 this weekend!
>
>Juergen
>
>



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Fw: [springframework-developer] PropertyEditor question

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

FYI, I've just made my suggestion work through the introduction of a new =
feature: String arrays can now be converted to other arrays, just like =
Lists can. So registering an editor for an individual InetAddress would =
work now, even if populated with a String array: Each String gets =
converted to an InetAddress, just like each List element would get =
converted when populated with a List.
=20
This code will be included in the upcoming 1.0 RC1.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag von =
j=FCrgen h=F6ller [werk3AT]
Gesendet: Fr 30.01.2004 23:01
An: Les A. Hazlewood
Cc: spr...@li...
Betreff: [Springframework-user] Re [springframework-developer] =
PropertyEditor question



Les,

First of all, my last suggestion really doesn't work: You'd need to have =
a property value of type List to benefit from individual conversion of =
array elements - a String array doesn't work here. Obviously, you cannot =
influence this if binding request parameters, so that's ruled out.

I've just checked that your initial approach of trying to bind to a =
java.util.Set doesn't work either: Your PropertyEditor will just get =
invoked for *String* values, not for *String array* values. To verify =
that, you could try if it works for a *single* InetAddress request =
parameter.

So I'm afraid you have to resort to manual binding code, for example in =
a custom onBindAndValidate implementation: Use a different request =
parameter name, fetch that parameter array from the request there, =
convert it to InetAddress objects, and invoke the corrresponding setter =
on your form object.

Juergen


________________________________

Von: Les A. Hazlewood [mailto:le...@ha...]
Gesendet: Fr 30.01.2004 16:54
An: j=FCrgen h=F6ller [werk3AT]
Cc: col...@ex...
Betreff: Re: [springframework-developer] PropertyEditor question



> Changing the Set to a InetAddress[] and
> registering the custom editor for a single InetAddress.class should
> definitely work.

Juergen, thanks very much for your reply.  However, that didn't work.  I =
have no
idea why, as everything tells me it should work.

I think the problem remains that the binder is never associating my
InetAddressEditor with the InetAddress.class.  Otherwise I wouldn't =
receive the
'Using property editor [null]' message from the BeanWrapperImpl.

Just to be clear, here's my controller method:

protected void initBinder( HttpServletRequest request,
                           ServletRequestDataBinder binder ) {
    //calls superclass which sets other application specific Editors =
common to
    //all forms (i.e. the superclass is a subclass of =
SimpleFormController
    //and it registers a UUID editor since uuid's are common to almost =
all our
    //forms)
    //Note to Jeurgen:  The UUID editor is always bound and functions =
properly.
    super.initBinder(request, binder);

    //register editors for this form in particular:
    binder.registerCustomEditor( InetAddress.class, new =
InetAddressEditor());
}

The InetAddressEditor (subclassing from PropertyEditorSupport) only has =
two
methods defined:  setAsText(String text) and String getAsText();

The jsp code (shows all ip addresses just fine, each in their own input =
box, the
controller just breaks when I submit the form):

<td>
  <spr:bind path=3D"workstation.inetAddressArray">
    <c:forEach var=3D"inetAddress" =
items=3D"${workstation.inetAddressArray}">
      <input name=3D"inetAddressArray" type=3D"text" size=3D"39" =
maxlength=3D"39"
value=3D"<c:out value=3D"${inetAddress.hostAddress}"/>"/><br/>
    </c:forEach>
    <a href=3D"javascript:addIp();">Add IP</a>
    <c:if test=3D"${addIp =3D=3D true}">
      <input name=3D"inetAddressArray" type=3D"text" size=3D"39" =
maxlength=3D"39"/>
    </c:if>
  </spr:bind>
</td>

The debug output when I try to submit my form:

DEBUG [BeanWrapperImpl] Convert: String to [class =
[Ljava.net.InetAddress;]
DEBUG [BeanWrapperImpl] Using property editor [null]
DEBUG [BeanWrapperImpl] About to invoke write method [public void
com.test.computer.SimpleComputerInfo.setInetAddressArray(java.net.InetAdd=
ress[])]
on object of class [com.test.workstation.SimpleWorkstationInfo]
DEBUG [BeanWrapperImpl] About to invoke write method [public void
com.test.computer.SimpleComputerInfo.setName(java.lang.String)] on =
object of
class [com.test.workstation.SimpleWorkstationInfo]
DEBUG [BeanWrapperImpl] Invoked write method [public void
com.test.computer.SimpleComputerInfo.setName(java.lang.String)] with =
value
[Development Workstation]
DEBUG [WorkstationFormController] Data binding errors: 1
DEBUG [SessionFactoryUtils] Opening Hibernate session
DEBUG [HibernateTemplate] Eagerly flushing Hibernate session
DEBUG [SessionFactoryUtils] Closing Hibernate session
DEBUG [SessionFactoryUtils] Opening Hibernate session
DEBUG [HibernateTemplate] Eagerly flushing Hibernate session
DEBUG [SessionFactoryUtils] Closing Hibernate session
DEBUG [SessionFactoryUtils] Opening Hibernate session
DEBUG [HibernateTemplate] Eagerly flushing Hibernate session
DEBUG [SessionFactoryUtils] Closing Hibernate session
DEBUG [DispatcherServlet] Will render view in DispatcherServlet with =
name
'SpringFrontController'
DEBUG [JstlView] Rendering view with name 'workstationFormView' with
model=3D[{facility=3Dcom.test.model.Reference@834e7,
org.springframework.validation.BindException.workstation=3Dorg.springfram=
ework.validation.BindException:
BindException: 1 errors; FieldError occurred in object [workstation] on
[inetAddressArray]: rejectedValue [10.0.0.1];
codes=3D[typeMismatch.workstation.inetAddressArray,typeMismatch.inetAddre=
ssArray,typeMismatch];
args=3D[null]; defaultMessage=3D[Failed to convert property value of =
type
[java.lang.String] to required type [[Ljava.net.InetAddress;] for =
property
named 'inetAddressArray'; nested exception is:
        java.lang.IllegalArgumentException: argument type mismatch],
workstation=3Dcom.test.workstation.SimpleWorkstationInfo@cc0f9f,
controlRooms=3D[com.test.model.Reference@c92ed6],
workstations=3D[com.test.model.Reference@21f46a,
com.test.model.Reference@13598c3]}] and static attributes=3D[{}]


Is this truly a bug, and should I submit it to JIRA?  Does calling
super.initBinder on my superclass break something (even though the =
superclass
is an application specific controller that extends =
SimpleFormController)?  I
couldn't imagine that it would, since all the superclass does is =
register a
UUID Editor and nothing more.  Or am I completely off the map, and the =
error
entirely my own?

Gratefully,

Les




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user

Re: [Springframework-developer] Re: Proxying target classes

[Colin S. <col...@ex...>]

Chris Nokleberg wrote:

>Colin Sampaleanu <colinml1 <at> exis.com> writes:
>
>  
>
>>Unfortunately I need to get this code working and deployed today/tomorrow,
>>    
>>
>
>  
>
>>so adding the interface was the easiest solution. In a day or two I can 
>>    
>>
>
>  
>
>>try to reproduce this in a test case...
>>    
>>
>
>
>
>It's hard for me to test right now but FYI I'm pretty sure this bug is fixed 
>
>in CGLIB CVS.
>
>
>  
>
So you actually think this was a cglib bug? Any reason why the Spring 
unit tests would not have caught this? They should be doing similar 
stuff to my code.

 If I can get half an hour on the weekend then, I may roll back my 
changes to test the CVS version.

RE: [Springframework-developer] Another Spring positive reference.....

[Alastair R. <ala...@ph...>]

AFAIK, with Maven the developer still has to list all the dependencies =
in the POM (Maven's project object model). I think the Maven team have =
plans to improve this so that in effect each library will be distributed =
with a structured description of its dependencies, so that when you want =
to use the lib all of its dependencies are automatically discovered and =
downloaded (and all their dependencies too... etc), and are then also =
included in your app. Sounds great, though I think it's tentatively =
scheduled for the 1.1 release, so it's still some way off.=20


> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of William G. Thompson, Jr.
> Sent: 28 January 2004 16:04
> To: spr...@li...
> Subject: Re: [Springframework-developer] Another Spring=20
> positive reference.....
>=20
>=20
> FYI.  In reference to the dependency manager...it seems like=20
> Maven has=20
> been making good progress.  I recently downloaded Pluto (RI Portlet=20
> Container) and the "maven fullDeployment" command snarfed all the=20
> dependant jars down for me...very nice.
>=20
> Kopylenko, Dmitry wrote:
>=20
> > <quote>
> > Agree - especially with packages like collections and=20
> beanutils being=20
> > so
> > standard, it creates a lot of resistance to pulling down a=20
> project and=20
> > giving it a quick trial run. I appreciate the _Spring approach_=20
> > <http://sourceforge.net/project/showfiles.php?group_id=3D73357> - =
one=20
> > version with all dependencies and one without. At the very=20
> least, it=20
> > would be useful if projects released with a list of URLs=20
> for the JARs=20
> > (either online or in the installation notes).
> >=20
> > Still, it makes me wonder if there's a need for a project like the=20
> > linux
> > dependency managers, which would go and fetch all the jars=20
> you need.=20
> > That would make a sweet Ant task. I haven't seen anything=20
> like that,=20
> > though I recall the perl CPAN module can handle it. The problem is=20
> > there's no protocol for specifying version dependencies in=20
> JAR files.
> >=20
> > </quote>
> >=20
> > from TSS thread:
> > _http://www.theserverside.com/news/thread.jsp?thread_id=3D23544_
> >=20
> > Regards,
> > Dmitriy.
> >=20
>=20
>=20

[Springframework-developer] Re: Proxying target classes

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

Colin Sampaleanu <colinml1 <at> exis.com> writes:

> Unfortunately I need to get this code working and deployed today/tomorrow,

> so adding the interface was the easiest solution. In a day or two I can 

> try to reproduce this in a test case...



It's hard for me to test right now but FYI I'm pretty sure this bug is fixed 

in CGLIB CVS.



Chris

[Springframework-developer] Re: Proxying target classes

[Colin S. <col...@ex...>]

The class is not final, and there are no final methods. And I was wrong, 
it actually already implemented one interface, InitializingBean.

I was definitely wrapping the right object, as afterwards I added a new 
service interface to the object, took out the proxyTargetClass property, 
and everything is now working fine. Unfortunately I need to get this 
code working and deployed today/tomorrow, so adding the interface was 
the easiest solution. In a day or two I can try to reproduce this in a 
test case...


Rod Johnson wrote:

>I saw this once only and it was my fault (accidentally wrapped a String as
>the target, rather than real object).
>
>Are any of the methods, or the object itself, final?
>
>Can you reproduce this in a failing test case so I can look at it? There
>certainly should be a better error message, even if it's a CGLIB prob.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>;
><rod...@in...>
>Sent: Wednesday, January 28, 2004 1:20 PM
>Subject: Proxying target classes
>
>
>  
>
>>Rod,
>>
>>Have you ever seen cglib's EnhancerEmitter blow up on trying to create a
>>proxy? I generally only have to proxy interfaces, so have not proxied
>>classes too much so far, however I just had a case where I needed to
>>proxy a class directly, and got the following exception:
>>
>> method 'onMessage' due to throwable
>>[org.springframework.beans.factory.BeanCrea
>>tionException: Error creating bean with name 'packaging-engine' defined
>>in class
>>path resource [packaging-applicationContext.xml]: Initialization method
>>of bean
>>failed; nested exception is:
>>        org.springframework.aop.framework.AopConfigException: Unexpected
>>AOP exc
>>eption; nested exception is:
>>        java.lang.NullPointerException]
>>08:07:48,585 INFO  [JtaTransactionManager] Initiating transaction rollback
>>08:07:48,585 ERROR [LogInterceptor] RuntimeException:
>>org.springframework.beans.factory.BeanCreationException: Error creating
>>bean wit
>>h name 'packaging-engine' defined in classpath resource
>>[packaging-applicationCo
>>ntext.xml]: Initialization method of bean failed; nested exception is:
>>        org.springframework.aop.framework.AopConfigException: Unexpected
>>AOP exc
>>eption; nested exception is:
>>        java.lang.NullPointerException
>>org.springframework.aop.framework.AopConfigException: Unexpected AOP
>>exception;
>>nested exception is:
>>        java.lang.NullPointerException
>>java.lang.NullPointerException
>>        at
>>net.sf.cglib.proxy.EnhancerEmitter$4.getMethods(EnhancerEmitter.java:
>>407)
>>        at
>>    
>>
>net.sf.cglib.proxy.NoOpGenerator.generate(NoOpGenerator.java:69)
>  
>
>>        at
>>net.sf.cglib.proxy.EnhancerEmitter.emitMethods(EnhancerEmitter.java:4
>>31)
>>        at
>>net.sf.cglib.proxy.EnhancerEmitter.<init>(EnhancerEmitter.java:172)
>>
>>This is using BeanNameAutoProxyCreator, with proxyTargetClass set to
>>true. I actually used another postprocessor just for this case, since
>>normally I only care about interfaces, so there's nothing else in it:
>>
>>  <bean id="packaging-txAutoProxyCreator2"
>>
>>    
>>
>class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"
>  
>
>>    <property name="proxyTargetClass"><value>true</value></property>
>>    <property name="interceptorNames">
>>      <list>
>>        <idref bean="hibInterceptor"/>
>>        <idref local="packaging-matchAllTxInterceptor"/>
>>      </list>
>>    </property>
>>    <property name="beanNames">
>>      <list>
>>           <idref local="packaging-engine"/>
>>      </list>
>>    </property>
>>  </bean>
>>
>>The class in question (Engine) is a fairly simple class. It implements
>>no interfaces.
>>
>>Regards,
>>Colin
>>
>>
>>    
>>
>
>  
>

[Springframework-developer] Re: Proxying target classes

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

I saw this once only and it was my fault (accidentally wrapped a String as
the target, rather than real object).

Are any of the methods, or the object itself, final?

Can you reproduce this in a failing test case so I can look at it? There
certainly should be a better error message, even if it's a CGLIB prob.

Regards,
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>;
<rod...@in...>
Sent: Wednesday, January 28, 2004 1:20 PM
Subject: Proxying target classes


> Rod,
>
> Have you ever seen cglib's EnhancerEmitter blow up on trying to create a
> proxy? I generally only have to proxy interfaces, so have not proxied
> classes too much so far, however I just had a case where I needed to
> proxy a class directly, and got the following exception:
>
>  method 'onMessage' due to throwable
> [org.springframework.beans.factory.BeanCrea
> tionException: Error creating bean with name 'packaging-engine' defined
> in class
> path resource [packaging-applicationContext.xml]: Initialization method
> of bean
> failed; nested exception is:
>         org.springframework.aop.framework.AopConfigException: Unexpected
> AOP exc
> eption; nested exception is:
>         java.lang.NullPointerException]
> 08:07:48,585 INFO  [JtaTransactionManager] Initiating transaction rollback
> 08:07:48,585 ERROR [LogInterceptor] RuntimeException:
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean wit
> h name 'packaging-engine' defined in classpath resource
> [packaging-applicationCo
> ntext.xml]: Initialization method of bean failed; nested exception is:
>         org.springframework.aop.framework.AopConfigException: Unexpected
> AOP exc
> eption; nested exception is:
>         java.lang.NullPointerException
> org.springframework.aop.framework.AopConfigException: Unexpected AOP
> exception;
> nested exception is:
>         java.lang.NullPointerException
> java.lang.NullPointerException
>         at
> net.sf.cglib.proxy.EnhancerEmitter$4.getMethods(EnhancerEmitter.java:
> 407)
>         at
net.sf.cglib.proxy.NoOpGenerator.generate(NoOpGenerator.java:69)
>         at
> net.sf.cglib.proxy.EnhancerEmitter.emitMethods(EnhancerEmitter.java:4
> 31)
>         at
> net.sf.cglib.proxy.EnhancerEmitter.<init>(EnhancerEmitter.java:172)
>
> This is using BeanNameAutoProxyCreator, with proxyTargetClass set to
> true. I actually used another postprocessor just for this case, since
> normally I only care about interfaces, so there's nothing else in it:
>
>   <bean id="packaging-txAutoProxyCreator2"
>
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"
>
>     <property name="proxyTargetClass"><value>true</value></property>
>     <property name="interceptorNames">
>       <list>
>         <idref bean="hibInterceptor"/>
>         <idref local="packaging-matchAllTxInterceptor"/>
>       </list>
>     </property>
>     <property name="beanNames">
>       <list>
>            <idref local="packaging-engine"/>
>       </list>
>     </property>
>   </bean>
>
> The class in question (Engine) is a fairly simple class. It implements
> no interfaces.
>
> Regards,
> Colin
>
>

Re: [Springframework-developer] Reworked transaction infrastructure

[Colin S. <col...@ex...>]

I've been using the new code for a few days with generaly no issues.=20
I've come upon a problem now which may or may not have been there=20
before; it's hard for me to tell, and I can't roll back to the previous=20
spring version since I need some of the new features elsewhere.

The use case is fairly complex. There is a hierarchical appcontext=20
(although that is irrelevant), with a number of service beans in there=20
wrapped transactionally with an interceptor using JTATransactionManager=20
and with the Hibernate interceptor, via BeanNameAutoProxyCreator. There=20
is also usage of CMT Session Beans, which get called from Spring=20
objects, and call to Spring objects. So I have a problem with the=20
following sequence:

- JMS call to MessageDrivenBean, DispatcherBean
- DispatcherBean gets real POJO service object,=20
PackagingMessageHandlerImpl, from a context it locates, and delegates to=20
it. PackagingMessageHandlerImpl is transactionally wrapped by the context=
.
- PackagingMessageHandlerImpl calls out to ApplicationController, a=20
Session Bean (with CMT)
- ApplicationController gets real POJO service object from context,=20
ApplicationControllerServiceImpl, and delegates to it.
- ApplicationControllerServiceImpl does some work using some=20
Hibernate-based Mappers/DAOs.
- ApplicationControllerServiceImpl returns
- transaction manager calls commit, but no commit actually done since=20
not a new transaction, return continues
- ApplicationController (sessionBean) returns

then I get the following blowup, where JBoss is pretty confused. Looks=20
like an unknown connection is attempted to be closed, and the real one=20
isn't (as per the subsequent error about closing connections yourself).=20
Hard to tell who is at fault here. I will try to dig into this deeper=20
myself, but if you have any ideas they would be much appreciated:

2004-01-28 10:54:38,934 DEBUG=20
[org.springframework.transaction.interceptor.TransactionInterceptor]=20
Invoking commit for transaction on method 'uploadDistribution'
2004-01-28 10:54:38,934 DEBUG=20
[org.springframework.orm.hibernate.HibernateInterceptor] Not closing=20
pre-bound Hibernate session after interceptor
2004-01-28 10:54:38,934 INFO =20
[org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEve=
ntListener]=20
throwable from unregister connection
java.lang.IllegalStateException: Trying to return an unknown=20
connection2! org.jboss.resource.adapter.jdbc.WrappedConnection@5cd34e
    at=20
org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterCo=
nnection(CachedConnectionManager.java:275)
    at=20
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEven=
tListener.connectionClosed(TxConnectionManager.java:550)
    at=20
org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(=
BaseWrapperManagedConnection.java:287)
    at=20
org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection=
.java:127)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at=20
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at=20
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(Cac=
hedConnectionManager.java:375)
    at=20
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAware=
Object(CachedConnectionManager.java:199)
    at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:190)
    at=20
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Stateles=
sSessionInstanceInterceptor.java:72)
    at=20
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
    at=20
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:267)
    at=20
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
    at=20
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java=
:118)
    at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:19=
1)
    at=20
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
    at=20
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionCo=
ntainer.java:331)
    at org.jboss.ejb.Container.invoke(Container.java:700)
    at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
    at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at=20
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDis=
patcher.java:284)
    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:54=
6)
    at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:1=
01)
    at=20
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90=
)
    at=20
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java=
:46)
    at=20
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45)
    at=20
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionIn=
terceptor.java:100)
    at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
    at $Proxy99.uploadDistribution(Unknown Source)
    at=20
com.whatever.coreserv.services.messaging.PackagingMessageHandlerImpl.onMe=
ssage(PackagingMessageHandlerImpl.java:156)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at=20
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at=20
org.springframework.aop.framework.AopProxyUtils.invokeJoinpointUsingRefle=
ction(AopProxyUtils.java:59)
    at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpo=
int(ReflectiveMethodInvocation.java:201)
    at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:176)
    at=20
org.springframework.transaction.interceptor.TransactionInterceptor.invoke=
(TransactionInterceptor.java:156)
    at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
    at=20
org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateIn=
terceptor.java:84)
    at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
    at=20
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAop=
Proxy.java:135)
    at $Proxy114.onMessage(Unknown Source)
    at=20
com.whatever.coreserv.services.messaging.DispatcherBean.onMessage(Dispatc=
herBean.java:96)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at=20
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at=20
org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageD=
rivenContainer.java:460)
    at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:186)
    at=20
org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDriv=
enInstanceInterceptor.java:62)
    at=20
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
    at=20
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:240)
    at=20
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
    at=20
org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterc=
eptor.java:90)
    at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:19=
1)
    at=20
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
    at=20
org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContaine=
r.java:374)
    at org.jboss.ejb.Container.invoke(Container.java:700)
    at=20
org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.=
java:827)
    at=20
org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessa=
ge(JMSContainerInvoker.java:1117)
    at=20
org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:256)
    at=20
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageC=
onsumer.java:633)
    at=20
org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:433)
    at org.jboss.mq.SpySession.run(SpySession.java:298)
    at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:180)
    at=20
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor=
.java:727)
    at java.lang.Thread.run(Thread.java:534)
2004-01-28 10:54:39,167 INFO =20
[org.jboss.resource.connectionmanager.CachedConnectionManager]=20
Successfully closed a connection for you.  Please close them yourself:=20
org.jboss.resource.adapter.jdbc.WrappedConnection@5cd34e
java.lang.Exception: Stack Trace
    at=20
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(Cac=
hedConnectionManager.java:376)
    at=20
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAware=
Object(CachedConnectionManager.java:199)
    at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:190)
    at=20
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Stateles=
sSessionInstanceInterceptor.java:72)
    at=20
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
    at=20
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:267)
    at=20
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
    at=20
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java=
:118)
    at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:19=
1)
    at=20
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
    at=20
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionCo=
ntainer.java:331)
    at org.jboss.ejb.Container.invoke(Container.java:700)
    at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
    at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at=20
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDis=
patcher.java:284)
    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:54=
6)
    at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:1=
01)
    at=20
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90=
)
    at=20
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java=
:46)
    at=20
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45)
    at=20
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionIn=
terceptor.java:100)
    at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
    at $Proxy99.uploadDistribution(Unknown Source)
    at=20
com.whatever.coreserv.services.messaging.PackagingMessageHandlerImpl.onMe=
ssage(PackagingMessageHandlerImpl.java:156)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at=20
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at=20
org.springframework.aop.framework.AopProxyUtils.invokeJoinpointUsingRefle=
ction(AopProxyUtils.java:59)
    at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpo=
int(ReflectiveMethodInvocation.java:201)
    at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:176)
    at=20
org.springframework.transaction.interceptor.TransactionInterceptor.invoke=
(TransactionInterceptor.java:156)
    at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
    at=20
org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateIn=
terceptor.java:84)
    at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
    at=20
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAop=
Proxy.java:135)
    at $Proxy114.onMessage(Unknown Source)
    at=20
com.whatever.coreserv.services.messaging.DispatcherBean.onMessage(Dispatc=
herBean.java:96)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at=20
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
    at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at=20
org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageD=
rivenContainer.java:460)
    at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:186)
    at=20
org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDriv=
enInstanceInterceptor.java:62)
    at=20
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
    at=20
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:240)
    at=20
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
    at=20
org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterc=
eptor.java:90)
    at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:19=
1)
    at=20
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
    at=20
org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContaine=
r.java:374)
    at org.jboss.ejb.Container.invoke(Container.java:700)
    at=20
org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.=
java:827)
    at=20
org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessa=
ge(JMSContainerInvoker.java:1117)
    at=20
org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:256)
    at=20
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageC=
onsumer.java:633)
    at=20
org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:433)
    at org.jboss.mq.SpySession.run(SpySession.java:298)
    at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:180)
    at=20
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor=
.java:727)
    at java.lang.Thread.run(Thread.java:534)








j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>=20
>I've significantly reworked our transaction infrastructure last week, to=
 effectively provide the same support for transaction suspension as EJB C=
MT does.  Accordingly, I've introduced propagation behaviors "REQUIRES_NE=
W", "NOT_SUPPORTED", and "NEVER" for all our PlatformTransactionManagers.=
 I've committed this yesterday evening, now that CVS seems to work again.
>
>JtaTransactionManager needs to access the javax.transaction.TransactionM=
anager for transaction suspension; unfortunately, the TransactionManager =
location is not defined by J2EE (O/R mappers have a similar problem for c=
ache callbacks in a JTA environment). Thus, I've introduced a JtaDialect =
interface (analogous to our JdoDialect), containing "getInternalTransacti=
onManager" and "applyIsolationLevel" methods (the latter factored out fro=
m JtaTransactionManager's template method into this strategy).
>
>The default dialect implementations is JndiLookupJtaDialect, with a conf=
igurable "templateManagerName" JNDI location (not doing anything about th=
e isolation level); its Javadoc states a couple of well-known JTA Transac=
tionManager locations in popular application servers. Additionally, I've =
added JotmJtaDialect and WebSphereJtaDialect, which both require specific=
 static accessor methods to obtain the JTA TransactionManager. I've simpl=
y taken the corresponding code from Hibernate's TransactionManagerLookups=
.
>
>There's also a new "jtaDialect" property in LocalSessionFactoryBean, all=
owing to use a Spring-configured JtaDialect for Hibernate's TransactionMa=
nagerLookup. This avoids double configuration of the server-specific look=
up strategy. As when providing a DataSource, the corresponding Hibernate =
property will be set implictly when a JtaDialect is provided.=20
>=20
>I've tested transaction suspension with HibernateTransactionManager and =
DataSourceTransactionManager in Tomcat, Resin, and JBoss; with JtaTransac=
tionManager and a corresponding JndiLookupJtaDialect, in Resin and JBoss.=
 Works nicely in all cases: I'd be happy if someone else tried WebLogic, =
WebSphere, JOTM, etc (there's nothing to worry about there, just validati=
ng the TransactionManager lookup strategies).
>=20
>I've also added a ClobStringType for Hibernate, using a LocalSessionFact=
oryBean-specified LobHandler for mapping Strings to CLOBs. You can specif=
y ClobStringType for such fields in your Hibernate mappings even if just =
using CLOBs in certain environments: DefaultLobHandler will simply delega=
te to PreparedStatement.setString/ResultSet.getString anyway. On Oracle, =
simply configure OracleLobHandler in your application context - the Hiber=
nate mapping file does not have to change.
>=20
>ClobStringType is particularly useful if you need Strings with more than=
 4000 characters in Oracle mapped to persistent objects via Hibernate. Yo=
u need to use CLOBs for such long texts in Oracle; and due to Oracle's pe=
culiar handling of LOBs, you need a special strategy like OracleLobHandle=
r. On other databases like MySQL, type "longtext" is fine, to be used lik=
e normal String values. Our LobHandler abstraction allows to turn this in=
to a configuration issue.
>=20
>If you get the chance, please check this out promptly, as we intend to r=
elease 1.0 RC1 this weekend!
>=20
>Juergen
>=20
>

Re: [Springframework-developer] Another Spring positive reference.....

[William G. T. Jr. <wg...@ru...>]

FYI.  In reference to the dependency manager...it seems like Maven has 
been making good progress.  I recently downloaded Pluto (RI Portlet 
Container) and the "maven fullDeployment" command snarfed all the 
dependant jars down for me...very nice.

Kopylenko, Dmitry wrote:

> <quote>
> Agree - especially with packages like collections and beanutils being so 
> standard, it creates a lot of resistance to pulling down a project and 
> giving it a quick trial run. I appreciate the _Spring approach_ 
> <http://sourceforge.net/project/showfiles.php?group_id=73357> - one 
> version with all dependencies and one without. At the very least, it 
> would be useful if projects released with a list of URLs for the JARs 
> (either online or in the installation notes).
> 
> Still, it makes me wonder if there's a need for a project like the linux 
> dependency managers, which would go and fetch all the jars you need. 
> That would make a sweet Ant task. I haven't seen anything like that, 
> though I recall the perl CPAN module can handle it. The problem is 
> there's no protocol for specifying version dependencies in JAR files.
> 
> </quote>
> 
> from TSS thread: 
> _http://www.theserverside.com/news/thread.jsp?thread_id=23544_
> 
> Regards,
> Dmitriy.
> 

[Springframework-developer] Another Spring positive reference.....

[Kopylenko, D. <dko...@ac...>]

<quote>
Agree - especially with packages like collections and beanutils being so
standard, it creates a lot of resistance to pulling down a project and
giving it a quick trial run. I appreciate the Spring approach
<http://sourceforge.net/project/showfiles.php?group_id=73357>  - one version
with all dependencies and one without. At the very least, it would be useful
if projects released with a list of URLs for the JARs (either online or in
the installation notes). 

Still, it makes me wonder if there's a need for a project like the linux
dependency managers, which would go and fetch all the jars you need. That
would make a sweet Ant task. I haven't seen anything like that, though I
recall the perl CPAN module can handle it. The problem is there's no
protocol for specifying version dependencies in JAR files. 
</quote>

from TSS thread:
http://www.theserverside.com/news/thread.jsp?thread_id=23544
<http://www.theserverside.com/news/thread.jsp?thread_id=23544> 

Regards,
Dmitriy.

[Springframework-developer] Proxying target classes

[Colin S. <col...@ex...>]

Rod,

Have you ever seen cglib's EnhancerEmitter blow up on trying to create a 
proxy? I generally only have to proxy interfaces, so have not proxied 
classes too much so far, however I just had a case where I needed to 
proxy a class directly, and got the following exception:

 method 'onMessage' due to throwable 
[org.springframework.beans.factory.BeanCrea
tionException: Error creating bean with name 'packaging-engine' defined 
in class
path resource [packaging-applicationContext.xml]: Initialization method 
of bean
failed; nested exception is:
        org.springframework.aop.framework.AopConfigException: Unexpected 
AOP exc
eption; nested exception is:
        java.lang.NullPointerException]
08:07:48,585 INFO  [JtaTransactionManager] Initiating transaction rollback
08:07:48,585 ERROR [LogInterceptor] RuntimeException:
org.springframework.beans.factory.BeanCreationException: Error creating 
bean wit
h name 'packaging-engine' defined in classpath resource 
[packaging-applicationCo
ntext.xml]: Initialization method of bean failed; nested exception is:
        org.springframework.aop.framework.AopConfigException: Unexpected 
AOP exc
eption; nested exception is:
        java.lang.NullPointerException
org.springframework.aop.framework.AopConfigException: Unexpected AOP 
exception;
nested exception is:
        java.lang.NullPointerException
java.lang.NullPointerException
        at 
net.sf.cglib.proxy.EnhancerEmitter$4.getMethods(EnhancerEmitter.java:
407)
        at net.sf.cglib.proxy.NoOpGenerator.generate(NoOpGenerator.java:69)
        at 
net.sf.cglib.proxy.EnhancerEmitter.emitMethods(EnhancerEmitter.java:4
31)
        at 
net.sf.cglib.proxy.EnhancerEmitter.<init>(EnhancerEmitter.java:172)

This is using BeanNameAutoProxyCreator, with proxyTargetClass set to 
true. I actually used another postprocessor just for this case, since 
normally I only care about interfaces, so there's nothing else in it:

  <bean id="packaging-txAutoProxyCreator2" 
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
    <property name="proxyTargetClass"><value>true</value></property>
    <property name="interceptorNames">
      <list>
        <idref bean="hibInterceptor"/>
        <idref local="packaging-matchAllTxInterceptor"/>
      </list>
    </property>
    <property name="beanNames">
      <list>
           <idref local="packaging-engine"/>
      </list>
    </property>
  </bean>

The class in question (Engine) is a fairly simple class. It implements 
no interfaces.

Regards,
Colin

Re: [Springframework-developer] test email

[Darren D. <dda...@kg...>]

> I see most emails are flowing, but, but an email from me yesterday 
> morning has not shown up, nor one from last night...

they're still clearing a backlog I think.  I'm subscribed to this list from 2
addresses at present and receive the same mails at varying times - in a few
cases days apart!


--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] CVS access

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

Still can't commit, although CVS seems up to date. Don't know where my AO=
P
commit is at...have to try again later :-(

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, January 23, 2004 2:51 PM
Subject: Re: [Springframework-developer] CVS access


Just submitted a corresponding support request to SourceForge.


________________________________

Von: spr...@li... im Auftrag von
Colin Sampaleanu
Gesendet: Fr 23.01.2004 14:26
An: spr...@li...
Betreff: Re: [Springframework-developer] CVS access



According to that status item, they are going to prioritize (manually
synch) projects that specifically ask for it, so we should put in a
Support Request explicitly.

 >> The SourceForge.net team is working to resolve outstanding problems
from the hardware cutover of the developer CVS server. A number of
project repositories are not yet present on the new developer CVS server
or currently contain outdated data. This may result in messages about
files or file versions in your working copy not being present in the
repository. We have initiated a contingency plan to resynchronize
missing/outdated data; we expect this sync to run through the day Friday
and complete during the weekend. We regret the inconvenience this may
cause you and your project team. At this time, we are accepting Support
Request reports of outdated repositories and are syncing reported issue
repositories by hand as to provide faster turnaround. During the time
frame of this large resync, performance of developer CVS will be
degraded. Due to the increased system load of the resync period, end of
file (EOF) errors and SSH ssh_exchange_identification errors upon
connect may be encountered; retrying your operation should work.
Additional status updates will be posted as this matter is resolved.
Your patience is appreciated.




j=FCrgen h=F6ller [werk3AT] wrote:

>As I've mentioned in the previous mail, SourceForge expect the syncing w=
ith
the new CVS server to finish during the weekend. So it seems that we won'=
t
be able to commit our changes before Monday. If they manage to get
everything up and running again then, this should be good enough: Releasi=
ng
RC1 by the end of next week is acceptable, from my point of view.
>
>BTW, we're at 3500 downloads for M4 in the first two weeks after its
release! More than any previous release had in six weeks...
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n
Rod Johnson
>Gesendet: Fr 23.01.2004 11:02
>An: spr...@li...
>Betreff: Re: [Springframework-developer] CVS access
>
>
>
>It's very sick. I can't commit some changes I made offline yesterday. I'=
m
>seeing really ancient stuff when I compare.
>
>At least I have clean, up-to-date sources (with my own recent changes of
>course). But Juergen still has the new tx mgt stuff to go in.
>
>If it doesn't come back this morning, it's likely to delay RC1.
>
>I bloody well hope they haven't really screwed our repository. I just
>downloaded the CVS backup archive, but haven't looked at it yet.
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Thursday, January 22, 2004 9:57 PM
>Subject: Re: [Springframework-developer] CVS access
>
>
>
>
>>Something is seriously f*cked on SF. I am halfway in the middle of doin=
g
>>an update, and it is busy pulling down stuff that is months old, and
>>knows nothing about some of the newer dirs. I didn't specify any old
>>branch or rev, or any kind of date, so either my system or sf is quite
>>confused.
>>
>>I will try wiping out my local copy and doing a fresh checkout...
>>
>>
>>tri...@tr... wrote:
>>
>>
>>
>>>Still no luck.
>>>
>>>Reminds me of this comment by Brian McCallister the other day
>>>http://kasparov.skife.org/blog/2004/01/18#self-hosting :-)
>>>
>>>Thomas
>>>
>>>Quoting Colin Sampaleanu <col...@ex...>:
>>>
>>>
>>>
>>>
>>>
>>>>Fails for me too:
>>>>cvs update: warning: unrecognized response `Remote process exit code
>>>>unavailable
>>>>' from cvs server
>>>>cvs [update aborted]: end of file from server (consult above messages=
 if
>>>>any)
>>>>
>>>>
>>>>
>>>>Kopylenko, Dmitry wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Can anyone access CVS via extssh right now? I'm having problems
>>>>>reaching sourceforge CVS.
>>>>>
>>>>>Dmitriy.
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>-------------------------------------------------------
>>The SF.Net email is sponsored by EclipseCon 2004
>>Premiere Conference on Open Tools Development and Integration
>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>http://www.eclipsecon.org/osdn
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] BeanFactoryLocator iinterface and some implementations checked in

[Colin S. <col...@ex...>]

(resent, the initial email from last night seems to have gone into a 
black hole; probably it will show up in a day or two).

I've checked in a new interface called BeanFactoryLocator. It replaces 
the existing BeanFactoryLoader interface, with the old concrete 
implementations XmlBeanFactoryLoader and 
XmlBeanFactoryApplicationContextLoader now implementing 
BeanFactoryLocator, and renamed to SimpleJndiBeanFactoryLocator and 
JndiBeanFactoryLocator, respectively. The latter is the default used by 
the EJB support classes.

As well, there are two new classes implementing BeanFactoryLocator, 
called SingletonBeanFactoryLocator and DefaultBeanFactoryLocator. These 
implement a 'keyed-singleton' bean factory access mechanism. The latter 
class simply uses an ApplicationContext internally instead of the 
former's BeanFactory. Essentialy, the classes use a
BeanFactory or ApplicationContext definition (which becomes a singleton, 
keyed by the name of the definition file(s)) to load one or more 
BeanFactories or ApplicationContexts, and return them to the caller.

I am by no means a big fan of using singleton's, but they have some uses 
in glue code some times. As such, I have heavily plastered the JavaDocs 
with warnings not to use these classes in most circumstances.

Given that we are so close to RC1, if somebody doesn't like any of the 
class names, method names, packages, implementation, etc., please speak 
up. Also, these changes break compatibility with any old code overriding 
the default BeanFactoryLoader in the ejb support classes. I thought it 
was worth it to do this in order to consolidate two fairly similar 
interfaces. Changing to use the new code should be fairly trivial for 
anybody affected.

Regards,
Colin

[Springframework-developer] test email

[Colin S. <col...@ex...>]

I see most emails are flowing, but, but an email from me yesterday 
morning has not shown up, nor one from last night...