springframework-developer — Spring Framework developers list

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

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

Colin,
=20
It may be a detail, but I'm not too happy with the two virtually =
identical classes XmlBeanFactoryLoader and =
XmlApplicationContextBeanFactoryLoader (and the name of the latter).
=20
I suggest to refactor the latter as a subclass of XmlBeanFactoryLoader: =
Why not simply offer a "BeanFactory createBeanFactory(String =
beanFactoryPath)" template method there, defaulting to an =
XmlBeanFactory? The subclass could then override this for a =
ClassPathXmlApplicationContext.
=20
Regarding the name, I suggest to call the subclass =
"XmlApplicationContextLoader", even if it does not contain the full =
interface name "BeanFactoryLoader": After all, an ApplicationContext =
*is* a BeanFactory, so it's better to just use one of the two terms in =
the class name, IMO.
=20
As a side note, the transaction manager implementation names do not =
contain the full interface name "PlatformTransactionManager" either. In =
general, if the resulting name is expressive enough, I prefer such a =
simplified name instead of one that contains the full interface name in =
the first place.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 18.01.2004 01:21
An: spr...@li...; Peter den Haan
Betreff: Re: [Springframework-developer] PostProcessor infrastructure in =
DefaultListableBeanFactory and EJB support classes



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.
>>> =20
>>
>> 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).
>>=20
>>
> 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
>




-------------------------------------------------------
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] Spring supported in Mule

[Ross M. <ro...@at...>]

Mule is a project that I've been working on. It is an ESB framework - or 
at least will be by version 1.0 ;-).  It is currenlt being used in a 
production enviornment and is stable.  But as an ESB framework it is 
missing some functionality.

Currently, the Spring fuctionality is limited to wiring components for 
use by Mule (it also has support for Pico).

However, I've had the pleasure of working with Spring on some other 
projects over the last couple of months and have been very impressed 
with the framework. So I'm seriously considering using Spring as base 
framework for Mule. I am particulary keen to leverage Springs the AOP 
and Hibernate support.

Cheers,

Ross
http://blog.rossmason.com

Colin Sampaleanu wrote:
> Just took a look at a project called Mule, which appears to try to 
> provide 'Enterprise Service Bus' functionality. It has built-in support 
> for Spring as a component source/container...
>  http://www.muleumo.org/index.html
>  http://www.muleumo.org/architectureGuide.html
> 
> 
> 
> -------------------------------------------------------
> 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] Discussion involving Spring

[Ken K. <kk...@kk...>]

Also, there are a lot of people who don't want to go anywhere that isn't 
part of an official or at least a defacto standard, as Struts seems to 
have become to some users.

Kopylenko, Dmitry wrote:

>Seems like there are still a lot of supporters (believers) of EJB (tm)
>technology out there....
>
>-----Original Message-----
>From: Rod Johnson [mailto:rod...@in...] 
>Sent: Wednesday, January 21, 2004 3:03 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Discussion involving Spring
>
>
>You just can't get away from Spring on news sites these days, can you... Not
>many of the recent posts (TSS etc) have originated from the Spring
>developers (although of course some of us have participated once they've got
>going)...
>
>----- Original Message -----
>From: "Ken Krebs" <kk...@kk...>
>To: "'spring-dev-list'" <spr...@li...>
>Sent: Wednesday, January 21, 2004 2:10 PM
>Subject: [Springframework-developer] Discussion involving Spring
>
>
>  
>
>>FYI,
>>
>>There is a good discussion involving Spring going on at JavaRanch.com 
>>if anyone's interested in participating.
>>
>>Topic: When to not use EJB
>>
>>    
>>
><http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=11&t
>=006707>
>  
>
>
>
>
>
>-------------------------------------------------------
>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] ClassPathXmlApplicationContext is sue.

[Pedro C. <ped...@ne...>]

Maybe It was some problem with eclipse class loading. i was running some
tests with it. I restarted it, and they are running fine now.

A Qua, 2004-01-21 às 19:35, Colin Sampaleanu escreveu:
> Sure, if you point to two different places on the filesystem, 
> FileSystemXmlApplicationContext would work fine. However, usually it's 
> not very convenient to point to hard-coded locations.
> 
> 
> Kopylenko, Dmitry wrote:
> 
> >Well, since ClassPathXmlApplicationContext extends
> >FileSystemXmlApplicationContext, it wouldn't work, would it? ;-)))
> >
> >Dmitriy. 
> >
> >-----Original Message-----
> >From: Kopylenko, Dmitry [mailto:dko...@ac...] 
> >Sent: Wednesday, January 21, 2004 2:18 PM
> >To: 'spr...@li...'
> >Subject: RE: [Springframework-developer] ClassPathXmlApplicationContext is
> >sue.
> >
> >
> >.... Or use FileSystemXmlApplicationContext
> >
> >Regards,
> >Dmitriy.
> >
> >-----Original Message-----
> >From: Colin Sampaleanu [mailto:col...@ex...] 
> >Sent: Wednesday, January 21, 2004 1:09 PM
> >To: spr...@li...
> >Subject: Re: [Springframework-developer] ClassPathXmlApplicationContext
> >issue.
> >
> >
> >Pedro,
> >
> >Spring does no manipulation of the classpath. It uses whatever classpath 
> >is given to it; generally this is the current thread's context 
> >classloader's classpath, as set by whatever environment it is in.
> >
> >If there are two application context definition files with the same name 
> >available on the classpath, then generally Spring will load whichever 
> >one the classloader returns. If this behaviour is not acceptable, then 
> >you have to have unique names...
> >
> >Regards,
> >Colin
> >
> >pedro.costa wrote:
> >
> >  
> >
> >>Hi all,
> >>
> >>I'm trying to load two different applicationContext xml file using
> >>ClassPathXmlApplicationContext.
> >>
> >>The files have the same name, but are on diferent class paths.
> >>
> >>What is happening is that it seams that spring is always finding the
> >>same file in both cases, regardless of the classpath that is used when
> >>    
> >>
> >creating ClassPathXmlApplicationContext.
> >  
> >
> >>I can see it from the logs.
> >>
> >>If i change the name of one of the files, it works fine.
> >>
> >>Is this a known problem?
> >>
> >>here is the code:
> >>
> >>ClassPathXmlApplicationContext appContext = new
> >>ClassPathXmlApplicationContext("replica/command/beans/beans.xml");
> >>
> >>BeansMappings beansMappings =
> >>(BeansMappings)appContext.getBean("serverCommandMappings");
> >>
> >>// no problem here ...
> >>
> >>ClassPathXmlApplicationContext appContext = new
> >>ClassPathXmlApplicationContext("replica/server/beans.xml");
> >>
> >>Listener listener = (Listener)appContext .getBean("serverListener");
> >>
> >>// Problem! it can't find it .... it seams to have loaded the first
> >>file again.
> >>
> >>// If i use a diferent file name,it works fine.
> >>
> >>
> >>
> >>thanks,
> >>
> >>Pedro.
> >>    
> >>
> 
> 
> 
> 
> -------------------------------------------------------
> 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
-- 
Pedro Costa <ped...@ne...>

RE: [Springframework-developer] Discussion involving Spring

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

Seems like there are still a lot of supporters (believers) of EJB (tm)
technology out there....

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Wednesday, January 21, 2004 3:03 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Discussion involving Spring


You just can't get away from Spring on news sites these days, can you... Not
many of the recent posts (TSS etc) have originated from the Spring
developers (although of course some of us have participated once they've got
going)...

----- Original Message -----
From: "Ken Krebs" <kk...@kk...>
To: "'spring-dev-list'" <spr...@li...>
Sent: Wednesday, January 21, 2004 2:10 PM
Subject: [Springframework-developer] Discussion involving Spring


> FYI,
>
> There is a good discussion involving Spring going on at JavaRanch.com 
> if anyone's interested in participating.
>
> Topic: When to not use EJB
>
<http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=11&t
=006707>
>




-------------------------------------------------------
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] Discussion involving Spring

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

You just can't get away from Spring on news sites these days, can you... Not
many of the recent posts (TSS etc) have originated from the Spring
developers (although of course some of us have participated once they've got
going)...

----- Original Message -----
From: "Ken Krebs" <kk...@kk...>
To: "'spring-dev-list'" <spr...@li...>
Sent: Wednesday, January 21, 2004 2:10 PM
Subject: [Springframework-developer] Discussion involving Spring


> FYI,
>
> There is a good discussion involving Spring going on at JavaRanch.com if
> anyone's interested in participating.
>
> Topic: When to not use EJB
>
<http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=11&t
=006707>
>

Re: [Springframework-developer] ClassPathXmlApplicationContext is sue.

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

Sure, if you point to two different places on the filesystem, 
FileSystemXmlApplicationContext would work fine. However, usually it's 
not very convenient to point to hard-coded locations.


Kopylenko, Dmitry wrote:

>Well, since ClassPathXmlApplicationContext extends
>FileSystemXmlApplicationContext, it wouldn't work, would it? ;-)))
>
>Dmitriy. 
>
>-----Original Message-----
>From: Kopylenko, Dmitry [mailto:dko...@ac...] 
>Sent: Wednesday, January 21, 2004 2:18 PM
>To: 'spr...@li...'
>Subject: RE: [Springframework-developer] ClassPathXmlApplicationContext is
>sue.
>
>
>.... Or use FileSystemXmlApplicationContext
>
>Regards,
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...] 
>Sent: Wednesday, January 21, 2004 1:09 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] ClassPathXmlApplicationContext
>issue.
>
>
>Pedro,
>
>Spring does no manipulation of the classpath. It uses whatever classpath 
>is given to it; generally this is the current thread's context 
>classloader's classpath, as set by whatever environment it is in.
>
>If there are two application context definition files with the same name 
>available on the classpath, then generally Spring will load whichever 
>one the classloader returns. If this behaviour is not acceptable, then 
>you have to have unique names...
>
>Regards,
>Colin
>
>pedro.costa wrote:
>
>  
>
>>Hi all,
>>
>>I'm trying to load two different applicationContext xml file using
>>ClassPathXmlApplicationContext.
>>
>>The files have the same name, but are on diferent class paths.
>>
>>What is happening is that it seams that spring is always finding the
>>same file in both cases, regardless of the classpath that is used when
>>    
>>
>creating ClassPathXmlApplicationContext.
>  
>
>>I can see it from the logs.
>>
>>If i change the name of one of the files, it works fine.
>>
>>Is this a known problem?
>>
>>here is the code:
>>
>>ClassPathXmlApplicationContext appContext = new
>>ClassPathXmlApplicationContext("replica/command/beans/beans.xml");
>>
>>BeansMappings beansMappings =
>>(BeansMappings)appContext.getBean("serverCommandMappings");
>>
>>// no problem here ...
>>
>>ClassPathXmlApplicationContext appContext = new
>>ClassPathXmlApplicationContext("replica/server/beans.xml");
>>
>>Listener listener = (Listener)appContext .getBean("serverListener");
>>
>>// Problem! it can't find it .... it seams to have loaded the first
>>file again.
>>
>>// If i use a diferent file name,it works fine.
>>
>>
>>
>>thanks,
>>
>>Pedro.
>>    
>>

RE: [Springframework-developer] ClassPathXmlApplicationContext is sue.

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

Well, since ClassPathXmlApplicationContext extends
FileSystemXmlApplicationContext, it wouldn't work, would it? ;-)))

Dmitriy. 

-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...] 
Sent: Wednesday, January 21, 2004 2:18 PM
To: 'spr...@li...'
Subject: RE: [Springframework-developer] ClassPathXmlApplicationContext is
sue.


.... Or use FileSystemXmlApplicationContext

Regards,
Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...] 
Sent: Wednesday, January 21, 2004 1:09 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ClassPathXmlApplicationContext
issue.


Pedro,

Spring does no manipulation of the classpath. It uses whatever classpath 
is given to it; generally this is the current thread's context 
classloader's classpath, as set by whatever environment it is in.

If there are two application context definition files with the same name 
available on the classpath, then generally Spring will load whichever 
one the classloader returns. If this behaviour is not acceptable, then 
you have to have unique names...

Regards,
Colin

pedro.costa wrote:

>Hi all,
> 
>I'm trying to load two different applicationContext xml file using
>ClassPathXmlApplicationContext.
> 
>The files have the same name, but are on diferent class paths.
> 
>What is happening is that it seams that spring is always finding the
>same file in both cases, regardless of the classpath that is used when
creating ClassPathXmlApplicationContext.
> 
>I can see it from the logs.
> 
>If i change the name of one of the files, it works fine.
> 
>Is this a known problem?
> 
>here is the code:
> 
>ClassPathXmlApplicationContext appContext = new
>ClassPathXmlApplicationContext("replica/command/beans/beans.xml");
>
>BeansMappings beansMappings =
>(BeansMappings)appContext.getBean("serverCommandMappings");
>
>// no problem here ...
>
>ClassPathXmlApplicationContext appContext = new
>ClassPathXmlApplicationContext("replica/server/beans.xml");
>
> Listener listener = (Listener)appContext .getBean("serverListener");
>
>// Problem! it can't find it .... it seams to have loaded the first
>file again.
>
>// If i use a diferent file name,it works fine.
>
> 
>
>thanks,
>
>Pedro.
>
> 
>




-------------------------------------------------------
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] ClassPathXmlApplicationContext is sue.

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

.... Or use FileSystemXmlApplicationContext

Regards,
Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...] 
Sent: Wednesday, January 21, 2004 1:09 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ClassPathXmlApplicationContext
issue.


Pedro,

Spring does no manipulation of the classpath. It uses whatever classpath 
is given to it; generally this is the current thread's context 
classloader's classpath, as set by whatever environment it is in.

If there are two application context definition files with the same name 
available on the classpath, then generally Spring will load whichever 
one the classloader returns. If this behaviour is not acceptable, then 
you have to have unique names...

Regards,
Colin

pedro.costa wrote:

>Hi all,
> 
>I'm trying to load two different applicationContext xml file using 
>ClassPathXmlApplicationContext.
> 
>The files have the same name, but are on diferent class paths.
> 
>What is happening is that it seams that spring is always finding the 
>same file in both cases, regardless of the classpath that is used when
creating ClassPathXmlApplicationContext.
> 
>I can see it from the logs.
> 
>If i change the name of one of the files, it works fine.
> 
>Is this a known problem?
> 
>here is the code:
> 
>ClassPathXmlApplicationContext appContext = new 
>ClassPathXmlApplicationContext("replica/command/beans/beans.xml");
>
>BeansMappings beansMappings = 
>(BeansMappings)appContext.getBean("serverCommandMappings");
>
>// no problem here ...
>
>ClassPathXmlApplicationContext appContext = new 
>ClassPathXmlApplicationContext("replica/server/beans.xml");
>
> Listener listener = (Listener)appContext .getBean("serverListener");
>
>// Problem! it can't find it .... it seams to have loaded the first 
>file again.
>
>// If i use a diferent file name,it works fine.
>
> 
>
>thanks,
>
>Pedro.
>
> 
>




-------------------------------------------------------
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] ClassPathXmlApplicationContext issue.

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

Pedro,

Spring does no manipulation of the classpath. It uses whatever classpath 
is given to it; generally this is the current thread's context 
classloader's classpath, as set by whatever environment it is in.

If there are two application context definition files with the same name 
available on the classpath, then generally Spring will load whichever 
one the classloader returns. If this behaviour is not acceptable, then 
you have to have unique names...

Regards,
Colin

pedro.costa wrote:

>Hi all,
> 
>I'm trying to load two different applicationContext xml file using ClassPathXmlApplicationContext.
> 
>The files have the same name, but are on diferent class paths.
> 
>What is happening is that it seams that spring is always finding the same file in both cases, regardless of the classpath that is used when creating ClassPathXmlApplicationContext.
> 
>I can see it from the logs.
> 
>If i change the name of one of the files, it works fine.
> 
>Is this a known problem?
> 
>here is the code:
> 
>ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext("replica/command/beans/beans.xml");
>
>BeansMappings beansMappings = (BeansMappings)appContext.getBean("serverCommandMappings");
>
>// no problem here ... 
>
>ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext("replica/server/beans.xml");
>
> Listener listener = (Listener)appContext .getBean("serverListener");
>
>// Problem! it can't find it .... it seams to have loaded the first file again.
>
>// If i use a diferent file name,it works fine.
>
> 
>
>thanks,
>
>Pedro.
>
> 
>

[Springframework-developer] ClassPathXmlApplicationContext issue.

[pedro.costa <ped...@ne...>]

Hi all,
=20
I'm trying to load two different applicationContext xml file using =
ClassPathXmlApplicationContext.
=20
The files have the same name, but are on diferent class paths.
=20
What is happening is that it seams that spring is always finding the =
same file in both cases, regardless of the classpath that is used when =
creating ClassPathXmlApplicationContext.
=20
I can see it from the logs.
=20
If i change the name of one of the files, it works fine.
=20
Is this a known problem?
=20
here is the code:
=20
ClassPathXmlApplicationContext appContext =3D new =
ClassPathXmlApplicationContext("replica/command/beans/beans.xml");

BeansMappings beansMappings =3D =
(BeansMappings)appContext.getBean("serverCommandMappings");

// no problem here ...=20

ClassPathXmlApplicationContext appContext =3D new =
ClassPathXmlApplicationContext("replica/server/beans.xml");

 Listener listener =3D (Listener)appContext .getBean("serverListener");

// Problem! it can't find it .... it seams to have loaded the first file =
again.

// If i use a diferent file name,it works fine.

=20

thanks,

Pedro.

=20
=20
=20

[Springframework-developer] Discussion involving Spring

[Ken K. <kk...@kk...>]

FYI,

There is a good discussion involving Spring going on at JavaRanch.com if 
anyone's interested in participating.

Topic: When to not use EJB
<http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=11&t=006707>

Re: [Springframework-developer] Hibernate Spring and HSQLDB - locking issue

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

Troy,

I don't think you should issue a "SHUTDOWN" while using Hibernate or Spring. 
Let the framework handle the lifecycle of the database connections.  I think
it's a matter of picking the correct datasource configuration to use.  

Are you currently using connection pooling?  That would keep the connection open
and leave the lock file ou there.  Since you are not using a "Server" instance
of HSQL, you are limited to that single connection that will stay open until the
connection pool or Tomcat is shut down.

If you absolutely have to run HSQL in "Standalone" mode then you can't use
connection pooling.  For a Spring configured datasource you should use
"DriverManagerDataSource".

Thomas

Quoting Troy McKinnon <Tro...@ho...>:

> I can't get Hibernate to disconnect from the database once it is connected.
> It creates a HSQLDB.lck file and I have to terminate the Tomcat before I can
> access it again.
> 
> I have tried: (With no luck..)
> 
> 
>   try {
>             Configuration cfg = new
> Configuration().configure("/hibernate-HSQLDB.cfg.xml");
>             SessionFactory sessions = cfg.buildSessionFactory();
>             Long user = new Long(0);
>             AuditInterceptor aii = new AuditInterceptor(user);
>             session = sessions.openSession(aii);
>             sw.start();
>             list = session.find("from " + table + " in class " +
> StringUtils.capitalise(table));
>             // Edited by tmckinnon: 20-Jan-2004 03:56:27 PM PST
>             // trying to get HSQLDB lck to release...
>             if(session != null && session.isOpen()) {
>                 Connection con = session.connection();
>                 Statement st = con.createStatement();
>                 st.execute("SHUTDOWN COMPACT");
>                 con.commit();
>                 st.close();
>                 con.close();
>                 logger.trace("Shut down HSQLDB session!");
>                 session.disconnect();
>                 if(session != null) session.close();
>             }
>              hibernate.push(list.toArray(new Object[list.size()]), clazz);
>         } catch(Exception e) {
>             throw e;
>         } finally {
>             try {
>                 if(session != null && session.isOpen()) {
>                     logger.trace("Closing CSV session!");
>                     session.disconnect();
>                     if(session!=null) session.close();
>                 }
>             } catch(Exception e) {
>                 logger.trace("Error trying to close session");
>                 throw e;
>             }
>         }
> 
> 
> 
> 
> 
> but just get:
> 
> 16:20:06,032  WARN [http8100-Processor4]
> net.sf.hibernate.util.JDBCExceptionReporter:38 - SQL Error: -33, SQLState:
> null
> 16:20:06,032 ERROR [http8100-Processor4]
> net.sf.hibernate.util.JDBCExceptionReporter:46 - Access is denied in
> statement [SHUTDOWN COMPACT]
> 16:20:06,042 ERROR [http8100-Processor4]
> net.sf.hibernate.util.JDBCExceptionReporter:38 - Cannot close connection
> java.sql.SQLException: Access is denied in statement [SHUTDOWN COMPACT]
>  at org.hsqldb.jdbcResultSet.<init>(Unknown Source)
>  at org.hsqldb.jdbcConnection.executeStandalone(Unknown Source)
>  at org.hsqldb.jdbcConnection.execute(Unknown Source)
>  at org.hsqldb.jdbcConnection.rollback(Unknown Source)
>  at
> com.mchange.v2.c3p0.impl.C3P0PooledConnection.reset(C3P0PooledConnection.jav
> a:251)
>  at
> com.mchange.v2.c3p0.impl.C3P0PooledConnection.access$000(C3P0PooledConnectio
> n.java:35)
>  at
> com.mchange.v2.c3p0.impl.C3P0PooledConnection$ProxyConnectionInvocationHandl
> er.doSilentClose(C3P0PooledConnection.java:531)
>  at
> com.mchange.v2.c3p0.impl.C3P0PooledConnection$ProxyConnectionInvocationHandl
> er.invoke(C3P0PooledConnection.java:636)
>  at com.mchange.v2.c3p0.impl.$Proxy0.close(Unknown Source)
>  at
> net.sf.hibernate.connection.C3P0ConnectionProvider.closeConnection(C3P0Conne
> ctionProvider.java:40)
>  at net.sf.hibernate.impl.BatcherImpl.closeConnection(BatcherImpl.java:275)
>  at net.sf.hibernate.impl.SessionImpl.disconnect(SessionImpl.java:3299)
> 
> 
> -------------------------------------------------------
> 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] Hibernate Spring and HSQLDB - locking issue

[Troy M. <Tro...@ho...>]

I can't get Hibernate to disconnect from the database once it is connected.
It creates a HSQLDB.lck file and I have to terminate the Tomcat before I can
access it again.

I have tried: (With no luck..)


  try {
            Configuration cfg = new
Configuration().configure("/hibernate-HSQLDB.cfg.xml");
            SessionFactory sessions = cfg.buildSessionFactory();
            Long user = new Long(0);
            AuditInterceptor aii = new AuditInterceptor(user);
            session = sessions.openSession(aii);
            sw.start();
            list = session.find("from " + table + " in class " +
StringUtils.capitalise(table));
            // Edited by tmckinnon: 20-Jan-2004 03:56:27 PM PST
            // trying to get HSQLDB lck to release...
            if(session != null && session.isOpen()) {
                Connection con = session.connection();
                Statement st = con.createStatement();
                st.execute("SHUTDOWN COMPACT");
                con.commit();
                st.close();
                con.close();
                logger.trace("Shut down HSQLDB session!");
                session.disconnect();
                if(session != null) session.close();
            }
             hibernate.push(list.toArray(new Object[list.size()]), clazz);
        } catch(Exception e) {
            throw e;
        } finally {
            try {
                if(session != null && session.isOpen()) {
                    logger.trace("Closing CSV session!");
                    session.disconnect();
                    if(session!=null) session.close();
                }
            } catch(Exception e) {
                logger.trace("Error trying to close session");
                throw e;
            }
        }





but just get:

16:20:06,032  WARN [http8100-Processor4]
net.sf.hibernate.util.JDBCExceptionReporter:38 - SQL Error: -33, SQLState:
null
16:20:06,032 ERROR [http8100-Processor4]
net.sf.hibernate.util.JDBCExceptionReporter:46 - Access is denied in
statement [SHUTDOWN COMPACT]
16:20:06,042 ERROR [http8100-Processor4]
net.sf.hibernate.util.JDBCExceptionReporter:38 - Cannot close connection
java.sql.SQLException: Access is denied in statement [SHUTDOWN COMPACT]
 at org.hsqldb.jdbcResultSet.<init>(Unknown Source)
 at org.hsqldb.jdbcConnection.executeStandalone(Unknown Source)
 at org.hsqldb.jdbcConnection.execute(Unknown Source)
 at org.hsqldb.jdbcConnection.rollback(Unknown Source)
 at
com.mchange.v2.c3p0.impl.C3P0PooledConnection.reset(C3P0PooledConnection.jav
a:251)
 at
com.mchange.v2.c3p0.impl.C3P0PooledConnection.access$000(C3P0PooledConnectio
n.java:35)
 at
com.mchange.v2.c3p0.impl.C3P0PooledConnection$ProxyConnectionInvocationHandl
er.doSilentClose(C3P0PooledConnection.java:531)
 at
com.mchange.v2.c3p0.impl.C3P0PooledConnection$ProxyConnectionInvocationHandl
er.invoke(C3P0PooledConnection.java:636)
 at com.mchange.v2.c3p0.impl.$Proxy0.close(Unknown Source)
 at
net.sf.hibernate.connection.C3P0ConnectionProvider.closeConnection(C3P0Conne
ctionProvider.java:40)
 at net.sf.hibernate.impl.BatcherImpl.closeConnection(BatcherImpl.java:275)
 at net.sf.hibernate.impl.SessionImpl.disconnect(SessionImpl.java:3299)

Re: [Springframework-developer] HSQLDB.lck file issues when using Spring Framework

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

Troy,

Are you using the "DriverManagerDataSource"?  If not try using it or post your
DataSource configuration.

Thomas


Quoting Troy McKinnon <Tro...@ho...>:

> Note: I posted this to springframework forum as well since it is applicable
> to both.
> 
> The springframework is an open source IoC MVC framework. It also allows you
> to incorportate Hibernate framework, easily, for the model side of things.
> 
> http://www.springframework.org/docs/reference/index.html
> 
> As far as my question below.  I am not familiar with the SHUTDOWN. How would
> I do that?
> 
> But as far as with the Spring Framework.  I don't really have control of that
> as far as I know.  The framework is locking the database at server startup,
> because I have HSQLDB datasource in my application-context.xml.
> 
>   ----- Original Message ----- 
>   From: fredt 
>   To: Troy McKinnon ; hsq...@li... 
>   Sent: Tuesday, January 20, 2004 3:31 PM
>   Subject: Re: [Hsqldb-developers] HSQLDB.lck file issues
> 
> 
>   As far as HSQLDB is concerned, an in-process or server instance that opens
> a database, creates the *.lck file and does not release it until the SHUTDOWN
> command has been issued on the database. You should aim at incorporating the
> SHUTDOWN into your framework when you no longer need the connection to that
> particular database.
> 
>   If you are using SHUTDOWN and it does not release the *.lck then please let
> us know. I don't know about the Sprint framework (reference please).
> 
>   Please subscribe to the hsqldb-developers if you want to post messages
> here.
> 
>   Fred
> 
> 
>     ----- Original Message ----- 
>     From: Troy McKinnon 
>     To: fredt ; hsq...@li... 
>     Sent: 20 January 2004 23:11
>     Subject: Re: [Hsqldb-developers] HSQLDB.lck file issues
> 
> 
>     My issue is basically this...
> 
>     I am using the FILE version of HSQLDB to access CVS files so I can import
> them into my (Oracle /or/ Postgres) database.
> 
>     I manually create these files with one process and using the HSQL driver
> and Hibernate to access the data and take care of all the Dirty Work for me.
> 
>     Works very well stand alone.  But when I tried to incorporate it into my
> Tomcat/Spring/Hibernate framework, it just locks up (HSQLDB.lck).
> 
>     I discovered this is because I created a HSQLHibernateSessionFactory bean
> using the HSQLDataSource in my application-context.xml.
> 
>     On startup Spring must load these and lock them. It doesn't release them
> again until tomcat is terminated.
> 
>     I removed the references from my application-context.xml and used a
> straight forward hibernate-HSQLDB.cfg.xml file configuration.  Basically
> skipped spring all together.. and it works fine.
> 
>     I would like to utilize the spring framework.. is there a better way to
> do this?  I don't want to run SERVER mode on HSQL since they are basically
> only temporary import and export files.
> 
> 
>     What would you suggest?
> 
>     Cheers
> 
>     Troy
> 
> 
>       ----- Original Message ----- 
>       From: fredt 
>       To: Troy McKinnon ; hsq...@li... 
>       Cc: Troy McKinnon 
>       Sent: Tuesday, January 20, 2004 3:02 PM
>       Subject: Re: [Hsqldb-developers] HSQLDB.lck file issues
> 
> 
>       The .lck file prevents two processes from simultaneously opening the
> database file. It stays there until you shutdown the database.  If it is
> causing a problem, please state what it is.
> 
>       Fred
>         ----- Original Message ----- 
>         From: Troy McKinnon 
>         To: hsq...@li... 
>         Cc: Troy McKinnon 
>         Sent: 20 January 2004 22:12
>         Subject: [Hsqldb-developers] HSQLDB.lck file issues
> 
> 
>         I am having trouble using HSQLDB using CSV type files.  Running it in
> tomcat using Hibernate... as soon as the context starts up the lock file
> appears and it doesn't ever go away.  What exactly creates the lck file and
> how can I get by it?
> 
>         Troy
> 
> 

Re: [Springframework-developer] Weird (?) behavior when using MethodInvokingFactoryBean

[Christophe V. <c.v...@pa...>]

On Tuesday 20 January 2004 23:11, Colin Sampaleanu wrote:
> These are lifecycle methods which apply to beans created by the
> container (spring) itself. If the container is not actually creating an
> object, then it can't and shouldn't call lifecycle methods on it.
>
> All that MethodInvokingFactoryBean is doing is calling a method on
> another bean, but in this case it has nothing to do with the fact that
> that method is then creating a new object. So with w/regards to the
> test.Thingy class, it is only created via a 'new Thingy'()' call in
> ThingyCreater, and you can not expect that any lifecycle methods will be
> called on it by Spring.
>
Thanks, that makes lots of sense.
The reason I wanted to be able to do this is the following:

I have an object, that is actually a loaded hibernate instance (and the only 
instance of its class). It is needed in many places in my application 
(actions, tablemodels, ... ; this is a standalone swing app), as it is the 
central object that holds all the data that will be manipulated and is in 
memory all the time.

I now load this instance via a call on a Hibernate DAO class using the 
MethodFactoryBean, and give references to it for anything that needs it 
(practically every panel, action, ...). So far so good.

It would have been handy to let this object handle certain ApplicationEvents, 
which is why I implemented this interface, but I now know that this won't 
work. (As a sidenote, ApplicationListener is very handy in swing apps, you 
can create very loose coupled components, without the need to create and 
register all sorts of custom Listeners, and it doesn't give any significant 
performance drawbacks because there are so few ApplicationListeners.)

I suppose I could register an instance of another class, also let it implement 
ApplicationListener, and then let it the delegate the events to the hibernate 
instance, but now I'm wondering if there is a more direct way to do this 
(maybe by somehow making the hibernated object a "real" spring object).

-- 
Kind regards,
Christophe Vanfleteren

[Springframework-developer] HSQLDB.lck file issues when using Spring Framework

[Troy M. <Tro...@ho...>]

Note: I posted this to springframework forum as well since it is =
applicable to both.

The springframework is an open source IoC MVC framework. It also allows =
you to incorportate Hibernate framework, easily, for the model side of =
things.

http://www.springframework.org/docs/reference/index.html

As far as my question below.  I am not familiar with the SHUTDOWN. How =
would I do that?

But as far as with the Spring Framework.  I don't really have control of =
that as far as I know.  The framework is locking the database at server =
startup, because I have HSQLDB datasource in my application-context.xml.

  ----- Original Message -----=20
  From: fredt=20
  To: Troy McKinnon ; hsq...@li...=20
  Sent: Tuesday, January 20, 2004 3:31 PM
  Subject: Re: [Hsqldb-developers] HSQLDB.lck file issues


  As far as HSQLDB is concerned, an in-process or server instance that =
opens a database, creates the *.lck file and does not release it until =
the SHUTDOWN command has been issued on the database. You should aim at =
incorporating the SHUTDOWN into your framework when you no longer need =
the connection to that particular database.

  If you are using SHUTDOWN and it does not release the *.lck then =
please let us know. I don't know about the Sprint framework (reference =
please).

  Please subscribe to the hsqldb-developers if you want to post messages =
here.

  Fred


    ----- Original Message -----=20
    From: Troy McKinnon=20
    To: fredt ; hsq...@li...=20
    Sent: 20 January 2004 23:11
    Subject: Re: [Hsqldb-developers] HSQLDB.lck file issues


    My issue is basically this...

    I am using the FILE version of HSQLDB to access CVS files so I can =
import them into my (Oracle /or/ Postgres) database.

    I manually create these files with one process and using the HSQL =
driver and Hibernate to access the data and take care of all the Dirty =
Work for me.

    Works very well stand alone.  But when I tried to incorporate it =
into my Tomcat/Spring/Hibernate framework, it just locks up =
(HSQLDB.lck).

    I discovered this is because I created a HSQLHibernateSessionFactory =
bean using the HSQLDataSource in my application-context.xml.

    On startup Spring must load these and lock them. It doesn't release =
them again until tomcat is terminated.

    I removed the references from my application-context.xml and used a =
straight forward hibernate-HSQLDB.cfg.xml file configuration.  Basically =
skipped spring all together.. and it works fine.

    I would like to utilize the spring framework.. is there a better way =
to do this?  I don't want to run SERVER mode on HSQL since they are =
basically only temporary import and export files.


    What would you suggest?

    Cheers

    Troy


      ----- Original Message -----=20
      From: fredt=20
      To: Troy McKinnon ; hsq...@li...=20
      Cc: Troy McKinnon=20
      Sent: Tuesday, January 20, 2004 3:02 PM
      Subject: Re: [Hsqldb-developers] HSQLDB.lck file issues


      The .lck file prevents two processes from simultaneously opening =
the database file. It stays there until you shutdown the database.  If =
it is causing a problem, please state what it is.

      Fred
        ----- Original Message -----=20
        From: Troy McKinnon=20
        To: hsq...@li...=20
        Cc: Troy McKinnon=20
        Sent: 20 January 2004 22:12
        Subject: [Hsqldb-developers] HSQLDB.lck file issues


        I am having trouble using HSQLDB using CSV type files.  Running =
it in tomcat using Hibernate... as soon as the context starts up the =
lock file appears and it doesn't ever go away.  What exactly creates the =
lck file and how can I get by it?

        Troy

Re: [Springframework-developer] Weird (?) behavior when using MethodInvokingFactoryBean

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

These are lifecycle methods which apply to beans created by the 
container (spring) itself. If the container is not actually creating an 
object, then it can't and shouldn't call lifecycle methods on it.

All that MethodInvokingFactoryBean is doing is calling a method on 
another bean, but in this case it has nothing to do with the fact that 
that method is then creating a new object. So with w/regards to the 
test.Thingy class, it is only created via a 'new Thingy'()' call in 
ThingyCreater, and you can not expect that any lifecycle methods will be 
called on it by Spring.

Regards,
Colin

Christophe Vanfleteren wrote:

>Hello,
>
>I'm using MethodInvokingFactoryBean to retrieve an instance of an class using 
>another instance of another class. If I implement InitializingBean, the 
>afterPropertiesSet method never gets called. 
>But that is not only the case with InitializingBean, it shows the same 
>behaviour when implementing ApplicationListenener, OnApplicationEvent  never 
>seems to get called.
>
>Is this normal behaviour?
>
>I checked the bug system for something on MethodInvokingFactoryBean, but I 
>couldn't find anything. Should I file a bug about this?
>
>If this is normal behavior, what is the correct way to achieve what I need (an 
>object instantiated outside of the beanfactory, but that still will be able 
>to implement Spring specific interfaces and expect them to work.
>
>Here is a small test setup:
>
>---test/testThingy.xml---
><beans>
>    <bean id="thingyCreator" class="test.ThingyCreator" singleton="true"/>
>    <bean id="thingy" 
>class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
>        <property name="target"><ref local="thingyCreator"/></property>
>        <property name="targetMethod"><value>getThingy</value></property>
>    </bean>
>    
>    <bean id="otherThingy" class="test.OtherThingy" />
></beans>
>
>---test.ThingyCreator----
>package test;
>public class ThingyCreator {
>    private Thingy thingy = new Thingy();
> 
>   public Thingy getThingy() {
>        return this.thingy;
>    }
>}
>
>---test.Thingy---
>package test;
>
>public class Thingy implements 
>org.springframework.beans.factory.InitializingBean {
>    
>    public Thingy() {
>        System.err.println("thingy constructor");
>    }    
>    public void afterPropertiesSet() throws Exception {
>        System.err.println("Thingy: I never get called");
>    }     
>}
>
>---test.OtherThingy---
>package test;
>
>public class OtherThingy implements 
>org.springframework.beans.factory.InitializingBean {
>  
>    public OtherThingy() {
>        System.err.println("OtherThingy constructor");
>    }   
>    public void afterPropertiesSet() throws Exception {
>        System.err.println("OtherThingy: I get called");
>    } 
>}
>
>---test.Main---
>package test;
>import org.springframework.context.ApplicationContext;
>import org.springframework.context.support.ClassPathXmlApplicationContext;
>public class Main {
>    
>    public static void main(String[] args) throws Exception {
>        ApplicationContext context = new 
>ClassPathXmlApplicationContext("/test/testThingy.xml");
>        //prints "I get called"
>        OtherThingy ot = (OtherThingy)context.getBean("otherThingy");
>        //doens't print anything, but I think it should
>        Thingy t = (Thingy)context.getBean("thingy");
>    }
>}
>
>  
>

[Springframework-developer] Weird (?) behavior when using MethodInvokingFactoryBean

[Christophe V. <c.v...@pa...>]

Hello,

I'm using MethodInvokingFactoryBean to retrieve an instance of an class using 
another instance of another class. If I implement InitializingBean, the 
afterPropertiesSet method never gets called. 
But that is not only the case with InitializingBean, it shows the same 
behaviour when implementing ApplicationListenener, OnApplicationEvent  never 
seems to get called.

Is this normal behaviour?

I checked the bug system for something on MethodInvokingFactoryBean, but I 
couldn't find anything. Should I file a bug about this?

If this is normal behavior, what is the correct way to achieve what I need (an 
object instantiated outside of the beanfactory, but that still will be able 
to implement Spring specific interfaces and expect them to work.

Here is a small test setup:

---test/testThingy.xml---
<beans>
    <bean id="thingyCreator" class="test.ThingyCreator" singleton="true"/>
    <bean id="thingy" 
class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
        <property name="target"><ref local="thingyCreator"/></property>
        <property name="targetMethod"><value>getThingy</value></property>
    </bean>
    
    <bean id="otherThingy" class="test.OtherThingy" />
</beans>

---test.ThingyCreator----
package test;
public class ThingyCreator {
    private Thingy thingy = new Thingy();
 
   public Thingy getThingy() {
        return this.thingy;
    }
}

---test.Thingy---
package test;

public class Thingy implements 
org.springframework.beans.factory.InitializingBean {
    
    public Thingy() {
        System.err.println("thingy constructor");
    }    
    public void afterPropertiesSet() throws Exception {
        System.err.println("Thingy: I never get called");
    }     
}

---test.OtherThingy---
package test;

public class OtherThingy implements 
org.springframework.beans.factory.InitializingBean {
  
    public OtherThingy() {
        System.err.println("OtherThingy constructor");
    }   
    public void afterPropertiesSet() throws Exception {
        System.err.println("OtherThingy: I get called");
    } 
}

---test.Main---
package test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class Main {
    
    public static void main(String[] args) throws Exception {
        ApplicationContext context = new 
ClassPathXmlApplicationContext("/test/testThingy.xml");
        //prints "I get called"
        OtherThingy ot = (OtherThingy)context.getBean("otherThingy");
        //doens't print anything, but I think it should
        Thingy t = (Thingy)context.getBean("thingy");
    }
}

-- 
Kind regards,
Christophe Vanfleteren

[Springframework-developer] Spring supported in Mule

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

Just took a look at a project called Mule, which appears to try to 
provide 'Enterprise Service Bus' functionality. It has built-in support 
for Spring as a component source/container...
  http://www.muleumo.org/index.html
  http://www.muleumo.org/architectureGuide.html

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

[Lars F. <lar...@gm...>]

It means that it is only certified for Red Hat. I´m running WLS
on SuSE Linux without problems.

> -----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-----
> 
> 
> 
> -------------------------------------------------------
> 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] (no subject)

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

Everyone,

how about getting rid of "grant all to public" schema in JPetstore's oracle schema script and creating a separate schema, let's say 'jpet'?

Regards,
Dmitriy.

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

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

Colin,

Point taken regarding making clear that it's about a reference to beans =
- but the same also applies to the general "ref" tag. My main concern is =
consistency across the current tags in the spring-beans DTD: That's why =
I consider "idref" the best name in addition to the existing "ref".

Don't bother with these changes: I've already tried the new name on my =
machine, and can commit the change as soon as the SourceForge CVS server =
works again (can't reach it currently). I've also already removed the =
"external" support.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Monday, January 19, 2004 2:21 PM
To: spr...@li...
Subject: Re: [Springframework-developer] xml dtd addition for bean id
reference


I'm totally ok with calling the element 'idref'. My original intent with =

'beanid' was to make it clear that it referred to bean ids, not to ids=20
of elements in general, since at some point Spring itself will hopefully =

validate that it matches real bean ids. I think if it's documented=20
that's fine; beans are after the most important element in the =
documents...

I am also ok with removing the deprecated external tag.

If I don't hear anything in a few hours I'll make these changes.



j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>=20
>That's a good new feature! However, I'm not entirely happy with the =
name "beanid", as it misses the referential aspect - it sounds more like =
you're defining a bean ID itself there. The original tag was "ref", and =
I think we should build on that name: so what about "idref", as it's =
about a reference to an id (instead of a full object)? I've already =
tried this locally on my machine, to check whether the name was reserved =
or anything.
>=20
>  <ref bean=3D"...">
>  <idref bean=3D"...">
>=20
>Both would refer to a bean, but the former to the bean object, the =
latter just to a bean ID. I think it's better than "refid", which would =
suggest the ID *of* a reference rather than a reference *to* and ID. =
What do you think? I'm of course open for any other suggestions.
>=20
>BTW, I'd also like to remove the deprecated <ref external=3D"..."> as =
of RC1, to just keep <ref local=3D"..."> and <ref bean=3D"...">. We've =
announced that quite a while ago and have not been using it in any =
examples. And after all, migration is easy: simply rename "ref external" =
to "ref bean", and you're done.
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>Gesendet: Sa 17.01.2004 18:10
>An: spr...@li...; =
spr...@li...
>Betreff: [Springframework-developer] xml dtd addition for bean id =
reference
>
>
>
>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=3D"interceptorNames">
>     <list>
>       <value>hibInterceptor</value>
>       <value>matchAllTxInterceptor</value>
>     </list>
>   </property>
>
>can now become
>
>   <property name=3D"interceptorNames">
>     <list>
>       <beanid local=3D"hibInterceptor"/>
>       <beanid local=3D"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:
>
> =20
>
>>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
>>
>>
>>
>>
>>   =20
>>
>>>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:
>>>
>>> =20
>>>
>>>     =20
>>>
>>>>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:
>>>>
>>>>   =20
>>>>
>>>>       =20
>>>>
>>>>>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
>>>>>     =20
>>>>>
>>>>>         =20
>>>>>
>>usage,
>>
>>
>>   =20
>>
>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     =20
>>>>>
>>>>>         =20
>>>>>
>>>>>>The recent switch in AbstractAutoProxyCreate which forced me to =
switch
>>>>>>some BeanNameAutoProxyCreator configs from something like
>>>>>>...
>>>>>>   <property name=3D"interceptorNames">
>>>>>>    <list>
>>>>>>      <ref bean=3D"hibInterceptor"/>
>>>>>>      <ref bean=3D"matchAllTxInterceptor</ref>
>>>>>>    </list>
>>>>>>  </property>
>>>>>>...
>>>>>>
>>>>>>to
>>>>>>...
>>>>>>  <property name=3D"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=3D"xxx" />
>>>>>>the xml processor can do it, while
>>>>>> <ref bean=3D"xxx" />
>>>>>>can be validate by the loader or something like an Eclipse plugin. =
But
>>>>>>
>>>>>>  <property name=3D"interceptorNames">
>>>>>>    <list>
>>>>>>      <value>something</value>
>>>>>>    </list>
>>>>>>  </property>
>>>>>>
>>>>>>can only be validate by the user of that property.  So how about =
we
>>>>>>       =20
>>>>>>
>>>>>>           =20
>>>>>>
>>add
>>
>>
>>   =20
>>
>>>>>>another element which is used to produce a text value which is a =
bean
>>>>>>id. That is:
>>>>>>  <property name=3D"interceptorNames">
>>>>>>    <list>
>>>>>>      <beanid bean=3D"a-local-or-external-bean"/>
>>>>>>      <beanid local=3D"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
>>>>>>           =20
>>>>>>




-------------------------------------------------------
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'm totally ok with calling the element 'idref'. My original intent with 
'beanid' was to make it clear that it referred to bean ids, not to ids 
of elements in general, since at some point Spring itself will hopefully 
validate that it matches real bean ids. I think if it's documented 
that's fine; beans are after the most important element in the documents...

I am also ok with removing the deprecated external tag.

If I don't hear anything in a few hours I'll make these changes.



jürgen höller [werk3AT] wrote:

>Colin,
> 
>That's a good new feature! However, I'm not entirely happy with the name "beanid", as it misses the referential aspect - it sounds more like you're defining a bean ID itself there. The original tag was "ref", and I think we should build on that name: so what about "idref", as it's about a reference to an id (instead of a full object)? I've already tried this locally on my machine, to check whether the name was reserved or anything.
> 
>  <ref bean="...">
>  <idref bean="...">
> 
>Both would refer to a bean, but the former to the bean object, the latter just to a bean ID. I think it's better than "refid", which would suggest the ID *of* a reference rather than a reference *to* and ID. What do you think? I'm of course open for any other suggestions.
> 
>BTW, I'd also like to remove the deprecated <ref external="..."> as of RC1, to just keep <ref local="..."> and <ref bean="...">. We've announced that quite a while ago and have not been using it in any examples. And after all, migration is easy: simply rename "ref external" to "ref bean", and you're done.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Sa 17.01.2004 18:10
>An: spr...@li...; spr...@li...
>Betreff: [Springframework-developer] xml dtd addition for bean id reference
>
>
>
>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

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

Colin,
=20
That's a good new feature! However, I'm not entirely happy with the name =
"beanid", as it misses the referential aspect - it sounds more like =
you're defining a bean ID itself there. The original tag was "ref", and =
I think we should build on that name: so what about "idref", as it's =
about a reference to an id (instead of a full object)? I've already =
tried this locally on my machine, to check whether the name was reserved =
or anything.
=20
  <ref bean=3D"...">
  <idref bean=3D"...">
=20
Both would refer to a bean, but the former to the bean object, the =
latter just to a bean ID. I think it's better than "refid", which would =
suggest the ID *of* a reference rather than a reference *to* and ID. =
What do you think? I'm of course open for any other suggestions.
=20
BTW, I'd also like to remove the deprecated <ref external=3D"..."> as of =
RC1, to just keep <ref local=3D"..."> and <ref bean=3D"...">. We've =
announced that quite a while ago and have not been using it in any =
examples. And after all, migration is easy: simply rename "ref external" =
to "ref bean", and you're done.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Sa 17.01.2004 18:10
An: spr...@li...; =
spr...@li...
Betreff: [Springframework-developer] xml dtd addition for bean id =
reference



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=3D"interceptorNames">
     <list>
       <value>hibInterceptor</value>
       <value>matchAllTxInterceptor</value>
     </list>
   </property>

can now become

   <property name=3D"interceptorNames">
     <list>
       <beanid local=3D"hibInterceptor"/>
       <beanid local=3D"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
>
>
>=20
>
>>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:
>>
>>  =20
>>
>>>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:
>>>
>>>    =20
>>>
>>>>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
>>>>      =20
>>>>
>usage,
>=20
>
>>>>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
>>>>
>>>>
>>>>
>>>>
>>>>      =20
>>>>
>>>>>The recent switch in AbstractAutoProxyCreate which forced me to =
switch
>>>>>some BeanNameAutoProxyCreator configs from something like
>>>>>...
>>>>>    <property name=3D"interceptorNames">
>>>>>     <list>
>>>>>       <ref bean=3D"hibInterceptor"/>
>>>>>       <ref bean=3D"matchAllTxInterceptor</ref>
>>>>>     </list>
>>>>>   </property>
>>>>>...
>>>>>
>>>>>to
>>>>>...
>>>>>   <property name=3D"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=3D"xxx" />
>>>>>the xml processor can do it, while
>>>>>  <ref bean=3D"xxx" />
>>>>>can be validate by the loader or something like an Eclipse plugin. =
But
>>>>>
>>>>>   <property name=3D"interceptorNames">
>>>>>     <list>
>>>>>       <value>something</value>
>>>>>     </list>
>>>>>   </property>
>>>>>
>>>>>can only be validate by the user of that property.  So how about we
>>>>>        =20
>>>>>
>add
>=20
>
>>>>>another element which is used to produce a text value which is a =
bean
>>>>>id. That is:
>>>>>   <property name=3D"interceptorNames">
>>>>>     <list>
>>>>>       <beanid bean=3D"a-local-or-external-bean"/>
>>>>>       <beanid local=3D"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
>>>>>        =20
>>>>>





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