springframework-developer — Spring Framework developers list

[Springframework-developer] Difficulty using LocalSessionFactoryBean schemaUpdate with Oracle9 Sequences

[Jason W. S. <jso...@sb...>]

I recently switched from using Hibernate's schemaupdate ant task to =
using
the schemaUpdate property of
org.springframework.orm.hibernate.LocalSessionFactoryBean.

When I attempt to update an already existing schema it fails with the
message:

java.sql.SQLException: ORA-00955: name is already used by an existing =
object
(see below for complete stack trace).

It turns out that Hibernate's schemaUpdate implementation always =
requests
that Oracle create a new sequence, even if that sequence already exists =
in
the database. When I used the schemaupdate task, this did not result in =
any
error messages. The sequence create statement silently failed. My old =
EJB
build scripts worked the same way, asking the database to create a =
sequence
for each CMP bean each time I deployed, and then silently failing for
sequences that already exist. I gather from talking to Oracle people =
that
this is considered to be the "proper" way to do things in the Oracle =
world
(i.e. create everything, and silently fail for anything that already
exists).

When I set the schemaUpdate property on LocalSessionFactoryBean, this =
same
behavior results in an exception that prevents application deployment. =
While
I agree with the philosophy of failing loudly, in this case it is
problematic for me.

Would it be excessively evil if I caught the exceptions inside of the
callback inside of LocalSessionFactoryBean.executeSchemaUpdate without
taking any corrective action?

If not, is it possible that a flag could be added to the standard
implementation of LocalSessionFactoryBean to cause failed statements =
during
schemaUpdate to be ignored? I imagine that using Oracle9 and using =
sequences
to generate primary keys in Hibernate (seqhilo) is not an uncommon use =
case.

I am inclined to implement a subclass of LocalSessionFactoryBean that =
has
this behavior, but I am concerned that continuing to use a Hibernate
session, even after a trivial failure during schemaUpdate, might have
unintended consequences.

Thanks,

Jason W. Solinsky


Here is my stack trace:

java.sql.SQLException: ORA-00955: name is already used by an existing =
object

	at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
	at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
	at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573)
	at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1891)
	at
oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:1093)
	at
oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2=
047
)
	at
oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:19=
40)
	at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.j=
ava
:2709)
	at
oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:796=
)
	at
org.apache.commons.dbcp.DelegatingStatement.executeUpdate(DelegatingState=
men
t.java:196)
	at
org.springframework.orm.hibernate.LocalSessionFactoryBean$1.doInHibernate=
(Lo
calSessionFactoryBean.java:321)
	at
org.springframework.orm.hibernate.HibernateTemplate.execute(HibernateTemp=
lat
e.java:147)
	at
org.springframework.orm.hibernate.LocalSessionFactoryBean.executeSchemaUp=
dat
e(LocalSessionFactoryBean.java:311)
	at
org.springframework.orm.hibernate.LocalSessionFactoryBean.afterProperties=
Set
(LocalSessionFactoryBean.java:249)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.callLifecyc=
leM
ethodsIfNecessary(AbstractBeanFactory.java:1026)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
Abs
tractBeanFactory.java:548)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tra
ctBeanFactory.java:188)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveRefe=
ren
ce(AbstractBeanFactory.java:980)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValu=
eIf
Necessary(AbstractBeanFactory.java:952)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.applyProper=
tyV
alues(AbstractBeanFactory.java:909)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.populateBea=
n(A
bstractBeanFactory.java:743)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
Abs
tractBeanFactory.java:547)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tra
ctBeanFactory.java:188)
	at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preI=
nst
antiateSingletons(DefaultListableBeanFactory.java:211)
	at
org.springframework.context.support.AbstractApplicationContext.refresh(Ab=
str
actApplicationContext.java:280)
	at
org.springframework.web.context.support.XmlWebApplicationContext.refresh(=
Xml
WebApplicationContext.java:107)
	at
org.springframework.web.context.ContextLoader.createWebApplicationContext=
(Co
ntextLoader.java:131)
	at
org.springframework.web.context.ContextLoader.initWebApplicationContext(C=
ont
extLoader.java:81)
	at
org.springframework.web.context.ContextLoaderListener.contextInitialized(=
Con
textLoaderListener.java:32)
	at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.ja=
va:
3775)
	at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4257)=

	at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.jav=
a:8
66)
	at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:850)
	at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
	at
org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeploy=
er.
java:832)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at
org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:25=
2)
	at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:256)
	at org.apache.commons.digester.Rule.end(Rule.java:276)
	at
org.apache.commons.digester.Digester.endElement(Digester.java:1058)
	at
org.apache.catalina.util.CatalinaDigester.endElement(CatalinaDigester.jav=
a:1
23)
	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unkn=
own
Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDisp=
atc
her.dispatch(Unknown Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknow=
n
Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
	at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.commons.digester.Digester.parse(Digester.java:1567)
	at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeploye=
r.j
ava:512)
	at
org.apache.catalina.core.StandardHost.install(StandardHost.java:890)
	at
org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:856=
)
	at
org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:699=
)
	at
org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:447)=

	at javax.servlet.http.HttpServlet.service(HttpServlet.java:766)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicat=
ion
FilterChain.java:284)
	at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilte=
rCh
ain.java:204)
	at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve=
.ja
va:256)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCon=
tex
t.java:151)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:56=
4)
	at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardCont=
ext
Valve.java:245)
	at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve=
.ja
va:199)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCon=
tex
t.java:151)
	at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorB=
ase
.java:594)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCon=
tex
t.java:149)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:56=
4)
	at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:=
195
)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCon=
tex
t.java:151)
	at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:=
164
)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCon=
tex
t.java:149)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:56=
4)
	at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.j=
ava
:156)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCon=
tex
t.java:151)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:56=
4)
	at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
	at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:211)
	at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:805=
)
	at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processCo=
nne
ction(Http11Protocol.java:696)
	at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:605=
)
	at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.=
jav
a:677)
	at java.lang.Thread.run(Unknown Source)

Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes

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

As per the thread below from about a week ago, I have defaulted 
AbstractEnterpriseBean and its subclasses to use a new 
XmlApplicationContextBeanFactoryLoader, which will load and create an 
ApplicationContext from the classpath. For a lighter weight solution 
when ApplicationContexts are not needed, people may still switch in the 
old XmlBeanFactoryLoader.

One comment though, is that if you look at a common usage scenario, 
which is to call out from Session ejbs to service POJOs using 
Hibernate-based DAO/Mapper objects, this solution is still not good 
enough, in that every EJB ends up creating an application context, which 
ends up creating a new session factory for every EJB. For this reason, I 
still drop in a custom BeanFactoryLoader which loads/accesses a shared 
ApplicationContext via the KeyedSingletonContextLocator I posted here a 
while ago.

Regards,
Colin


Colin Sampaleanu wrote:

> Peter den Haan wrote:
>
>> Colin Sampaleanu wrote:
>>
>>> eanPostProcessors are a function of ApplicationContexts, so it is
>>> normal that BeanFactories which are not also ApplicationContexts (such
>>> as that produced by XMLBeanFactoryLoader) do no post-processing.
>>>   
>>
>> Ah, but that's the funny thing. This is not entirely true. The actual
>> postprocessing plumbing is part and parcel of the 
>> DefaultListableBeanFactory
>> itself. However, it does not auto-register any postprocessors itself. 
>> That
>> is done by the application context. Given the important place 
>> postprocessing
>> has been gaining in the Spring infrastructure, it seems odd that EJBs 
>> do get
>> a BeanFactory that does in fact have all it takes (you do not need a 
>> full
>> context) but is still very limited because its postprocessing 
>> plumbing isn't
>> initialised.
>>
>> Users new to the product would expect Spring to provide some 
>> out-of-the-box
>> support for a fully functional bean container in the EJB tier, 
>> probably by
>> default. As things stand, you won't be getting this without coding 
>> (and a
>> nontrivial understanding of Spring subtleties).
>>  
>>
> The fact that DefaultListableBeanFactory has some of the support code 
> is somewhat irrelevant. The contract is that if something has the 
> ApplicationContext interface it supports BeanPostProcessors, and if it 
> doesn't (i.e. it is simply a BeanFactory), it doesn't support 
> BeanPostProcessors. And this is how the current code behaves. As I 
> said, I agree that the distinction between application contexts and 
> bean factories needs to be better documented, and it probably makes 
> sense for the default BeanFactoryLoader in the base EJB classes to 
> produce an ApplicationContext variant instead of just a regular 
> BeanFactory. That code actually got into Spring before I got to the 
> project, so I'm not sure why it was decided one way vs. another. If 
> there is no opposition, I am quite willing to make that change...
>
> Regards,
> Colin
>

[Springframework-developer] We should probably version the dtd

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

When I was adding the beanid tag earlier today, I was thinking that it 
probably made sense to put a version number on the dtd document, unless 
we think it's going to stay completely static from now on...

[Springframework-developer] AbstractJndiLocator time of JNDI lookup

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

Currently AbstractJndiLocator does the JNDI lookup right after 
initialization, basically triggered by afterPropertiesSet.

Somebody in the SF forum is having an issue when loading a J2EE ear in 
weblogic, in that the webapp is loaded by WL before the EJBs. Since the 
webapp triggers loading the context, and the EJB invoker interceptors 
(derived from AbstractJndiLocator) are singletons and are created at 
that time, they do the JNDI lookups for the ejb homes at that time, and 
don't see anything because the EJBs are not there yet.

What would probably work is to have the option of lazily doing the JNDI 
lookup. It would stay non-lazy by default, but subclasses, like the ejb 
invokers, would be lazy by default.

[Springframework-developer] xml dtd addition for bean id reference

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

I've checked in code which supports a new beanid element in the xml 
beanfactory/context definition, as follows:

<!--
    Defines a string property value, which must also be the id of another
    bean in this factory or an external factory (parent or included 
factory).
    While a regular 'value' element could instead be used for the same 
effect,
    using beanid in this case allows validation of local bean ids by the xml
    parser, and name completion by helper tools.
-->
<!ELEMENT beanid EMPTY>

<!--
    Beanids must specify a name of the target bean.
    The "bean" attribute can reference any name from any bean in the 
context,
    to be checked at runtime by future Spring implementations.
    Local references, using the "local" attribute, have to use bean ids;
    they can be checked by this DTD, thus should be preferred for references
    within the same bean factory XML file.
-->
<!ATTLIST beanid bean CDATA #IMPLIED>
<!ATTLIST beanid local IDREF #IMPLIED>

This is the simplistic implementation, which immediately converts the 
attribute to a string property, same as a <value> element would, at 
parse time, so it doesn't touch very much code.

It is mostly useful with the 'local' attribute so that the parser 
validates bean id literal values immediately, instead of relying on the 
component using those values to do it later. It is also useful for any 
kind of IDE plugin to do name completion.

So a BeanNameAutoProxyCreator config which currently includes the 
following property:

   <property name="interceptorNames">
     <list>
       <value>hibInterceptor</value>
       <value>matchAllTxInterceptor</value>
     </list>
   </property>

can now become

   <property name="interceptorNames">
     <list>
       <beanid local="hibInterceptor"/>
       <beanid local="matchAllTxInterceptor"/>
     </list>
   </property>

and benefit from parser validation.

If somebody thinks another name would be more suitable for this element, 
please speak up. Other possibilities would be
  bean-id
  refid
  ref-id

Regards,
Colin


Rod Johnson wrote:

>Colin
>
>I think the first way would be preferable at this late stage. It's backward
>compatible anyway--previous definitions will still work--so I'm happy for
>you to do it.
>
>We can always improve the implementation in future.
>
>I'm happy with beanid/bean for naming.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Saturday, January 17, 2004 4:45 AM
>Subject: Re: [Springframework-developer] xml dtd addition for bean id
>reference
>
>
>  
>
>>I took a bit of a look at this. It would be completely trivial to
>>support at a basic level, where the element would be converted at parse
>>time into a string, essentially exactly resolving to exactly the same as
>><value>xx/<value>. This would allow validation of local beans via the
>>xml parser's idref mechanism, but would not allow Spring (or anybody
>>else using the parser) to validate external bean ids, since the info
>>would be lost.
>>
>>The better option would be to treat it in a way similar to the same way
>><ref> is treated right now, via a special placeholder similar to ref's
>>RuntimeBeanReference. This touches a lot more code though.
>>
>>Unless there is opposition I would like to add at least the basic level
>>mentioned in the first paragraph. I think it's a piece of low-hanging
>>fruit that will save some people from typos a bit earlier in the
>>build/deploy/test cycle...
>>
>>
>>
>>Colin Sampaleanu wrote:
>>
>>    
>>
>>>Actually, now that I think about it, it's not just about validation.
>>>If you are in an IDE plugin, the new element would allow the plugin to
>>>offer code completion on the id name... Otherwise (with the present
>>>setup), it would have to know something about the actual object using
>>>those properties, to know they are in fact bean ids...
>>>
>>>
>>>Rod Johnson wrote:
>>>
>>>      
>>>
>>>>Mmm, I'd need to think about that. I guess the validation potential
>>>>would be
>>>>good. Thoughts?
>>>>
>>>>Btw the switch from interceptors to interceptorNames was necessary as
>>>>the
>>>>old way was conceptually wrong. It couldn't handle common
>>>>interceptors or
>>>>advisors that were prototypes. This is important to support mixin
>>>>        
>>>>
>usage,
>  
>
>>>>which should now always work correctly.
>>>>
>>>>Rod
>>>>
>>>>----- Original Message -----
>>>>From: "Colin Sampaleanu" <col...@ex...>
>>>>To: <spr...@li...>
>>>>Sent: Wednesday, January 14, 2004 5:32 PM
>>>>Subject: [Springframework-developer] xml dtd addition for bean id
>>>>reference
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>The recent switch in AbstractAutoProxyCreate which forced me to switch
>>>>>some BeanNameAutoProxyCreator configs from something like
>>>>>...
>>>>>    <property name="interceptorNames">
>>>>>     <list>
>>>>>       <ref bean="hibInterceptor"/>
>>>>>       <ref bean="matchAllTxInterceptor</ref>
>>>>>     </list>
>>>>>   </property>
>>>>>...
>>>>>
>>>>>to
>>>>>...
>>>>>   <property name="interceptorNames">
>>>>>     <list>
>>>>>       <value>hibInterceptor</value>
>>>>>       <value>matchAllTxInterceptor</value>
>>>>>     </list>
>>>>>   </property>
>>>>>...
>>>>>
>>>>>got me thinking that the former did have the advantage of being much
>>>>>easier to validate without getting the actual user of the properties
>>>>>(the postprocessor in this case) involved. That is, in the case of a
>>>>>  <ref local="xxx" />
>>>>>the xml processor can do it, while
>>>>>  <ref bean="xxx" />
>>>>>can be validate by the loader or something like an Eclipse plugin. But
>>>>>
>>>>>   <property name="interceptorNames">
>>>>>     <list>
>>>>>       <value>something</value>
>>>>>     </list>
>>>>>   </property>
>>>>>
>>>>>can only be validate by the user of that property.  So how about we
>>>>>          
>>>>>
>add
>  
>
>>>>>another element which is used to produce a text value which is a bean
>>>>>id. That is:
>>>>>   <property name="interceptorNames">
>>>>>     <list>
>>>>>       <beanid bean="a-local-or-external-bean"/>
>>>>>       <beanid local="a-local-bean"/>
>>>>>     </list>
>>>>>   </property>
>>>>>
>>>>>The latter beanid element would be checked by the xml processor. The
>>>>>former would be checkable only by the loader or by something like an
>>>>>IDE
>>>>>plugin.
>>>>>
>>>>>What does everybody think?
>>>>>
>>>>>Regards,
>>>>>Colin
>>>>>          
>>>>>

Re: [Springframework-developer] xml dtd addition for bean id reference

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

Colin

I think the first way would be preferable at this late stage. It's backward
compatible anyway--previous definitions will still work--so I'm happy for
you to do it.

We can always improve the implementation in future.

I'm happy with beanid/bean for naming.

Regards,
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Saturday, January 17, 2004 4:45 AM
Subject: Re: [Springframework-developer] xml dtd addition for bean id
reference


> I took a bit of a look at this. It would be completely trivial to
> support at a basic level, where the element would be converted at parse
> time into a string, essentially exactly resolving to exactly the same as
> <value>xx/<value>. This would allow validation of local beans via the
> xml parser's idref mechanism, but would not allow Spring (or anybody
> else using the parser) to validate external bean ids, since the info
> would be lost.
>
> The better option would be to treat it in a way similar to the same way
> <ref> is treated right now, via a special placeholder similar to ref's
> RuntimeBeanReference. This touches a lot more code though.
>
> Unless there is opposition I would like to add at least the basic level
> mentioned in the first paragraph. I think it's a piece of low-hanging
> fruit that will save some people from typos a bit earlier in the
> build/deploy/test cycle...
>
>
>
> Colin Sampaleanu wrote:
>
> > Actually, now that I think about it, it's not just about validation.
> > If you are in an IDE plugin, the new element would allow the plugin to
> > offer code completion on the id name... Otherwise (with the present
> > setup), it would have to know something about the actual object using
> > those properties, to know they are in fact bean ids...
> >
> >
> > Rod Johnson wrote:
> >
> >> Mmm, I'd need to think about that. I guess the validation potential
> >> would be
> >> good. Thoughts?
> >>
> >> Btw the switch from interceptors to interceptorNames was necessary as
> >> the
> >> old way was conceptually wrong. It couldn't handle common
> >> interceptors or
> >> advisors that were prototypes. This is important to support mixin
usage,
> >> which should now always work correctly.
> >>
> >> Rod
> >>
> >> ----- Original Message -----
> >> From: "Colin Sampaleanu" <col...@ex...>
> >> To: <spr...@li...>
> >> Sent: Wednesday, January 14, 2004 5:32 PM
> >> Subject: [Springframework-developer] xml dtd addition for bean id
> >> reference
> >>
> >>
> >>
> >>
> >>> The recent switch in AbstractAutoProxyCreate which forced me to switch
> >>> some BeanNameAutoProxyCreator configs from something like
> >>> ...
> >>>     <property name="interceptorNames">
> >>>      <list>
> >>>        <ref bean="hibInterceptor"/>
> >>>        <ref bean="matchAllTxInterceptor</ref>
> >>>      </list>
> >>>    </property>
> >>> ...
> >>>
> >>> to
> >>> ...
> >>>    <property name="interceptorNames">
> >>>      <list>
> >>>        <value>hibInterceptor</value>
> >>>        <value>matchAllTxInterceptor</value>
> >>>      </list>
> >>>    </property>
> >>> ...
> >>>
> >>> got me thinking that the former did have the advantage of being much
> >>> easier to validate without getting the actual user of the properties
> >>> (the postprocessor in this case) involved. That is, in the case of a
> >>>   <ref local="xxx" />
> >>> the xml processor can do it, while
> >>>   <ref bean="xxx" />
> >>> can be validate by the loader or something like an Eclipse plugin. But
> >>>
> >>>    <property name="interceptorNames">
> >>>      <list>
> >>>        <value>something</value>
> >>>      </list>
> >>>    </property>
> >>>
> >>> can only be validate by the user of that property.  So how about we
add
> >>> another element which is used to produce a text value which is a bean
> >>> id. That is:
> >>>    <property name="interceptorNames">
> >>>      <list>
> >>>        <beanid bean="a-local-or-external-bean"/>
> >>>        <beanid local="a-local-bean"/>
> >>>      </list>
> >>>    </property>
> >>>
> >>> The latter beanid element would be checked by the xml processor. The
> >>> former would be checkable only by the loader or by something like an
> >>> IDE
> >>> plugin.
> >>>
> >>> What does everybody think?
> >>>
> >>> Regards,
> >>> Colin
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> This SF.net email is sponsored by: Perforce Software.
> >>> Perforce is the Fast Software Configuration Management System offering
> >>> advanced branching capabilities and atomic changes on 50+ platforms.
> >>> Free Eval! http://www.perforce.com/perforce/loadprog.html
> >>> _______________________________________________
> >>> 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

Re: [Springframework-developer] xml dtd addition for bean id reference

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

I took a bit of a look at this. It would be completely trivial to 
support at a basic level, where the element would be converted at parse 
time into a string, essentially exactly resolving to exactly the same as 
<value>xx/<value>. This would allow validation of local beans via the 
xml parser's idref mechanism, but would not allow Spring (or anybody 
else using the parser) to validate external bean ids, since the info 
would be lost.

The better option would be to treat it in a way similar to the same way 
<ref> is treated right now, via a special placeholder similar to ref's 
RuntimeBeanReference. This touches a lot more code though.

Unless there is opposition I would like to add at least the basic level 
mentioned in the first paragraph. I think it's a piece of low-hanging 
fruit that will save some people from typos a bit earlier in the 
build/deploy/test cycle...



Colin Sampaleanu wrote:

> Actually, now that I think about it, it's not just about validation. 
> If you are in an IDE plugin, the new element would allow the plugin to 
> offer code completion on the id name... Otherwise (with the present 
> setup), it would have to know something about the actual object using 
> those properties, to know they are in fact bean ids...
>
>
> Rod Johnson wrote:
>
>> Mmm, I'd need to think about that. I guess the validation potential 
>> would be
>> good. Thoughts?
>>
>> Btw the switch from interceptors to interceptorNames was necessary as 
>> the
>> old way was conceptually wrong. It couldn't handle common 
>> interceptors or
>> advisors that were prototypes. This is important to support mixin usage,
>> which should now always work correctly.
>>
>> Rod
>>
>> ----- Original Message -----
>> From: "Colin Sampaleanu" <col...@ex...>
>> To: <spr...@li...>
>> Sent: Wednesday, January 14, 2004 5:32 PM
>> Subject: [Springframework-developer] xml dtd addition for bean id 
>> reference
>>
>>
>>  
>>
>>> The recent switch in AbstractAutoProxyCreate which forced me to switch
>>> some BeanNameAutoProxyCreator configs from something like
>>> ...
>>>     <property name="interceptorNames">
>>>      <list>
>>>        <ref bean="hibInterceptor"/>
>>>        <ref bean="matchAllTxInterceptor</ref>
>>>      </list>
>>>    </property>
>>> ...
>>>
>>> to
>>> ...
>>>    <property name="interceptorNames">
>>>      <list>
>>>        <value>hibInterceptor</value>
>>>        <value>matchAllTxInterceptor</value>
>>>      </list>
>>>    </property>
>>> ...
>>>
>>> got me thinking that the former did have the advantage of being much
>>> easier to validate without getting the actual user of the properties
>>> (the postprocessor in this case) involved. That is, in the case of a
>>>   <ref local="xxx" />
>>> the xml processor can do it, while
>>>   <ref bean="xxx" />
>>> can be validate by the loader or something like an Eclipse plugin. But
>>>
>>>    <property name="interceptorNames">
>>>      <list>
>>>        <value>something</value>
>>>      </list>
>>>    </property>
>>>
>>> can only be validate by the user of that property.  So how about we add
>>> another element which is used to produce a text value which is a bean
>>> id. That is:
>>>    <property name="interceptorNames">
>>>      <list>
>>>        <beanid bean="a-local-or-external-bean"/>
>>>        <beanid local="a-local-bean"/>
>>>      </list>
>>>    </property>
>>>
>>> The latter beanid element would be checked by the xml processor. The
>>> former would be checkable only by the loader or by something like an 
>>> IDE
>>> plugin.
>>>
>>> What does everybody think?
>>>
>>> Regards,
>>> Colin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: Perforce Software.
>>> Perforce is the Fast Software Configuration Management System offering
>>> advanced branching capabilities and atomic changes on 50+ platforms.
>>> Free Eval! http://www.perforce.com/perforce/loadprog.html
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>   
>>

[Springframework-developer] ibatis java.lang.Verify errors

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm getting the following error on running jpetstore..

java.lang.VerifyError: (class: com/ibatis/db/sqlmap/XmlSqlMapBuilder,
method: buildFragmentList signature: (Lorg/jdom/Element;)Ljava/util/List;)
Incompatible object argument for function call

has anyone else seen this - is there a dodgy jar file in CVS or do I have
something screwed up locally?

- --

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFACE3tKLMLAN01aw0RAtO8AJ0TmmvW/m/MKsXtb6AKyOHLVflIGQCeNksK
cCi4Ym4j1wJyu9wc0/HbF+8=
=RPR8
-----END PGP SIGNATURE-----

RE: [Springframework-developer] Eclipse CVS access problem

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

And I have 2.1.0 version of Eclipse...

-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...] 
Sent: Friday, January 16, 2004 3:24 PM
To: 'spr...@li...'
Subject: RE: [Springframework-developer] Eclipse CVS access problem


Thanks Thomas...

D.

-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...] 
Sent: Friday, January 16, 2004 3:17 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Eclipse CVS access problem


There is a bug accessing recent CVS versions in Eclipse 2.1.2 that has been
fixed in later 3.0 milestones. I think it will be inlcuded in 2.1.3.  There
is a fix - you have to download and replace cvs.jar - see this location for
more info: 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=45138

I hit the same thing the other day when I tried to use a 2.1.2 version.

Thomas


Quoting Colin Sampaleanu <col...@ex...>:

> Kopylenko, Dmitry wrote:
> 
> > I've deleted Spring project from my local workspace (wanted to do a 
> > clean check out), but now I'm having a problem accessing CVS HEAD 
> > from CVS perspective - it just simply does not show any contents. 
> > Does anyone have similar problem?
> >
> > Thanks,
> > Dmitriy.
> >
> I don't know what's up with your Eclipse CVS perspective, but the easy 
> alternative is to pull out the source with something like TortoiseCVS 
> or another CVS tool, then in Eclipse do an 'import existing project', 
> then 'Team|Share', and you will be up and going... The share will pick 
> up on the fact that you already have CVS metadata there, so you won't 
> have to point to the repo again...
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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

RE: [Springframework-developer] Eclipse CVS access problem

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

Thanks Thomas...

D.

-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...] 
Sent: Friday, January 16, 2004 3:17 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Eclipse CVS access problem


There is a bug accessing recent CVS versions in Eclipse 2.1.2 that has been
fixed in later 3.0 milestones. I think it will be inlcuded in 2.1.3.  There
is a fix - you have to download and replace cvs.jar - see this location for
more info: 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=45138

I hit the same thing the other day when I tried to use a 2.1.2 version.

Thomas


Quoting Colin Sampaleanu <col...@ex...>:

> Kopylenko, Dmitry wrote:
> 
> > I've deleted Spring project from my local workspace (wanted to do a
> > clean check out), but now I'm having a problem accessing CVS HEAD from 
> > CVS perspective - it just simply does not show any contents. Does 
> > anyone have similar problem?
> >
> > Thanks,
> > Dmitriy.
> >
> I don't know what's up with your Eclipse CVS perspective, but the easy
> alternative is to pull out the source with something like TortoiseCVS or 
> another CVS tool, then in Eclipse do an 'import existing project', then 
> 'Team|Share', and you will be up and going... The share will pick up on 
> the fact that you already have CVS metadata there, so you won't have to 
> point to the repo again...
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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

Re: [Springframework-developer] Eclipse CVS access problem

[<tri...@tr...>]

There is a bug accessing recent CVS versions in Eclipse 2.1.2 that has been
fixed in later 3.0 milestones. I think it will be inlcuded in 2.1.3.  There is a
fix - you have to download and replace cvs.jar - see this location for more info: 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=45138

I hit the same thing the other day when I tried to use a 2.1.2 version.

Thomas


Quoting Colin Sampaleanu <col...@ex...>:

> Kopylenko, Dmitry wrote:
> 
> > I've deleted Spring project from my local workspace (wanted to do a 
> > clean check out), but now I'm having a problem accessing CVS HEAD from 
> > CVS perspective - it just simply does not show any contents. Does 
> > anyone have similar problem?
> >
> > Thanks,
> > Dmitriy.
> >
> I don't know what's up with your Eclipse CVS perspective, but the easy 
> alternative is to pull out the source with something like TortoiseCVS or 
> another CVS tool, then in Eclipse do an 'import existing project', then 
> 'Team|Share', and you will be up and going... The share will pick up on 
> the fact that you already have CVS metadata there, so you won't have to 
> point to the repo again...
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> 

RE: [Springframework-developer] Eclipse CVS access problem

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

Thanks Colin, I'll try that...

D.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...] 
Sent: Friday, January 16, 2004 2:33 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Eclipse CVS access problem


Kopylenko, Dmitry wrote:

> I've deleted Spring project from my local workspace (wanted to do a
> clean check out), but now I'm having a problem accessing CVS HEAD from 
> CVS perspective - it just simply does not show any contents. Does 
> anyone have similar problem?
>
> Thanks,
> Dmitriy.
>
I don't know what's up with your Eclipse CVS perspective, but the easy 
alternative is to pull out the source with something like TortoiseCVS or 
another CVS tool, then in Eclipse do an 'import existing project', then 
'Team|Share', and you will be up and going... The share will pick up on 
the fact that you already have CVS metadata there, so you won't have to 
point to the repo again...





-------------------------------------------------------
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

Re: [Springframework-developer] Eclipse CVS access problem

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

Kopylenko, Dmitry wrote:

> I've deleted Spring project from my local workspace (wanted to do a 
> clean check out), but now I'm having a problem accessing CVS HEAD from 
> CVS perspective - it just simply does not show any contents. Does 
> anyone have similar problem?
>
> Thanks,
> Dmitriy.
>
I don't know what's up with your Eclipse CVS perspective, but the easy 
alternative is to pull out the source with something like TortoiseCVS or 
another CVS tool, then in Eclipse do an 'import existing project', then 
'Team|Share', and you will be up and going... The share will pick up on 
the fact that you already have CVS metadata there, so you won't have to 
point to the repo again...

[Springframework-developer] Eclipse CVS access problem

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

I've deleted Spring project from my local workspace (wanted to do a clean
check out), but now I'm having a problem accessing CVS HEAD from CVS
perspective - it just simply does not show any contents. Does anyone have
similar problem?

Thanks,
Dmitriy.

Re: [Springframework-developer] weblogic on linux anyone?

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

ad...@tr... wrote:

> I'm currently running it on Debian, along side Oracle 9.2. No problems 
> so far, but we have not gone into production yet.

thanks Adam.  It's only for build & deployment testing so that should be fine.

Cheers,


-- 

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

Re: [Springframework-developer] weblogic on linux anyone?

[<ad...@tr...>]

On 01-16-2004 1:01 +0000 Darren Davison <da...@da...> wrote:
> have any of you WLS guys ever run it on Linux (other than RedHat?)  The
> BEA
> download page specifies RedHat as the only linux option - just wondering
> if
> there really was some DeadRat dependency in there b4 grabbing it and
> finding
> it doesn't work..?

I'm currently running it on Debian, along side Oracle 9.2. No problems so 
far, but we have not gone into production yet.

A.

-- 
Adam Sherman
Tritus CG Inc.
+1 (613) 797-6819
http://www.tritus.ca/

[Springframework-developer] weblogic on linux anyone?

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

have any of you WLS guys ever run it on Linux (other than RedHat?)  The BEA
download page specifies RedHat as the only linux option - just wondering if
there really was some DeadRat dependency in there b4 grabbing it and finding
it doesn't work..?

Cheers,

- --

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFABzfRKLMLAN01aw0RAvGMAJ4qysdSCii9j64yVV+hzHh0YerJwgCeL6zv
hgWE27meED1bu7VpAbQn8DY=
=+sxA
-----END PGP SIGNATURE-----

RE: [Springframework-developer] FW: [springframework - Help] spring:transform tag config missing?

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

Yup, I'll have a look at at first thing tomorrow morning... Gotta catch
some sleept first ;-)

Alef


> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Thursday, January 15, 2004 4:00 PM
> To: spr...@li...
> Subject: [Springframework-developer] FW: [springframework -=20
> Help] spring:transform tag config missing?
>=20
>=20
> Alef, could you have a look at this?
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: SourceForge.net [mailto:no...@so...]
> Sent: Tuesday, January 13, 2004 1:22 AM
> To: no...@so...
> Subject: [springframework - Help] spring:transform tag config missing?
>=20
>=20
>=20
> Read and respond to this message at:=20
> https://sourceforge.net/forum/message.php?msg_id=3D2371816
> By: ee4ptm
>=20
> The tag documentation included with the distribution=20
> documents a transform tag which supports transforming=20
> properties not contained by a command object eg reference=20
> data. I've tried using this tag but get a JasperException -=20
> no such tag transform in the tag library imported with prefix=20
> spring. Looking in the spring.tld file this tag isn't listed=20
> (all of the other tags
> are) and looking at CVS never has. The changelog states it=20
> was included in M2. Should I be using the transform tag - is=20
> it just missing from spring.tld - or is there some other way=20
> I should be accessing reference data and transforming it=20
> using a registered property editor?
>=20
> Thanks,
>=20
> Paul
>=20
> ______________________________________________________________________
> You are receiving this email because you elected to monitor=20
> this forum. To stop monitoring this forum, login to=20
> SourceForge.net and visit:=20
> https://sourceforge.net/forum/unmonitor.php?forum_id=3D250340
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System=20
> offering advanced branching capabilities and atomic changes=20
> on 50+ platforms. Free Eval!=20
> http://www.perforce.com/perforce/loadprog.h> tml
>=20
> _______________________________________________
>=20
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

[Springframework-developer] FW: [springframework - Help] spring:transform tag config missing?

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

Alef, could you have a look at this?

Juergen


-----Original Message-----
From: SourceForge.net [mailto:no...@so...]
Sent: Tuesday, January 13, 2004 1:22 AM
To: no...@so...
Subject: [springframework - Help] spring:transform tag config missing?



Read and respond to this message at:=20
https://sourceforge.net/forum/message.php?msg_id=3D2371816
By: ee4ptm

The tag documentation included with the distribution documents a =
transform tag
which supports transforming properties not contained by a command object =
eg
reference data.
I've tried using this tag but get a JasperException - no such tag =
transform
in the tag library imported with prefix spring.
Looking in the spring.tld file this tag isn't listed (all of the other =
tags
are) and looking at CVS never has. The changelog states it was included =
in M2.
Should I be using the transform tag - is it just missing from spring.tld =
- or
is there some other way I should be accessing reference data and =
transforming
it using a registered property editor?

Thanks,

Paul

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:=20
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250340

Re: [Springframework-developer] xml dtd addition for bean id reference

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

Actually, now that I think about it, it's not just about validation. If 
you are in an IDE plugin, the new element would allow the plugin to 
offer code completion on the id name... Otherwise (with the present 
setup), it would have to know something about the actual object using 
those properties, to know they are in fact bean ids...


Rod Johnson wrote:

>Mmm, I'd need to think about that. I guess the validation potential would be
>good. Thoughts?
>
>Btw the switch from interceptors to interceptorNames was necessary as the
>old way was conceptually wrong. It couldn't handle common interceptors or
>advisors that were prototypes. This is important to support mixin usage,
>which should now always work correctly.
>
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Wednesday, January 14, 2004 5:32 PM
>Subject: [Springframework-developer] xml dtd addition for bean id reference
>
>
>  
>
>>The recent switch in AbstractAutoProxyCreate which forced me to switch
>>some BeanNameAutoProxyCreator configs from something like
>>...
>>     <property name="interceptorNames">
>>      <list>
>>        <ref bean="hibInterceptor"/>
>>        <ref bean="matchAllTxInterceptor</ref>
>>      </list>
>>    </property>
>>...
>>
>>to
>>...
>>    <property name="interceptorNames">
>>      <list>
>>        <value>hibInterceptor</value>
>>        <value>matchAllTxInterceptor</value>
>>      </list>
>>    </property>
>>...
>>
>>got me thinking that the former did have the advantage of being much
>>easier to validate without getting the actual user of the properties
>>(the postprocessor in this case) involved. That is, in the case of a
>>   <ref local="xxx" />
>>the xml processor can do it, while
>>   <ref bean="xxx" />
>>can be validate by the loader or something like an Eclipse plugin. But
>>
>>    <property name="interceptorNames">
>>      <list>
>>        <value>something</value>
>>      </list>
>>    </property>
>>
>>can only be validate by the user of that property.  So how about we add
>>another element which is used to produce a text value which is a bean
>>id. That is:
>>    <property name="interceptorNames">
>>      <list>
>>        <beanid bean="a-local-or-external-bean"/>
>>        <beanid local="a-local-bean"/>
>>      </list>
>>    </property>
>>
>>The latter beanid element would be checked by the xml processor. The
>>former would be checkable only by the loader or by something like an IDE
>>plugin.
>>
>>What does everybody think?
>>
>>Regards,
>>Colin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Perforce Software.
>>Perforce is the Fast Software Configuration Management System offering
>>advanced branching capabilities and atomic changes on 50+ platforms.
>>Free Eval! http://www.perforce.com/perforce/loadprog.html
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>    
>>

Re: [Springframework-developer] xml dtd addition for bean id reference

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

Mmm, I'd need to think about that. I guess the validation potential would be
good. Thoughts?

Btw the switch from interceptors to interceptorNames was necessary as the
old way was conceptually wrong. It couldn't handle common interceptors or
advisors that were prototypes. This is important to support mixin usage,
which should now always work correctly.

Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Wednesday, January 14, 2004 5:32 PM
Subject: [Springframework-developer] xml dtd addition for bean id reference


> The recent switch in AbstractAutoProxyCreate which forced me to switch
> some BeanNameAutoProxyCreator configs from something like
> ...
>      <property name="interceptorNames">
>       <list>
>         <ref bean="hibInterceptor"/>
>         <ref bean="matchAllTxInterceptor</ref>
>       </list>
>     </property>
> ...
>
> to
> ...
>     <property name="interceptorNames">
>       <list>
>         <value>hibInterceptor</value>
>         <value>matchAllTxInterceptor</value>
>       </list>
>     </property>
> ...
>
> got me thinking that the former did have the advantage of being much
> easier to validate without getting the actual user of the properties
> (the postprocessor in this case) involved. That is, in the case of a
>    <ref local="xxx" />
> the xml processor can do it, while
>    <ref bean="xxx" />
> can be validate by the loader or something like an Eclipse plugin. But
>
>     <property name="interceptorNames">
>       <list>
>         <value>something</value>
>       </list>
>     </property>
>
> can only be validate by the user of that property.  So how about we add
> another element which is used to produce a text value which is a bean
> id. That is:
>     <property name="interceptorNames">
>       <list>
>         <beanid bean="a-local-or-external-bean"/>
>         <beanid local="a-local-bean"/>
>       </list>
>     </property>
>
> The latter beanid element would be checked by the xml processor. The
> former would be checkable only by the loader or by something like an IDE
> plugin.
>
> What does everybody think?
>
> Regards,
> Colin
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] xml dtd addition for bean id reference

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

The recent switch in AbstractAutoProxyCreate which forced me to switch 
some BeanNameAutoProxyCreator configs from something like
...
     <property name="interceptorNames">
      <list>
        <ref bean="hibInterceptor"/>
        <ref bean="matchAllTxInterceptor</ref>
      </list>
    </property>
...

to
...
    <property name="interceptorNames">
      <list>
        <value>hibInterceptor</value>
        <value>matchAllTxInterceptor</value>
      </list>
    </property>
...

got me thinking that the former did have the advantage of being much 
easier to validate without getting the actual user of the properties 
(the postprocessor in this case) involved. That is, in the case of a
   <ref local="xxx" />
the xml processor can do it, while
   <ref bean="xxx" />
can be validate by the loader or something like an Eclipse plugin. But

    <property name="interceptorNames">
      <list>
        <value>something</value>
      </list>
    </property>

can only be validate by the user of that property.  So how about we add 
another element which is used to produce a text value which is a bean 
id. That is:
    <property name="interceptorNames">
      <list>
        <beanid bean="a-local-or-external-bean"/>
        <beanid local="a-local-bean"/>
      </list>
    </property>

The latter beanid element would be checked by the xml processor. The 
former would be checkable only by the loader or by something like an IDE 
plugin.

What does everybody think?

Regards,
Colin

[Springframework-developer] Javadoc comments for ParameterizableViewController

[Luke T. <ne...@fr...>]

Hi all,

Just been looking through some of the Javadoc to see if it can be tidied 
up at all. I'm looking at this class

http://monkeymachine.co.uk/spring/xref/org/springframework/web/servlet/mvc/ParameterizableViewController.html#12

and can't make much sense of the phrase

"letter the some the configuration determine (instead of the controller) 
the viewtechnology."

Should that be:

"letting the configuration determine the view technology (instead of the 
controller)."

The next paragraph is pretty confusing too:

"An alternative to the ParameterizableViewController is of the
{@link org.springframework.web.servlet.mvc.multiaction MultiAction 
controllers}, some of which allow the same behavior, but then for more 
views at in one controller."

Not sure I even want to have a stab at what that should be :). Something 
along the lines of

".... Multiaction controller}, which can also be used with decoupled 
(named) views, but where different views can be returned depending on 
the desired application workflow."

perhaps?

Let me know if that makes sense and I'll make the changes.

Luke.

-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

Re: [Springframework-developer] PROPOGATION_REQUIRESNEW

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

I guess whether it's worth it depends on the usage scenario, to some=20
extent. If you think about people using something like JBoss or=20
WebLogic, who want to drop EJBs, but still want the app server because=20
they use JMS or for some other reason, they would probably prefer to=20
keep using the app server's transaction manager. So these people would=20
not be helped at all.

On the other hand, if somebody is willing to work in a lighter weight=20
environment (TomCat with JOTM or something of the sort), then it would=20
be of some use.

Unfortunately I don't feel comfortable messing around in that particular=20
code in Spring (all I've ever done is step through it), so it would have=20
to be something you do when/if you have the time and inclination.

Actually I should take a look and see if JBoss and WebLogic support any=20
sort of proprietary access to the transaction manager. If so, this stuff=20
could at least be pluggable...


j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>=20
>Good point - I've been wondering about this myself repeatedly. As you sa=
y, it seems that you can just implement REQUIRESNEW with knowledge about =
the internals of the transaction manager, as the JTA API does not offer a=
ny means to suspend a transaction. So that seems to stay a unique EJB fea=
ture, unfortunately - except maybe for specific transaction managers of s=
pecific J2EE servers where someone figures out how to trigger this.
>=20
>We *could* implement this for Spring's own transaction managers, namely =
DataSourceTransactionManager, HibernateTransactionManager, and JdoTransac=
tionManager. It wouldn't be too hard, actually: basically unbind the curr=
ent transaction from the thread, store it in the backyard of the new tran=
saction object, bind the new transaction to the thread. On commit of the =
new transaction, rebind the original transaction to the thread.
>=20
>Do you think that would be worthwhile? It's really just about a couple o=
f hours; if I find the time, I might implement this. Of course, not for J=
taTransactionManager: that would require server-specific subclasses, and =
more importantly, figuring out the proprietary API.
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n Colin Sampaleanu
>Gesendet: So 11.01.2004 21:46
>An: spr...@li...
>Betreff: [Springframework-developer] PROPOGATION_REQUIRESNEW
>
>
>
>What would be involved in supporting PROPOGATION_REQUIRESNEW, similar to
>an EJB setting of RequiresNew?
>
>While J2EE doesn't support nested transactions for EJBs (although
>JTS/JTA may or may not) EJBs do support the RequiresNew setting, which
>is supposed to 'suspend' the current transaction and start a new one,
>the termination of which will either commit or rollback the new
>transaction, without affecting the enclosing one.
>
>Now if you are dealing with a UserTransaction object, and call begin(),
>my understanding is that you will either get a real nested transaction
>if the transaction manager supports nested transactions, or an exception
>if it doesn't (which presumably most transaction managers in most
>containers will not).
>
>So I am curious how EJB containers implement RequiresNew. I presume that
>as of the RequiresNew, they associate an entirely new transaction
>manager for the purposes of that EJB/thread. As such, it would be
>impossible for Spring to do the same thing when working with a JTA
>UserTransaction from JNDI, since it is not the container actually
>managing the transaction manager. I presume if Spring itself were to
>completely manage transactions (ie it was the transaction manager) then
>it would not be an issue to simulate the EJB behaviour.
>
>Part of my reason for bringing up this topic is that people converting
>code from EJBs often have declarative transactions with RequiresNew. Now
>a lot of the time it makes no difference if they switch to Requires (and
>in fact they used Requires vs. RequiresNew due to the restrictive EJB
>level locking implemented by most containers), but some of the time, for
>handling things like logging, etc., RequiresNew would be desirable.
>
>Anybody care to comment?
>
>Regards
>Colin
> =20
>

Re: [Springframework-developer] PROPOGATION_REQUIRESNEW

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

Colin,
=20
Good point - I've been wondering about this myself repeatedly. As you =
say, it seems that you can just implement REQUIRESNEW with knowledge =
about the internals of the transaction manager, as the JTA API does not =
offer any means to suspend a transaction. So that seems to stay a unique =
EJB feature, unfortunately - except maybe for specific transaction =
managers of specific J2EE servers where someone figures out how to =
trigger this.
=20
We *could* implement this for Spring's own transaction managers, namely =
DataSourceTransactionManager, HibernateTransactionManager, and =
JdoTransactionManager. It wouldn't be too hard, actually: basically =
unbind the current transaction from the thread, store it in the backyard =
of the new transaction object, bind the new transaction to the thread. =
On commit of the new transaction, rebind the original transaction to the =
thread.
=20
Do you think that would be worthwhile? It's really just about a couple =
of hours; if I find the time, I might implement this. Of course, not for =
JtaTransactionManager: that would require server-specific subclasses, =
and more importantly, figuring out the proprietary API.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 11.01.2004 21:46
An: spr...@li...
Betreff: [Springframework-developer] PROPOGATION_REQUIRESNEW



What would be involved in supporting PROPOGATION_REQUIRESNEW, similar to
an EJB setting of RequiresNew?

While J2EE doesn't support nested transactions for EJBs (although
JTS/JTA may or may not) EJBs do support the RequiresNew setting, which
is supposed to 'suspend' the current transaction and start a new one,
the termination of which will either commit or rollback the new
transaction, without affecting the enclosing one.

Now if you are dealing with a UserTransaction object, and call begin(),
my understanding is that you will either get a real nested transaction
if the transaction manager supports nested transactions, or an exception
if it doesn't (which presumably most transaction managers in most
containers will not).

So I am curious how EJB containers implement RequiresNew. I presume that
as of the RequiresNew, they associate an entirely new transaction
manager for the purposes of that EJB/thread. As such, it would be
impossible for Spring to do the same thing when working with a JTA
UserTransaction from JNDI, since it is not the container actually
managing the transaction manager. I presume if Spring itself were to
completely manage transactions (ie it was the transaction manager) then
it would not be an issue to simulate the EJB behaviour.

Part of my reason for bringing up this topic is that people converting
code from EJBs often have declarative transactions with RequiresNew. Now
a lot of the time it makes no difference if they switch to Requires (and
in fact they used Requires vs. RequiresNew due to the restrictive EJB
level locking implemented by most containers), but some of the time, for
handling things like logging, etc., RequiresNew would be desirable.

Anybody care to comment?

Regards
Colin





-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer