springframework-developer — Spring Framework developers list

Re: [Springframework-developer] JavaBeans lifecycle considerations?

[Ivan R. <iv...@we...>]

> Yes, contribution is very welcome. Please note that this is 
> definitely something for the 1.1 release, not 1.0.

   Not a problem. I am not in a hurry, i.e. I don't have a
   project with a deadline. I can also implement changes on
   a separate branch and merge them later.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] JavaBeans lifecycle considerations?

[Ivan R. <iv...@we...>]

> You are very welcome to join us and work on this! Rod and
 > me will be happy to provide you with details on the current
> bean factory and application context concepts :-)

   That is great to hear. I've spent some time today playing
   with the framework to get a feel of what's possible. Here
   are my notes.

   There are many ideas/features mentioned here but not all
   are equally important. Personally I would start simply
   but adding the equivalent to start/stop/dispose methods
   as they will benefit the majority of those building standalone
   applications. Other features are nice, but not
   essential.

   ...


Some background
---------------

I've spent the last year or so dealing with a Java daemon
application (a RADIUS server). As part of that project I've
built a framework similar to what I describe below, but not as
fancy. Well, I couldn't really call that a framework since
there wasn't much time to design it upfront, but it works
and it works well. This server consists of many components
that are configured and wired at runtime from an XML-based
configuration, just like the Spring framework.

That was for work. After completing the project I decided to
rebuild the framework from scratch for fun, so here I am.


Requirements
------------

* Complete bean life cycle: parameters, initialisation,
   start, stop, suspend, resume, reconfigure, dispose/destroy.

* Beans that want to can execute on their own thread

* Singleton/shared and not-shared beans

* Ability to safely reconfigure a bean that is referenced
   by other beans

* Load/unload beans

* Bean pools (check-in, check-out)

* Reload bean class (in combination with bean pools this
   probably means that multiple bean versions will run
   in parallel at times)

* Persist bean configuration (not serialization,
   properties only).


Notes
-----

At the moment Spring supports parameterization and initialization
(with the InitializingBean interface). It would be simple
to add one or more interfaces to support methods such
as: start, stop, dispose/destroy (other names can be chosen
to avoid clash with the Thread class).

As an idea, beans implementing the Runnable interface could
be launched as daemon threads. I am more against than for
this idea (but you may think otherwise).

I have also considered detecting a "main" method on an object
and invoking it, simulating a command line. I am more against
than for this idea (but you may think otherwise).

We could have suspend/resume, or we can simply use start/stop
for that purpose. I am not really sure. I lean toward using
a single pair of methods, start and stop.

Reconfiguring a bean is a bit more complicated. I was
thinking about using proxies to intercept method invocations,
wait until all method executions are completed, reconfigure
the bean, and then resume. We would probably need to call
stop/suspend before and start/resume after. The process
with loading/unloading would be similar.

Spring also supports singleton and not-shared beans at the
moment. There is a space in between to support bean pools.
I don't think that this can be supported transparently, there
would have to exist a check in/checkout process. For example,
a client bean would receive a reference to a bean pool
and ask it for bean instances when required.

When reconfiguring bean pools, there could be an option whether
to only create new beans with new configuration (possibly removing
all idle beans immediately) and let busy beans finish with their
work, or reconfigure all bean instances.

Finally, a container needs to be written which would allow
access to all beans and their configuration from the outside,
plus options to load/unload beans, reconfigure them, inspect
them and so on. On a related note, I have also started work on
a utility scripts that would allow tight integration of Java
daemons with UNIX and Windows operating systems.

Links
-----

Some links to similar projects. I would say that they
are all far more complicated than I would want.

http://avalon.apache.org/framework/
http://www.picocontainer.org/
http://jakarta.apache.org/commons/sandbox/hivemind/

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[Springframework-developer] Tags using expression language?? & Petclinic

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

Eliminating repetitive code in the jsp's is something I'd very much like 
to see. Alef: thanks for your contribution, it looks like it will help.

I've been in the process lately of  refactoring Petclinic's Clinic 
implementation along with code tightening and documentation improvements 
and am just about ready to commit the changes. I WILL commit these 
changes sometime later today. A couple of jsp's have minor changes.

Alef: If you would like to make the changes to the jsp's, please go 
ahead. If not, I'll do it. Please let me know if you will be doing it.

Regards,
Ken
 
jürgen höller [werk3AT] wrote:

>I've introduced support for EL on tag attributes yesterday, already committed. Thanks for the idea and the prototype, Alef! I hope you are satisfied with the integration. You're very welcome to try it out :-)
> 
>There's a new ExpressionEvaluationsUtils class now in com.interface21.web.util, taking a String argument value and parsing it to Object, String, int, or boolean. It will just attempt EL evaluation if the value starts with "${", else it will simply parse the value with standard means.
> 
>All of Spring's tags use this class now for all attributes, simply delegating to the respective ExpressionEvaluationsUtils method in each setter. This means that all attributes still accept normal String values as before (like <i21:bind path="person.name">), but also EL expressions (like <i21:bind path="${bindPath}">).
> 
>For EL evaluation, ExpressionEvaluationsUtils depends on Jakarta's JSTL implementation (standard.jar). It doesn't have a runtime dependency if just parsing normal String values though, as it delegates EL evaluation to an inner class that will just get loaded in case of actual EL expressions. So you'll just need the Jakarta JSTL implementation in your classpath if you actually use EL attribute values on tags.
> 
>BTW, our AopProxy uses a similar mechanism to avoid a runtime dependency on CGLIB. If just proxying interfaces, it will use standard J2SE proxies. Only if you try to proxy a class itself, it will invoke CGLIB by delegating to a respective inner class.
> 
>Finally, we should adapt PetClinic to use EL expressions on its bind tags. Alef has already shown the way in the prototype that he sent. Ken, what do you think? Would you like Alef to do this?
> 
>Juergen
> 
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: jürgen höller [werk3AT] 
>	Gesendet: Fr 11.07.2003 08:13 
>	An: al...@jt...; spr...@li... 
>	Cc: 
>	Betreff: Re: [Springframework-developer] Tags using expression language??
>	
>	
>
>	Alef,
>	
>	I've just browsed your code - this looks very interesting! It makes iterating such repetitive form fields like in the petclinic much easier. I'll have a look at the implementation details, and if everything works out I'll add a clean room version to the main source tree promptly.
>	
>	I wonder if we could make that work with any JSTL implementation, not just the Jakarta one, although I wouldn't mind a dependency on the latter for this feature.
>	
>	Cool stuff :-)
>	
>	Juergen
>	
>	
>	
>	        -----Ursprüngliche Nachricht-----
>	        Von: Alef Arendsen [mailto:al...@jt...]
>	        Gesendet: Di 08.07.2003 19:43
>	        An: jürgen höller [werk3AT]; spr...@li...
>	        Cc:
>	        Betreff: RE: [Springframework-developer] Tags using expression language??
>	       
>	       
>	
>	        Ok, here we go...
>	       
>	        Like you said, at first glance, it does not look like the i21:bind tag
>	        needs expressionalization (hmmm, nice huh ;-). However, in the petclinic
>	        demo app I'm seeing a lot of input.jsps in the jsp/fields directory.
>	        These are things I'm hoping to solve using for instance EL-based tags...
>	        Attached you'll find a reworked version of the ownerForm. It does not
>	        use the JSPs from the fields directory anymore, but uses only one
>	        input.jsp that uses the bindstatus object to create the input field.
>	       
>	        Ok, it's still all rough and reworking the tags is a little bit more
>	        work than the 15 minutes I spent on it now, but maybe you're getting the
>	        idea.
>	       
>	        Consequences for adding / reworking the tags:
>	       
>	        1. dependency on jakarta-jstl-1.0.3 (jakarta.apache.org/taglib -->
>	        standard).
>	        2. dependency on jstl-1.0.3 (java.sun.com)
>	        3. In case you want to have both version in there, an extending class
>	        for each tag
>	        4. For each tag, a BeanInfo class
>	        5. I wasn't able to use the EvalHelper from jakarta, so I copied it
>	        (hmmm... not so nice, is it ;-)
>	       
>	        Probably I don't have time this week or something to refactor them to be
>	        all EL-based... Just let me know if you'd like it.
>	       
>	        Well, that's it for now, still discovering really cool features and
>	        already running out (brain)memory to think up everything I could do with
>	        Spring ;-)
>	       
>	        Cheers,
>	       
>	        Alef
>	       
>	
>	NHS^隊[){([jJ뢺kyƮ^اj+x:0Zuڕg*)jw`z֟盢0
>	Z(~(W(}iT)~{
>	+ׯzZ)zXX*kxŠuޖ^X(~zwilqzlX)ߣ))~{
>	+ׯzZ) 
>
>?????????????????????????????????????????ӆ+?^?隊[)?{(??[??ڭ?(~?+??鮊Y?ڦ??j?h??^??-?x?????:0?Zw?jU?l????݁?Z~??n?$?0???j???(???W???(}?i?_???????????????????????????????????*k?x???Š??ׯzZ)z???X??X??*k?x???Š??ׯzZ)z???l??.?ǟ???w???i????+-??(??~??{?޷?b????+-?w???k?x???Š??ׯzZ)
>
>
>  
>

Re: [Springframework-developer] Re: [Springframework-developer] Locale in rowmap?

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

Jean-Pierre,

It's definitely best to avoid adding instance variables or 
synchronization into what should be a threadsafe, reusable query object.

Won't the following do the trick ? I thought this is exactly what 
MappingSqlQueryWithParameters is for. Am I missing something ?

// in SpringQuery client class
Object[] params = new Object[] {
    userLocale,
    // more param objects
}
springQuery.execute(params);
// etc...

public class SpringQuery extends MappingSqlQueryWithParameters {

  public SpringQuery(DataSource ds) {
    super(ds, "select col1, col2 from table");
    compile();		
  }

  protected Object mapRow(ResultSet rs, int rownum, Object[] params) throws SQLException {
	Locale userLocale = (Locale) params[0];
    	if (userLocale.equals("xxx")) { 
		...
	}
    	...
  }

}


Regards,
Ken



jp....@ti... wrote:

>Hello Thomas,
>
>This is very close to what I made until a few days. What is wrong in this?
>
>If two users request the same and have different contexts (ie Locales), the last will change on the road the context to use for the first. For avoiding this, I used a "run" method setting the context like in your exeample and calling the "execute method. The "run" method being "synchronized".
>In this manner, it works. But I would eliminate the need of synchronizing due to performance reasons and for clarity. The context lifecycle is really tied to the execute method and setting it as an Instance variable is a workaround threadsafe only with synchronizing.
>
>As long as no consensus will be, I simply will use the three changed classes in a private package. They don't break any backward compatibility, so I will use them instead of standard ones. The problem is only that I will have to check from time to time if the original have not changed. Secondly, I guess it's not a common need but nevertheless a general one and early or later, passing so contextual information will be requested by developers.
>
>Jean-Pierre
>
>---------- Initial Header -----------
>
>>From      : tri...@tr...
>To          : "jp....@ti..." <jp....@ti...>
>Cc          : "jp.pawlak" <jp....@ti...>, "rod.johnson" <rod...@in...>, kk <kk...@kk...>, springframework-developer <spr...@li...>
>Date      : Sat, 12 Jul 2003 10:49:56 -0400
>Subject : Re: Re:[Springframework-developer] Re: [Springframework-developer] Locale in rowmap?
>
>Jean-Pierre,
>
>Could you not do this without modifying the JDBC layer?  Maybe declare a
>UserContext in the custom class and set that via a bean setter.
>
>Something like:
>
>public class SpringQuery extends MappingSqlQuery {
>
>  private UserContext userContext;
>
>  public SpringQuery(DataSource ds) {
>    super(ds, "select col1, col2 from table");
>    compile();		
>  }
>
>  protected Object mapRow(ResultSet rs, int rownum) throws SQLException {
>    ....
>    if (userContext.getLocale().equals("xxx")) 
>        ....
>    ....
>  }
>
>  public setUserContext(UserContext uc) {
>    userContext = uc;
>  }
>
>}
>
>
>Thomas
>
>  
>
>>What I used also in the past is letting the DAO create a 'data-layer' list
>>and after that in business layer, iterate the list to replace data-layer
>>elements by business-layer ones knowing the contextual information.
>>
>>This is certainly a better school-approach, but has clearly a performance
>>drawback.
>>
>>Letting rowmap being able to create definitive objects (indeed having a user
>>defined contextual info), seems to me, for now, a better solution.
>>
>>Jean-Pierre 
>>
>>---------- Initial Header -----------
>>
>>From      : spr...@li...
>>To          : "rod.johnson" <rod...@in...>
>>Cc          : "trisberg" <tri...@tr...>,"kk"
>><kk...@kk...>,"springframework-developer"
>><spr...@li...>
>>Date      : Sat, 12 Jul 2003 12:05:19 +0200
>>Subject : [Springframework-developer] Re: [Springframework-developer] Locale
>>in rowmap?
>>
>>Hi Ken, Thomas, Rod,
>>
>>It seems be a general miscomprehension.
>>
>>1) I have no intend to put any dependency between WEB and JDBC.
>>My request is only at being able to add an optional 'Object' supplemental
>>attribute in execute method. The intend of this attribute is simply to be
>>passed on rowmap.
>>
>>2) Why cannot this object be passed simply on the current methods?
>>Just because JDBC has nothing to do with. It is only for rowmap method as
>>this method is responsible for creating (business) objects.
>>
>>3) Typical example: 
>>Searching adresses. 
>>
>>a)Consider the searched adresses are not localized on the database and
>>contain a country information.
>>
>>b)The database contain only the country code of the address.
>>
>>c)With this country code is read from the database, the rowmap method will
>>have to create a Country Object to put in the Address one. This Country
>>object will have a name property matching with the current user to serve and
>>has nothing to do with the JDBC record.
>>
>>For creating the correct Country Object, rowmap has to know the Locale to
>>serve. In this case the new 'Object' parameter would be filled with the User
>>Locale and casted so in rowmap. But in others cases, it could be another
>>information as the Locale.
>>
>>The main need is:
>>ROWMAP IS RESPONSIBLE FOR CREATING OBJECTS AND FOR THIS IT CAN HAVE TO KNOW
>>OTHER INFORMATION AS JUST THESE READ IN THE DATABASE.
>>
>>This other information can be just right during the 'execution' call and
>>cannot be in this case an instance variable. 
>>
>>
>>Regards,
>>Jean-Pierre
>>
>>---------- Initial Header -----------
>>
>>From      : "Rod Johnson" <rod...@in...>
>>To          : <tri...@tr...>, "Ken Krebs" <kk...@kk...>
>>Cc          : "JP Pawlak" <jp....@ti...>,      
>>"'springframework-developer'"
>><spr...@li...>
>>Date      : Thu, 10 Jul 2003 17:55:12 +0100
>>Subject : Re: [Springframework-developer] Locale in rowmap?
>>
>>    
>>
>>>I would agree with Ken here - we must avoid any dependencies between the
>>>      
>>>
>>JDBC
>>    
>>
>>>framework and the Web framework.
>>>      
>>>
>>+1. I know of several companies in the UK using JDBC only at this point.
>>It's a great route in for Spring.
>>
>>
>>
>>
>>********** L'ADSL A 20 EUR/MOIS**********
>>Tiscali propose l'ADSL le moins cher du marché : 20 EUR/mois et le modem ADSL
>>offert ! 
>>Pour profiter de cette offre exceptionnelle, cliquez ici :
>>http://register.tiscali.fr/adsl/
>>Offre soumise à conditions.
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by: Parasoft
>>Error proof Web apps, automate testing & more.
>>Download & eval WebKing and get a free book.
>>www.parasoft.com/bulletproofapps1
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>********** L'ADSL A 20 EUR/MOIS**********
>>Tiscali propose l'ADSL le moins cher du marché : 20 EUR/mois et le modem ADSL
>>offert ! 
>>Pour profiter de cette offre exceptionnelle, cliquez ici :
>>http://register.tiscali.fr/adsl/
>>Offre soumise à conditions.
>>
>>
>>
>>    
>>
>
>
>
>
>
>********** L'ADSL A 20 EUR/MOIS**********
>Tiscali propose l'ADSL le moins cher du marché : 20 EUR/mois et le modem ADSL offert ! 
>Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl/
>Offre soumise à conditions.
>
>
>
>
>  
>

[Springframework-developer] =?iso-8859-1?Q?Re:_Re:[Springframework-developer]_Re:_[Springframework-developer]_Locale_in_rowmap=3F?=

[=?iso-8859-1?Q?<jp....@ti...>]

Hello Thomas,=0D=0A=0D=0AThis is very close to what I made until a few da=
ys. What is wrong in this?=0D=0A=0D=0AIf two users request the same and h=
ave different contexts (ie Locales), the last will change on the road the=
 context to use for the first. For avoiding this, I used a "run" method s=
etting the context like in your exeample and calling the "execute method.=
 The "run" method being "synchronized".=0D=0AIn this manner, it works. Bu=
t I would eliminate the need of synchronizing due to performance reasons =
and for clarity. The context lifecycle is really tied to the execute meth=
od and setting it as an Instance variable is a workaround threadsafe only=
 with synchronizing.=0D=0A=0D=0AAs long as no consensus will be, I simply=
 will use the three changed classes in a private package. They don't brea=
k any backward compatibility, so I will use them instead of standard ones=
. The problem is only that I will have to check from time to time if the =
original have not changed. Secondly, I guess it's not a common need but n=
evertheless a general one and early or later, passing so contextual infor=
mation will be requested by developers.=0D=0A=0D=0AJean-Pierre=0D=0A=0D=0A=
---------- Initial Header -----------=0D=0A=0D=0AFrom      : trisberg@tri=
db.com=0D=0ATo          : "jp....@ti..." <jp....@ti...>=0D=
=0ACc          : "jp.pawlak" <jp....@ti...>, "rod.johnson" <rod.j=
oh...@in...>, kk <kk...@kk...>, springframework-developer <sp=
rin...@li...>=0D=0ADate      : Sat, 12 J=
ul 2003 10:49:56 -0400=0D=0ASubject : Re: Re:[Springframework-developer] =
Re: [Springframework-developer] Locale in rowmap?=0D=0A=0D=0AJean-Pierre,=
=0D=0A=0D=0ACould you not do this without modifying the JDBC layer?  Mayb=
e declare a=0D=0AUserContext in the custom class and set that via a bean =
setter.=0D=0A=0D=0ASomething like:=0D=0A=0D=0Apublic class SpringQuery ex=
tends MappingSqlQuery {=0D=0A=0D=0A  private UserContext userContext;=0D=0A=
=0D=0A  public SpringQuery(DataSource ds) {=0D=0A    super(ds, "select co=
l1, col2 from table");=0D=0A    compile();		=0D=0A  }=0D=0A=0D=0A  protec=
ted Object mapRow(ResultSet rs, int rownum) throws SQLException {=0D=0A  =
  ....=0D=0A    if (userContext.getLocale().equals("xxx")) =0D=0A        =
....=0D=0A    ....=0D=0A  }=0D=0A=0D=0A  public setUserContext(UserContex=
t uc) {=0D=0A    userContext =3D uc;=0D=0A  }=0D=0A=0D=0A}=0D=0A=0D=0A=0D=
=0AThomas=0D=0A=0D=0A> What I used also in the past is letting the DAO cr=
eate a 'data-layer' list=0D=0A> and after that in business layer, iterate=
 the list to replace data-layer=0D=0A> elements by business-layer ones kn=
owing the contextual information.=0D=0A> =0D=0A> This is certainly a bett=
er school-approach, but has clearly a performance=0D=0A> drawback.=0D=0A>=
 =0D=0A> Letting rowmap being able to create definitive objects (indeed h=
aving a user=0D=0A> defined contextual info), seems to me, for now, a bet=
ter solution.=0D=0A> =0D=0A> Jean-Pierre =0D=0A> =0D=0A> ---------- Initi=
al Header -----------=0D=0A> =0D=0A> From      : springframework-develope=
r-...@li...=0D=0A> To          : "rod.johnson" <rod.joh=
ns...@in...>=0D=0A> Cc          : "trisberg" <tri...@tr...=
>,"kk"=0D=0A> <kk...@kk...>,"springframework-developer"=0D=0A> <springfr=
ame...@li...>=0D=0A> Date      : Sat, 12 Jul 2=
003 12:05:19 +0200=0D=0A> Subject : [Springframework-developer] Re: [Spri=
ngframework-developer] Locale=0D=0A> in rowmap?=0D=0A> =0D=0A> Hi Ken, Th=
omas, Rod,=0D=0A> =0D=0A> It seems be a general miscomprehension.=0D=0A> =
=0D=0A> 1) I have no intend to put any dependency between WEB and JDBC.=0D=
=0A> My request is only at being able to add an optional 'Object' supplem=
ental=0D=0A> attribute in execute method. The intend of this attribute is=
 simply to be=0D=0A> passed on rowmap.=0D=0A> =0D=0A> 2) Why cannot this =
object be passed simply on the current methods?=0D=0A> Just because JDBC =
has nothing to do with. It is only for rowmap method as=0D=0A> this metho=
d is responsible for creating (business) objects.=0D=0A> =0D=0A> 3) Typic=
al example: =0D=0A> Searching adresses. =0D=0A> =0D=0A> a)Consider the se=
arched adresses are not localized on the database and=0D=0A> contain a co=
untry information.=0D=0A> =0D=0A> b)The database contain only the country=
 code of the address.=0D=0A> =0D=0A> c)With this country code is read fro=
m the database, the rowmap method will=0D=0A> have to create a Country Ob=
ject to put in the Address one. This Country=0D=0A> object will have a na=
me property matching with the current user to serve and=0D=0A> has nothin=
g to do with the JDBC record.=0D=0A> =0D=0A> For creating the correct Cou=
ntry Object, rowmap has to know the Locale to=0D=0A> serve. In this case =
the new 'Object' parameter would be filled with the User=0D=0A> Locale an=
d casted so in rowmap. But in others cases, it could be another=0D=0A> in=
formation as the Locale.=0D=0A> =0D=0A> The main need is:=0D=0A> ROWMAP I=
S RESPONSIBLE FOR CREATING OBJECTS AND FOR THIS IT CAN HAVE TO KNOW=0D=0A=
> OTHER INFORMATION AS JUST THESE READ IN THE DATABASE.=0D=0A> =0D=0A> Th=
is other information can be just right during the 'execution' call and=0D=
=0A> cannot be in this case an instance variable. =0D=0A> =0D=0A> =0D=0A>=
 Regards,=0D=0A> Jean-Pierre=0D=0A> =0D=0A> ---------- Initial Header ---=
--------=0D=0A> =0D=0A> From      : "Rod Johnson" <rod.johnson@interface2=
1.com>=0D=0A> To          : <tri...@tr...>, "Ken Krebs" <kk@kktec.c=
om>=0D=0A> Cc          : "JP Pawlak" <jp....@ti...>,      =0D=0A>=
 "'springframework-developer'"=0D=0A> <spr...@li...=
urceforge.net>=0D=0A> Date      : Thu, 10 Jul 2003 17:55:12 +0100=0D=0A> =
Subject : Re: [Springframework-developer] Locale in rowmap?=0D=0A> =0D=0A=
> > I would agree with Ken here - we must avoid any dependencies between =
the=0D=0A> JDBC=0D=0A> > framework and the Web framework.=0D=0A> =0D=0A> =
+1. I know of several companies in the UK using JDBC only at this point.=0D=
=0A> It's a great route in for Spring.=0D=0A> =0D=0A> =0D=0A> =0D=0A> =0D=
=0A> ********** L'ADSL A 20 EUR/MOIS**********=0D=0A> Tiscali propose l'A=
DSL le moins cher du march=E9 : 20 EUR/mois et le modem ADSL=0D=0A> offer=
t ! =0D=0A> Pour profiter de cette offre exceptionnelle, cliquez ici :=0D=
=0A> http://register.tiscali.fr/adsl/=0D=0A> Offre soumise =E0 conditions=
.=0D=0A> =0D=0A> =0D=0A> =0D=0A> =0D=0A> --------------------------------=
-----------------------=0D=0A> This SF.Net email sponsored by: Parasoft=0D=
=0A> Error proof Web apps, automate testing & more.=0D=0A> Download & eva=
l WebKing and get a free book.=0D=0A> www.parasoft.com/bulletproofapps1=0D=
=0A> _______________________________________________=0D=0A> Springframewo=
rk-developer mailing list=0D=0A> Spr...@li...=
rge.net=0D=0A> https://lists.sourceforge.net/lists/listinfo/springframewo=
rk-developer=0D=0A> =0D=0A> =0D=0A> ********** L'ADSL A 20 EUR/MOIS******=
****=0D=0A> Tiscali propose l'ADSL le moins cher du march=E9 : 20 EUR/moi=
s et le modem ADSL=0D=0A> offert ! =0D=0A> Pour profiter de cette offre e=
xceptionnelle, cliquez ici :=0D=0A> http://register.tiscali.fr/adsl/=0D=0A=
> Offre soumise =E0 conditions.=0D=0A> =0D=0A> =0D=0A> =0D=0A=0D=0A=0D=0A=
=0D=0A=0A=0A********** L'ADSL A 20 EUR/MOIS**********=0ATiscali propose l=
'ADSL le moins cher du march=E9 : 20 EUR/mois et le modem ADSL offert ! =0A=
Pour profiter de cette offre exceptionnelle, cliquez ici : http://registe=
r.tiscali.fr/adsl/=0AOffre soumise =E0 conditions.=0A

[Springframework-developer] Re: =?iso-8859-1?Q?Re:[Springframework-developer]_Re:_[Springframework-developer]_Locale_in_rowmap=3F?=

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

Jean-Pierre,

Could you not do this without modifying the JDBC layer?  Maybe declare a
UserContext in the custom class and set that via a bean setter.

Something like:

public class SpringQuery extends MappingSqlQuery {

  private UserContext userContext;

  public SpringQuery(DataSource ds) {
    super(ds, "select col1, col2 from table");
    compile();		
  }

  protected Object mapRow(ResultSet rs, int rownum) throws SQLException {
    ....
    if (userContext.getLocale().equals("xxx")) 
        ....
    ....
  }

  public setUserContext(UserContext uc) {
    userContext = uc;
  }

}


Thomas

> What I used also in the past is letting the DAO create a 'data-layer' list
> and after that in business layer, iterate the list to replace data-layer
> elements by business-layer ones knowing the contextual information.
> 
> This is certainly a better school-approach, but has clearly a performance
> drawback.
> 
> Letting rowmap being able to create definitive objects (indeed having a user
> defined contextual info), seems to me, for now, a better solution.
> 
> Jean-Pierre 
> 
> ---------- Initial Header -----------
> 
> From      : spr...@li...
> To          : "rod.johnson" <rod...@in...>
> Cc          : "trisberg" <tri...@tr...>,"kk"
> <kk...@kk...>,"springframework-developer"
> <spr...@li...>
> Date      : Sat, 12 Jul 2003 12:05:19 +0200
> Subject : [Springframework-developer] Re: [Springframework-developer] Locale
> in rowmap?
> 
> Hi Ken, Thomas, Rod,
> 
> It seems be a general miscomprehension.
> 
> 1) I have no intend to put any dependency between WEB and JDBC.
> My request is only at being able to add an optional 'Object' supplemental
> attribute in execute method. The intend of this attribute is simply to be
> passed on rowmap.
> 
> 2) Why cannot this object be passed simply on the current methods?
> Just because JDBC has nothing to do with. It is only for rowmap method as
> this method is responsible for creating (business) objects.
> 
> 3) Typical example: 
> Searching adresses. 
> 
> a)Consider the searched adresses are not localized on the database and
> contain a country information.
> 
> b)The database contain only the country code of the address.
> 
> c)With this country code is read from the database, the rowmap method will
> have to create a Country Object to put in the Address one. This Country
> object will have a name property matching with the current user to serve and
> has nothing to do with the JDBC record.
> 
> For creating the correct Country Object, rowmap has to know the Locale to
> serve. In this case the new 'Object' parameter would be filled with the User
> Locale and casted so in rowmap. But in others cases, it could be another
> information as the Locale.
> 
> The main need is:
> ROWMAP IS RESPONSIBLE FOR CREATING OBJECTS AND FOR THIS IT CAN HAVE TO KNOW
> OTHER INFORMATION AS JUST THESE READ IN THE DATABASE.
> 
> This other information can be just right during the 'execution' call and
> cannot be in this case an instance variable. 
> 
> 
> Regards,
> Jean-Pierre
> 
> ---------- Initial Header -----------
> 
> From      : "Rod Johnson" <rod...@in...>
> To          : <tri...@tr...>, "Ken Krebs" <kk...@kk...>
> Cc          : "JP Pawlak" <jp....@ti...>,      
> "'springframework-developer'"
> <spr...@li...>
> Date      : Thu, 10 Jul 2003 17:55:12 +0100
> Subject : Re: [Springframework-developer] Locale in rowmap?
> 
> > I would agree with Ken here - we must avoid any dependencies between the
> JDBC
> > framework and the Web framework.
> 
> +1. I know of several companies in the UK using JDBC only at this point.
> It's a great route in for Spring.
> 
> 
> 
> 
> ********** L'ADSL A 20 EUR/MOIS**********
> Tiscali propose l'ADSL le moins cher du marché : 20 EUR/mois et le modem ADSL
> offert ! 
> Pour profiter de cette offre exceptionnelle, cliquez ici :
> http://register.tiscali.fr/adsl/
> Offre soumise à conditions.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> ********** L'ADSL A 20 EUR/MOIS**********
> Tiscali propose l'ADSL le moins cher du marché : 20 EUR/mois et le modem ADSL
> offert ! 
> Pour profiter de cette offre exceptionnelle, cliquez ici :
> http://register.tiscali.fr/adsl/
> Offre soumise à conditions.
> 
> 
> 

Re: [Springframework-developer] Tags using expression language??

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

SSd2ZSBpbnRyb2R1Y2VkIHN1cHBvcnQgZm9yIEVMIG9uIHRhZyBhdHRyaWJ1dGVzIHllc3RlcmRh
eSwgYWxyZWFkeSBjb21taXR0ZWQuIFRoYW5rcyBmb3IgdGhlIGlkZWEgYW5kIHRoZSBwcm90b3R5
cGUsIEFsZWYhIEkgaG9wZSB5b3UgYXJlIHNhdGlzZmllZCB3aXRoIHRoZSBpbnRlZ3JhdGlvbi4g
WW91J3JlIHZlcnkgd2VsY29tZSB0byB0cnkgaXQgb3V0IDotKQ0KIA0KVGhlcmUncyBhIG5ldyBF
eHByZXNzaW9uRXZhbHVhdGlvbnNVdGlscyBjbGFzcyBub3cgaW4gY29tLmludGVyZmFjZTIxLndl
Yi51dGlsLCB0YWtpbmcgYSBTdHJpbmcgYXJndW1lbnQgdmFsdWUgYW5kIHBhcnNpbmcgaXQgdG8g
T2JqZWN0LCBTdHJpbmcsIGludCwgb3IgYm9vbGVhbi4gSXQgd2lsbCBqdXN0IGF0dGVtcHQgRUwg
ZXZhbHVhdGlvbiBpZiB0aGUgdmFsdWUgc3RhcnRzIHdpdGggIiR7IiwgZWxzZSBpdCB3aWxsIHNp
bXBseSBwYXJzZSB0aGUgdmFsdWUgd2l0aCBzdGFuZGFyZCBtZWFucy4NCiANCkFsbCBvZiBTcHJp
bmcncyB0YWdzIHVzZSB0aGlzIGNsYXNzIG5vdyBmb3IgYWxsIGF0dHJpYnV0ZXMsIHNpbXBseSBk
ZWxlZ2F0aW5nIHRvIHRoZSByZXNwZWN0aXZlIEV4cHJlc3Npb25FdmFsdWF0aW9uc1V0aWxzIG1l
dGhvZCBpbiBlYWNoIHNldHRlci4gVGhpcyBtZWFucyB0aGF0IGFsbCBhdHRyaWJ1dGVzIHN0aWxs
IGFjY2VwdCBub3JtYWwgU3RyaW5nIHZhbHVlcyBhcyBiZWZvcmUgKGxpa2UgPGkyMTpiaW5kIHBh
dGg9InBlcnNvbi5uYW1lIj4pLCBidXQgYWxzbyBFTCBleHByZXNzaW9ucyAobGlrZSA8aTIxOmJp
bmQgcGF0aD0iJHtiaW5kUGF0aH0iPikuDQogDQpGb3IgRUwgZXZhbHVhdGlvbiwgRXhwcmVzc2lv
bkV2YWx1YXRpb25zVXRpbHMgZGVwZW5kcyBvbiBKYWthcnRhJ3MgSlNUTCBpbXBsZW1lbnRhdGlv
biAoc3RhbmRhcmQuamFyKS4gSXQgZG9lc24ndCBoYXZlIGEgcnVudGltZSBkZXBlbmRlbmN5IGlm
IGp1c3QgcGFyc2luZyBub3JtYWwgU3RyaW5nIHZhbHVlcyB0aG91Z2gsIGFzIGl0IGRlbGVnYXRl
cyBFTCBldmFsdWF0aW9uIHRvIGFuIGlubmVyIGNsYXNzIHRoYXQgd2lsbCBqdXN0IGdldCBsb2Fk
ZWQgaW4gY2FzZSBvZiBhY3R1YWwgRUwgZXhwcmVzc2lvbnMuIFNvIHlvdSdsbCBqdXN0IG5lZWQg
dGhlIEpha2FydGEgSlNUTCBpbXBsZW1lbnRhdGlvbiBpbiB5b3VyIGNsYXNzcGF0aCBpZiB5b3Ug
YWN0dWFsbHkgdXNlIEVMIGF0dHJpYnV0ZSB2YWx1ZXMgb24gdGFncy4NCiANCkJUVywgb3VyIEFv
cFByb3h5IHVzZXMgYSBzaW1pbGFyIG1lY2hhbmlzbSB0byBhdm9pZCBhIHJ1bnRpbWUgZGVwZW5k
ZW5jeSBvbiBDR0xJQi4gSWYganVzdCBwcm94eWluZyBpbnRlcmZhY2VzLCBpdCB3aWxsIHVzZSBz
dGFuZGFyZCBKMlNFIHByb3hpZXMuIE9ubHkgaWYgeW91IHRyeSB0byBwcm94eSBhIGNsYXNzIGl0
c2VsZiwgaXQgd2lsbCBpbnZva2UgQ0dMSUIgYnkgZGVsZWdhdGluZyB0byBhIHJlc3BlY3RpdmUg
aW5uZXIgY2xhc3MuDQogDQpGaW5hbGx5LCB3ZSBzaG91bGQgYWRhcHQgUGV0Q2xpbmljIHRvIHVz
ZSBFTCBleHByZXNzaW9ucyBvbiBpdHMgYmluZCB0YWdzLiBBbGVmIGhhcyBhbHJlYWR5IHNob3du
IHRoZSB3YXkgaW4gdGhlIHByb3RvdHlwZSB0aGF0IGhlIHNlbnQuIEtlbiwgd2hhdCBkbyB5b3Ug
dGhpbms/IFdvdWxkIHlvdSBsaWtlIEFsZWYgdG8gZG8gdGhpcz8NCiANCkp1ZXJnZW4NCiANCiAN
Cg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBqw7xyZ2VuIGjD
tmxsZXIgW3dlcmszQVRdIA0KCUdlc2VuZGV0OiBGciAxMS4wNy4yMDAzIDA4OjEzIA0KCUFuOiBh
bGVmQGp0ZWFtLm5sOyBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdl
Lm5ldCANCglDYzogDQoJQmV0cmVmZjogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBU
YWdzIHVzaW5nIGV4cHJlc3Npb24gbGFuZ3VhZ2U/Pw0KCQ0KCQ0KDQoJQWxlZiwNCgkNCglJJ3Zl
IGp1c3QgYnJvd3NlZCB5b3VyIGNvZGUgLSB0aGlzIGxvb2tzIHZlcnkgaW50ZXJlc3RpbmchIEl0
IG1ha2VzIGl0ZXJhdGluZyBzdWNoIHJlcGV0aXRpdmUgZm9ybSBmaWVsZHMgbGlrZSBpbiB0aGUg
cGV0Y2xpbmljIG11Y2ggZWFzaWVyLiBJJ2xsIGhhdmUgYSBsb29rIGF0IHRoZSBpbXBsZW1lbnRh
dGlvbiBkZXRhaWxzLCBhbmQgaWYgZXZlcnl0aGluZyB3b3JrcyBvdXQgSSdsbCBhZGQgYSBjbGVh
biByb29tIHZlcnNpb24gdG8gdGhlIG1haW4gc291cmNlIHRyZWUgcHJvbXB0bHkuDQoJDQoJSSB3
b25kZXIgaWYgd2UgY291bGQgbWFrZSB0aGF0IHdvcmsgd2l0aCBhbnkgSlNUTCBpbXBsZW1lbnRh
dGlvbiwgbm90IGp1c3QgdGhlIEpha2FydGEgb25lLCBhbHRob3VnaCBJIHdvdWxkbid0IG1pbmQg
YSBkZXBlbmRlbmN5IG9uIHRoZSBsYXR0ZXIgZm9yIHRoaXMgZmVhdHVyZS4NCgkNCglDb29sIHN0
dWZmIDotKQ0KCQ0KCUp1ZXJnZW4NCgkNCgkNCgkNCgkgICAgICAgIC0tLS0tVXJzcHLDvG5nbGlj
aGUgTmFjaHJpY2h0LS0tLS0NCgkgICAgICAgIFZvbjogQWxlZiBBcmVuZHNlbiBbbWFpbHRvOmFs
ZWZAanRlYW0ubmxdDQoJICAgICAgICBHZXNlbmRldDogRGkgMDguMDcuMjAwMyAxOTo0Mw0KCSAg
ICAgICAgQW46IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF07IHNwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJICAgICAgICBDYzoNCgkgICAgICAgIEJldHJl
ZmY6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gVGFncyB1c2luZyBleHByZXNzaW9u
IGxhbmd1YWdlPz8NCgkgICAgICAgDQoJICAgICAgIA0KCQ0KCSAgICAgICAgT2ssIGhlcmUgd2Ug
Z28uLi4NCgkgICAgICAgDQoJICAgICAgICBMaWtlIHlvdSBzYWlkLCBhdCBmaXJzdCBnbGFuY2Us
IGl0IGRvZXMgbm90IGxvb2sgbGlrZSB0aGUgaTIxOmJpbmQgdGFnDQoJICAgICAgICBuZWVkcyBl
eHByZXNzaW9uYWxpemF0aW9uIChobW1tLCBuaWNlIGh1aCA7LSkuIEhvd2V2ZXIsIGluIHRoZSBw
ZXRjbGluaWMNCgkgICAgICAgIGRlbW8gYXBwIEknbSBzZWVpbmcgYSBsb3Qgb2YgaW5wdXQuanNw
cyBpbiB0aGUganNwL2ZpZWxkcyBkaXJlY3RvcnkuDQoJICAgICAgICBUaGVzZSBhcmUgdGhpbmdz
IEknbSBob3BpbmcgdG8gc29sdmUgdXNpbmcgZm9yIGluc3RhbmNlIEVMLWJhc2VkIHRhZ3MuLi4N
CgkgICAgICAgIEF0dGFjaGVkIHlvdSdsbCBmaW5kIGEgcmV3b3JrZWQgdmVyc2lvbiBvZiB0aGUg
b3duZXJGb3JtLiBJdCBkb2VzIG5vdA0KCSAgICAgICAgdXNlIHRoZSBKU1BzIGZyb20gdGhlIGZp
ZWxkcyBkaXJlY3RvcnkgYW55bW9yZSwgYnV0IHVzZXMgb25seSBvbmUNCgkgICAgICAgIGlucHV0
LmpzcCB0aGF0IHVzZXMgdGhlIGJpbmRzdGF0dXMgb2JqZWN0IHRvIGNyZWF0ZSB0aGUgaW5wdXQg
ZmllbGQuDQoJICAgICAgIA0KCSAgICAgICAgT2ssIGl0J3Mgc3RpbGwgYWxsIHJvdWdoIGFuZCBy
ZXdvcmtpbmcgdGhlIHRhZ3MgaXMgYSBsaXR0bGUgYml0IG1vcmUNCgkgICAgICAgIHdvcmsgdGhh
biB0aGUgMTUgbWludXRlcyBJIHNwZW50IG9uIGl0IG5vdywgYnV0IG1heWJlIHlvdSdyZSBnZXR0
aW5nIHRoZQ0KCSAgICAgICAgaWRlYS4NCgkgICAgICAgDQoJICAgICAgICBDb25zZXF1ZW5jZXMg
Zm9yIGFkZGluZyAvIHJld29ya2luZyB0aGUgdGFnczoNCgkgICAgICAgDQoJICAgICAgICAxLiBk
ZXBlbmRlbmN5IG9uIGpha2FydGEtanN0bC0xLjAuMyAoamFrYXJ0YS5hcGFjaGUub3JnL3RhZ2xp
YiAtLT4NCgkgICAgICAgIHN0YW5kYXJkKS4NCgkgICAgICAgIDIuIGRlcGVuZGVuY3kgb24ganN0
bC0xLjAuMyAoamF2YS5zdW4uY29tKQ0KCSAgICAgICAgMy4gSW4gY2FzZSB5b3Ugd2FudCB0byBo
YXZlIGJvdGggdmVyc2lvbiBpbiB0aGVyZSwgYW4gZXh0ZW5kaW5nIGNsYXNzDQoJICAgICAgICBm
b3IgZWFjaCB0YWcNCgkgICAgICAgIDQuIEZvciBlYWNoIHRhZywgYSBCZWFuSW5mbyBjbGFzcw0K
CSAgICAgICAgNS4gSSB3YXNuJ3QgYWJsZSB0byB1c2UgdGhlIEV2YWxIZWxwZXIgZnJvbSBqYWth
cnRhLCBzbyBJIGNvcGllZCBpdA0KCSAgICAgICAgKGhtbW0uLi4gbm90IHNvIG5pY2UsIGlzIGl0
IDstKQ0KCSAgICAgICANCgkgICAgICAgIFByb2JhYmx5IEkgZG9uJ3QgaGF2ZSB0aW1lIHRoaXMg
d2VlayBvciBzb21ldGhpbmcgdG8gcmVmYWN0b3IgdGhlbSB0byBiZQ0KCSAgICAgICAgYWxsIEVM
LWJhc2VkLi4uIEp1c3QgbGV0IG1lIGtub3cgaWYgeW91J2QgbGlrZSBpdC4NCgkgICAgICAgDQoJ
ICAgICAgICBXZWxsLCB0aGF0J3MgaXQgZm9yIG5vdywgc3RpbGwgZGlzY292ZXJpbmcgcmVhbGx5
IGNvb2wgZmVhdHVyZXMgYW5kDQoJICAgICAgICBhbHJlYWR5IHJ1bm5pbmcgb3V0IChicmFpbilt
ZW1vcnkgdG8gdGhpbmsgdXAgZXZlcnl0aGluZyBJIGNvdWxkIGRvIHdpdGgNCgkgICAgICAgIFNw
cmluZyA7LSkNCgkgICAgICAgDQoJICAgICAgICBDaGVlcnMsDQoJICAgICAgIA0KCSAgICAgICAg
QWxlZg0KCSAgICAgICANCgkNCglOGEhTXumailspeyhbah9K66K6a3nGrl7Yp2oreDowWhp12pVn
Kilqd2B61p/nm6IwDQoJWih+KFcofWlUKX57DQoJK9evelopelhYKmt4H8KKdd6WXlgoHn56d2ls
cQd6bFgp36MpKX57DQoJK9evelopIA0KDQo=

[Springframework-developer] =?iso-8859-1?Q?Re:[Springframework-developer]_Re:_[Springframework-developer]_Locale_in_rowmap=3F?=

[=?iso-8859-1?Q?<jp....@ti...>]

What I used also in the past is letting the DAO create a 'data-layer' lis=
t and after that in business layer, iterate the list to replace data-laye=
r elements by business-layer ones knowing the contextual information.=0D=0A=
=0D=0AThis is certainly a better school-approach, but has clearly a perfo=
rmance drawback.=0D=0A=0D=0ALetting rowmap being able to create definitiv=
e objects (indeed having a user defined contextual info), seems to me, fo=
r now, a better solution.=0D=0A=0D=0AJean-Pierre =0D=0A=0D=0A---------- I=
nitial Header -----------=0D=0A=0D=0AFrom      : springframework-develope=
r-...@li...=0D=0ATo          : "rod.johnson" <rod.johns=
on...@in...>=0D=0ACc          : "trisberg" <tri...@tr...>,"k=
k" <kk...@kk...>,"springframework-developer" <springframework-developer@=
lists.sourceforge.net>=0D=0ADate      : Sat, 12 Jul 2003 12:05:19 +0200=0D=
=0ASubject : [Springframework-developer] Re: [Springframework-developer] =
Locale in rowmap?=0D=0A=0D=0AHi Ken, Thomas, Rod,=0D=0A=0D=0AIt seems be =
a general miscomprehension.=0D=0A=0D=0A1) I have no intend to put any dep=
endency between WEB and JDBC.=0D=0AMy request is only at being able to ad=
d an optional 'Object' supplemental attribute in execute method. The inte=
nd of this attribute is simply to be passed on rowmap.=0D=0A=0D=0A2) Why =
cannot this object be passed simply on the current methods?=0D=0AJust bec=
ause JDBC has nothing to do with. It is only for rowmap method as this me=
thod is responsible for creating (business) objects.=0D=0A=0D=0A3) Typica=
l example: =0D=0ASearching adresses. =0D=0A=0D=0Aa)Consider the searched =
adresses are not localized on the database and contain a country informat=
ion.=0D=0A=0D=0Ab)The database contain only the country code of the addre=
ss.=0D=0A=0D=0Ac)With this country code is read from the database, the ro=
wmap method will have to create a Country Object to put in the Address on=
e. This Country object will have a name property matching with the curren=
t user to serve and has nothing to do with the JDBC record.=0D=0A=0D=0AFo=
r creating the correct Country Object, rowmap has to know the Locale to s=
erve. In this case the new 'Object' parameter would be filled with the Us=
er Locale and casted so in rowmap. But in others cases, it could be anoth=
er information as the Locale.=0D=0A=0D=0AThe main need is:=0D=0AROWMAP IS=
 RESPONSIBLE FOR CREATING OBJECTS AND FOR THIS IT CAN HAVE TO KNOW OTHER =
INFORMATION AS JUST THESE READ IN THE DATABASE.=0D=0A=0D=0AThis other inf=
ormation can be just right during the 'execution' call and cannot be in t=
his case an instance variable. =0D=0A=0D=0A=0D=0ARegards,=0D=0AJean-Pierr=
e=0D=0A=0D=0A---------- Initial Header -----------=0D=0A=0D=0AFrom      :=
 "Rod Johnson" <rod...@in...>=0D=0ATo          : <trisberg=
@tridb.com>, "Ken Krebs" <kk...@kk...>=0D=0ACc          : "JP Pawlak" <j=
p.p...@ti...>,       "'springframework-developer'" <springframewor=
k-d...@li...>=0D=0ADate      : Thu, 10 Jul 2003 17:5=
5:12 +0100=0D=0ASubject : Re: [Springframework-developer] Locale in rowma=
p?=0D=0A=0D=0A> I would agree with Ken here - we must avoid any dependenc=
ies between the=0D=0AJDBC=0D=0A> framework and the Web framework.=0D=0A=0D=
=0A+1. I know of several companies in the UK using JDBC only at this poin=
t.=0D=0AIt's a great route in for Spring.=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A**=
******** L'ADSL A 20 EUR/MOIS**********=0D=0ATiscali propose l'ADSL le mo=
ins cher du march=E9 : 20 EUR/mois et le modem ADSL offert ! =0D=0APour p=
rofiter de cette offre exceptionnelle, cliquez ici : http://register.tisc=
ali.fr/adsl/=0D=0AOffre soumise =E0 conditions.=0D=0A=0D=0A=0D=0A=0D=0A=0D=
=0A-------------------------------------------------------=0D=0AThis SF.N=
et email sponsored by: Parasoft=0D=0AError proof Web apps, automate testi=
ng & more.=0D=0ADownload & eval WebKing and get a free book.=0D=0Awww.par=
asoft.com/bulletproofapps1=0D=0A_________________________________________=
______=0D=0ASpringframework-developer mailing list=0D=0ASpringframework-d=
eve...@li...=0D=0Ahttps://lists.sourceforge.net/lists/l=
istinfo/springframework-developer=0D=0A=0A=0A********** L'ADSL A 20 EUR/M=
OIS**********=0ATiscali propose l'ADSL le moins cher du march=E9 : 20 EUR=
/mois et le modem ADSL offert ! =0APour profiter de cette offre exception=
nelle, cliquez ici : http://register.tiscali.fr/adsl/=0AOffre soumise =E0=
 conditions.=0A

[Springframework-developer] =?iso-8859-1?Q?Re:_[Springframework-developer]_Locale_in_rowmap=3F?=

[=?iso-8859-1?Q?<jp....@ti...>]

Hi Ken, Thomas, Rod,=0D=0A=0D=0AIt seems be a general miscomprehension.=0D=
=0A=0D=0A1) I have no intend to put any dependency between WEB and JDBC.=0D=
=0AMy request is only at being able to add an optional 'Object' supplemen=
tal attribute in execute method. The intend of this attribute is simply t=
o be passed on rowmap.=0D=0A=0D=0A2) Why cannot this object be passed sim=
ply on the current methods?=0D=0AJust because JDBC has nothing to do with=
. It is only for rowmap method as this method is responsible for creating=
 (business) objects.=0D=0A=0D=0A3) Typical example: =0D=0ASearching adres=
ses. =0D=0A=0D=0Aa)Consider the searched adresses are not localized on th=
e database and contain a country information.=0D=0A=0D=0Ab)The database c=
ontain only the country code of the address.=0D=0A=0D=0Ac)With this count=
ry code is read from the database, the rowmap method will have to create =
a Country Object to put in the Address one. This Country object will have=
 a name property matching with the current user to serve and has nothing =
to do with the JDBC record.=0D=0A=0D=0AFor creating the correct Country O=
bject, rowmap has to know the Locale to serve. In this case the new 'Obje=
ct' parameter would be filled with the User Locale and casted so in rowma=
p. But in others cases, it could be another information as the Locale.=0D=
=0A=0D=0AThe main need is:=0D=0AROWMAP IS RESPONSIBLE FOR CREATING OBJECT=
S AND FOR THIS IT CAN HAVE TO KNOW OTHER INFORMATION AS JUST THESE READ I=
N THE DATABASE.=0D=0A=0D=0AThis other information can be just right durin=
g the 'execution' call and cannot be in this case an instance variable. =0D=
=0A=0D=0A=0D=0ARegards,=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial He=
ader -----------=0D=0A=0D=0AFrom      : "Rod Johnson" <rod.johnson@interf=
ace21.com>=0D=0ATo          : <tri...@tr...>, "Ken Krebs" <kk@kktec=
.com>=0D=0ACc          : "JP Pawlak" <jp....@ti...>,       "'spri=
ngframework-developer'" <spr...@li...>=
=0D=0ADate      : Thu, 10 Jul 2003 17:55:12 +0100=0D=0ASubject : Re: [Spr=
ingframework-developer] Locale in rowmap?=0D=0A=0D=0A> I would agree with=
 Ken here - we must avoid any dependencies between the=0D=0AJDBC=0D=0A> f=
ramework and the Web framework.=0D=0A=0D=0A+1. I know of several companie=
s in the UK using JDBC only at this point.=0D=0AIt's a great route in for=
 Spring.=0D=0A=0D=0A=0D=0A=0A=0A********** L'ADSL A 20 EUR/MOIS**********=
=0ATiscali propose l'ADSL le moins cher du march=E9 : 20 EUR/mois et le m=
odem ADSL offert ! =0APour profiter de cette offre exceptionnelle, clique=
z ici : http://register.tiscali.fr/adsl/=0AOffre soumise =E0 conditions.=0A=

[Springframework-developer] Hibernate configuration

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

QW4gdXBkYXRlIG9uIEhpYmVybmF0ZSBjb25maWd1cmF0aW9uOg0KDQpBZnRlciBhIHJlY2VudCBk
aXNjdXNzaW9uIHdpdGggR2F2aW4gS2luZyBmcm9tIEhpYmVybmF0ZSwgSSd2ZSBqdXN0IGNoYW5n
ZWQgdGhlIGFwcHJvYWNoIGZvciBEYXRhU291cmNlIGluaXRpYWxpemF0aW9uOiBJZiBhIERhdGFT
b3VyY2UgaXMgc3BlY2lmaWVkIGZvciBIaWJlcm5hdGVUcmFuc2FjdGlvbk1hbmFnZXIsIGl0IHdp
bGwgc2ltcGx5IGV4cG9ydCBhbiBhY3RpdmUgSGliZXJuYXRlIHRyYW5zYWN0aW9uIGFzIGEgSkRC
QyBDb25uZWN0aW9uIGZvciB0aGlzIERhdGFTb3VyY2UsIG5vdCB1c2UgdGhlIERhdGFTb3VyY2Ug
Zm9yIHRoZSBIaWJlcm5hdGUgU2Vzc2lvbi4gU3VwcGx5aW5nIGEgU3ByaW5nLWNvbmZpZ3VyZWQg
RGF0YVNvdXJjZSB0byBIaWJlcm5hdGUgbm93IHdvcmtzIHZpYSBMb2NhbFNlc3Npb25GYWN0b3J5
QmVhbiwgdXNpbmcgYSBzcGVjaWFsIGltcGxlbWVudGF0aW9uIG9mIGEgSGliZXJuYXRlIENvbm5l
Y3Rpb25Qcm92aWRlciB1bmRlciB0aGUgaG9vZC4NCg0KRm9yIHRoZSB0eXBpY2FsIGNhc2Ugd2hl
cmUgYSAiaGliZXJuYXRlLmNmZy54bWwiIGZpbGUgaXMgbG9hZGVkLCBhIExvY2FsU2Vzc2lvbkZh
Y3RvcnlCZWFuIGRlZmluaXRpb24gY2FuIG5vdyBsb29rIGFzIGZvbGxvd3MgaWYgaXQgd2FudHMg
dG8gdXNlIGEgU3ByaW5nLWNvbmZpZ3VyZWQgRGF0YVNvdXJjZS4gTm90ZSB0aGF0IHRoZSBIaWJl
cm5hdGUgY29uZmlnIGZpbGUgc2hvdWxkIG5vdCBzcGVjaWZ5IGEgY29ubmVjdGlvbiBwcm92aWRl
ciB0aGVuLCB0byBhdm9pZCBkdXBsaWNhdGUgY29uZmlndXJhdGlvbi4gSXQgd291bGQganVzdCBj
b250YWluIHJlZmVyZW5jZXMgdG8gc29tZSBtYXBwaW5nIHJlc291cmNlcyBhbmQgdmFsdWVzIGZv
ciBzb21lIEhpYmVybmF0ZSBwcm9wZXJ0aWVzLg0KDQogIDxiZWFuIGlkPSJzZXNzaW9uRmFjdG9y
eSIgY2xhc3M9ImNvbS5pbnRlcmZhY2UyMS5vcm0uaGliZXJuYXRlLkxvY2FsU2Vzc2lvbkZhY3Rv
cnlCZWFuIj4NCiAgICA8cHJvcGVydHkgbmFtZT0iY29uZmlnTG9jYXRpb24iPjx2YWx1ZT4vaGli
ZXJuYXRlLmNmZy54bWw8L3ZhbHVlPjwvcHJvcGVydHk+DQogICAgPHByb3BlcnR5IG5hbWU9ImRh
dGFTb3VyY2UiPjxyZWYgYmVhbj0ibXlEYXRhU291cmNlIi8+PC9wcm9wZXJ0eT4NCiAgPC9iZWFu
Pg0KDQpBbHRlcm5hdGl2ZWx5LCB0aGVyZSdzIG5vdyBhIG5ldyB3YXkgdGhhdCBjb21wbGV0ZWx5
IGF2b2lkcyBhbnkgZXh0ZXJuYWwgSGliZXJuYXRlIGNvbmZpZyBmaWxlIGxpa2UgaGliZXJuYXRl
LmNmZy54bWwuIFlvdSBjYW4gc3BlY2lmeSB0aGUgbWFwcGluZyByZXNvdXJjZXMgYW5kIEhpYmVy
bmF0ZSBwcm9wZXJ0aWVzIGRpcmVjdGx5IHZpYSBiZWFuIHByb3BlcnRpZXMsIGZvciBleGFtcGxl
Og0KDQogIDxiZWFuIGlkPSJzZXNzaW9uRmFjdG9yeSIgY2xhc3M9ImNvbS5pbnRlcmZhY2UyMS5v
cm0uaGliZXJuYXRlLkxvY2FsU2Vzc2lvbkZhY3RvcnlCZWFuIj4NCiAgICA8cHJvcGVydHkgbmFt
ZT0ibWFwcGluZ1Jlc291cmNlcyI+DQogICAgICA8bGlzdD4NCiAgICAgICAgPHZhbHVlPnN5c3Rl
bS5oYm0ueG1sPC92YWx1ZT4NCiAgICAgICAgPHZhbHVlPm1lZGlhLmhibS54bWw8L3ZhbHVlPg0K
ICAgICAgICA8dmFsdWU+dGVtcGxhdGUuaGJtLnhtbDwvdmFsdWU+DQogICAgICA8L2xpc3Q+DQog
ICAgPC9wcm9wZXJ0eT4NCiAgICA8cHJvcGVydHkgbmFtZT0iaGliZXJuYXRlUHJvcGVydGllcyI+
DQogICAgICA8cHJvcHM+DQogICAgICAgIDxwcm9wIGtleT0iaGliZXJuYXRlLmRpYWxlY3QiPm5l
dC5zZi5oaWJlcm5hdGUuZGlhbGVjdC5NeVNRTERpYWxlY3Q8L3Byb3A+DQogICAgICAgIDxwcm9w
IGtleT0iaGliZXJuYXRlLnF1ZXJ5LnN1YnN0aXR1dGlvbnMiPnRydWU9MSBmYWxzZT0wPC9wcm9w
Pg0KICAgICAgICA8cHJvcCBrZXk9ImhpYmVybmF0ZS5zaG93X3NxbCI+dHJ1ZTwvcHJvcD4NCiAg
ICAgIDwvcHJvcHM+DQogICAgPC9wcm9wZXJ0eT4NCiAgICA8cHJvcGVydHkgbmFtZT0iZGF0YVNv
dXJjZSI+PHJlZiBiZWFuPSJteURhdGFTb3VyY2UiLz48L3Byb3BlcnR5Pg0KICA8L2JlYW4+DQoN
Ck5vdGUgdGhhdCBzcGVjaWZ5aW5nIGEgRGF0YVNvdXJjZSBvbiBMb2NhbFNlc3Npb25GYWN0b3J5
QmVhbiBpc24ndCByZXF1aXJlZCBpbiBhbnkgY2FzZSwgeW91IGNhbiBhbHdheXMgbGV0IEhpYmVy
bmF0ZSBvYnRhaW4gaXQgdGhyb3VnaCBpdHMgY29ubmVjdGlvbiBwcm92aWRlciBtZWNoYW5pc20u
IElmIHlvdSBzcGVjaWZ5IGEgRGF0YVNvdXJjZSBoZXJlIHRob3VnaCwgaXQgd2lsbCBvdmVycmlk
ZSBhbnkgSGliZXJuYXRlLWNvbmZpZ3VyZWQgb25lLiBGdXJ0aGVybW9yZSwgeW91IGNhbiBhbHNv
IG1peCBzZXR0aW5ncyBpbiBhIEhpYmVybmF0ZSBjb25maWcgZmlsZSBhbmQgYWRkaXRpb25hbCBt
YXBwaW5ncyBhbmQvb3IgcHJvcGVydGllcyB0aGF0IGFyZSBkZWZpbmVkIG9uIExvY2FsU2Vzc2lv
bkZhY3RvcnlCZWFuLg0KDQpGb3IgY29uc2lzdGVuY3kgaW4gdGVybXMgb2Ygd2hldGhlciB0byBs
b2FkIGEgY29uZmlnIGZpbGUgYXQgYWxsLCBpdCBpcyBub3cgcmVxdWlyZWQgdG8gc3BlY2lmeSBh
IHJlc3BlY3RpdmUgImNvbmZpZ0xvY2F0aW9uIiB0byBsb2FkIGEgIi9oaWJlcm5hdGUuY2ZnLnht
bCIgZmlsZS4gUHJldmlvdXNseSwgdGhpcyB3YXMgdGhlIGRlZmF1bHQgd2hlbiBubyBsb2NhdGlv
biB3YXMgZ2l2ZW4uIEFkbWl0dGVkbHksIGV4aXN0aW5nIExvY2FsU2Vzc2lvbkZhY3RvcnlCZWFu
IGRlZmluaXRpb25zIGhhdmUgdG8gYmUgYWRhcHRlZCwgYnV0IEkgcHJlZmVyIGNsZWFyIGJlaGF2
aW9yIGluIHRoaXMgY2FzZS4NCg0KVGhlIExvY2FsUGVyc2lzdGVuY2VNYW5hZ2VyRmFjdG9yeUJl
YW4gZm9yIEpETyB3b3JrcyBpbiBhIHNpbWlsYXIgZmFzaGlvbiwgc3VwcG9ydGluZyBhICJjb25m
aWdMb2NhdGlvbiIgcG9pbnRpbmcgdG8gYSBKRE8gcHJvcGVydGllcyBmaWxlLCBhbmQgImpkb1By
b3BlcnRpZXMiIHRvIHNldCB0aGUgcHJvcGVydGllcyBkaXJlY3RseS4gTGlrZSBMb2NhbFNlc3Np
b25GYWN0b3J5QmVhbiwgaXQgd2lsbCBhbHNvIG1lcmdlIHRoZSBzZXR0aW5ncyB3aGVuIGJvdGgg
YSBmaWxlIGFuZCBsb2NhbCB2YWx1ZXMgYXJlIHNwZWNpZmllZC4NCg0KImNvbmZpZ0xvY2F0aW9u
IiB2YWx1ZXMgd2lsbCBhbHdheXMgZ2V0IGludGVycHJldGVkIGFzIGNsYXNzbG9hZGVyIHJlc291
cmNlIHBhdGggbm93LiBJJ3ZlIHJlbW92ZWQgdGhlIFVSTCBjaGVjayBmcm9tIGJvdGggTG9jYWxT
ZXNzaW9uRmFjdG9yeUJlYW4gYW5kIExvY2FsUGVyc2lzdGVuY2VNYW5hZ2VyRmFjdG9yeUJlYW4s
IGFzIHVzaW5nIGEgVVJMIGlzbid0IHJlY29tbWVuZGVkIGF0IGFsbC4gVGhlIFVSTCBjaGVjayB3
aXRoIGNsYXNzcGF0aCBmYWxsYmFjayBjb21wbGljYXRlZCB0aGUgYmVoYXZpb3Igc29tZXdoYXQu
DQoNCk9mIGNvdXJzZSwgSSd2ZSBhZGFwdGVkIHRoZSBkb2NzIGFuZCB0aGUgd2ViYXBwLWhpYmVy
bmF0ZSBza2VsZXRvbiBhY2NvcmRpbmdseSA6LSkNCg0KUmVnYXJkcywNCkp1ZXJnZW4NCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FU
XSANClNlbnQ6IE1vbmRheSwgSnVseSAwNywgMjAwMyAxMDoyNiBQTQ0KVG86IHNwcmluZ2ZyYW1l
d29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpTdWJqZWN0OiBbU3ByaW5nZnJh
bWV3b3JrLWRldmVsb3Blcl0gTGF0ZXN0IGFkZGl0aW9ucw0KDQoNCkhpIGV2ZXJ5Ym9keSwNCiAN
CkEgc3VtbWFyeSBvZiBteSBsYXRlc3QgYWRkaXRpb25zIHRvIENWUzoNCiANCjEuDQpDR0xJQiBz
dXBwb3J0IGluIHRoZSBBT1AgZnJhbWV3b3JrOiBJZiBubyBwcm94eSBpbnRlcmZhY2VzIGFyZSBz
cGVjaWZpZWQsIGEgQ0dMSUIgcHJveHkgaXMgY3JlYXRlZCBmb3IgdGhlIG9yaWdpbmFsIGNsYXNz
LiBUaHVzLCBhbnkgY2xhc3MgY2FuIGdldCBwcm94aWVkIGFuZCBpbnRlcmNlcHRlZCBub3csIGFz
IGxvbmcgYXMgaXQgZG9lc24ndCBoYXZlIGZpbmFsIG1ldGhvZHMgKENHTElCIGNyZWF0ZXMgcnVu
dGltZSBzdWJjbGFzc2VzKS4gRm9yIHByb3h5IGludGVyZmFjZXMsIHRoZSBBT1AgZnJhbWV3b3Jr
IHdpbGwgc3RpbGwgY3JlYXRlIHN0YW5kYXJkIEoyU0UgMS4zIGR5bmFtaWMgcHJveHkuIE5vdGUg
dGhhdCB0aGUgZnJhbWV3b3JrIGRvZXNuJ3QgaGF2ZSBhIHJ1bnRpbWUgZGVwZW5kZW5jeSBvbiBD
R0xJQiwgYXMgbG9uZyBhcyB5b3UgZG9uJ3QgZm9yY2UgaXQgdG8gY3JlYXRlIENHTElCIHByb3hp
ZXMuDQogDQoyLg0KUmV3b3JrZWQgUHJvcGVydHlSZXNvdXJjZUNvbmZpZ3VyZXIgYW5kIGludHJv
ZHVjZWQgQmVhbkZhY3RvcnlQb3N0UHJvY2Vzc29yOiBUbyBlbmFibGUgb3ZlcnJpZGluZyBvZiBi
ZWFuIHByb3BlcnR5IHZhbHVlcyBiZWZvcmUgaW5zdGFudGlhdGlvbiBvZiBhbnkgc2luZ2xldG9u
cywgSSd2ZSBjcmVhdGVkIGEgbmV3IGhvb2sgdGhhdCBhbGxvd3MgZm9yIGN1c3RvbSBwb3N0LXBy
b2Nlc3Npbmcgb2YgYSBmcmVzaGx5IHBhcnNlZCBiZWFuIGZhY3RvcnkuIEluaXRpYWxpemluZyBi
ZWFucyB0aHVzIHJlY2VpdmUgdGhlIG1vZGlmaWVkIHByb3BlcnR5IHZhbHVlcyBpbiB0aW1lLiBQ
cm9wZXJ0eVJlc291cmNlQ29uZmlndXJlciBvZmZlcnMgdGhlIHNhbWUgdXNhZ2UgYXMgYmVmb3Jl
LCBidXQgZ2V0cyBpbnZva2VkIGF0IGJlYW4gZGVmaW5pdGlvbiB0aW1lIG5vdywgbm90IGFmdGVy
IGNvbXBsZXRlZCBpbml0aWFsaXphdGlvbiBvZiB0aGUgd2hvbGUgY29udGV4dC4NCiANCjMuDQpS
ZXdvcmtlZCBIaWJlcm5hdGVUcmFuc2FjdGlvbk1hbmFnZXIncyBEYXRhU291cmNlIHN1cHBvcnQ6
IEZvcm1lcmx5LCBIaWJlcm5hdGVUcmFuc2FjdGlvbk1hbmFnZXIgd2FzIGFibGUgdG8gZXhwb3J0
IHRoZSBKREJDIENvbm5lY3Rpb24gYmVoaW5kIGEgY3VycmVudCBIaWJlcm5hdGUgdHJhbnNhY3Rp
b24gZm9yIHBsYWluIEpEQkMgYWNjZXNzIHZpYSBEYXRhU291cmNlVXRpbHMsIGZvciBhIGdpdmVu
IERhdGFTb3VyY2UuIE5vdywgdGhlIERhdGFTb3VyY2UgaXMgbm90IGp1c3QgdXNlZCBhcyBrZXkg
dGhhdCBzaG91bGQgbWF0Y2ggdGhlIEhpYmVybmF0ZSBjb25maWd1cmF0aW9uJ3MgY29ubmVjdGlv
biBwcm92aWRlciAodHlwaWNhbGx5IHBvaW50aW5nIHRvIHRoZSBzYW1lIEpOREkgRGF0YVNvdXJj
ZSksIGJ1dCBhcyBhY3R1YWwgY29ubmVjdGlvbiBwcm92aWRlciBmb3IgSGliZXJuYXRlIHNlc3Np
b25zLg0KIA0KVGhlcmVmb3JlLCB3aGVuIHNwZWNpZnlpbmcgYm90aCBhIFNlc3Npb25GYWN0b3J5
IGFuZCBhIERhdGFTb3VyY2UgdmlhIFNwcmluZywgSGliZXJuYXRlJ3Mgb3duIGNvbmZpZ3VyYXRp
b24gZG9lc24ndCBuZWVkIHRvIGNvbmZpZ3VyZSBhIGNvbm5lY3Rpb24gcHJvdmlkZXIgYW55bW9y
ZS4gSXQgc2ltcGx5IHVzZXMgU3ByaW5nJ3MsIGJlIGl0IGEgSk5ESSBEYXRhU291cmNlLCBhIEph
a2FydGEgQ29tbW9ucyBEQkNQIG9uZSwgb3IgYSBEcml2ZXJNYW5hZ2VyRGF0YVNvdXJjZS4gTm90
ZSB0aGF0IGRhdGEgYWNjZXNzIGNvZGUgc2hvdWxkIHBhc3MgYm90aCB0aGUgU2Vzc2lvbkZhY3Rv
cnkgYW5kIHRoZSBEYXRhU291cmNlIHRvIEhpYmVybmF0ZVRlbXBsYXRlIHJlc3AuIFNlc3Npb25G
YWN0b3J5VXRpbHMgdGhlbi4gSWYgbm8gRGF0YVNvdXJjZSBpcyBzcGVjaWZpZWQsIHRoZSBTZXNz
aW9uRmFjdG9yeSB3aWxsIGZhbGwgYmFjayB0byBIaWJlcm5hdGUtcHJvdmlkZWQgSkRCQyBjb25u
ZWN0aW9ucy4NCiANCldlJ3JlIHVzaW5nIHRoaXMgZm9yIGRldmVsb3BtZW50IGF0IHdlcmszQVQ6
IFRvIHN3aXRjaCBiZXR3ZWVuIG11bHRpcGxlIGRhdGFiYXNlcyBxdWlja2x5LCB3ZSB1c2UgQW50
IHRvIHdyaXRlIGEgc3BlY2lmaWMgImRhdGFTb3VyY2UudXJsIiB2YWx1ZSBpbiBhIFByb3BlcnR5
UmVzb3VyY2VDb25maWd1cmVyIHByb3BlcnRpZXMgZmlsZSB0aGF0IG92ZXJyaWRlcyB0aGUgYXBw
bGljYXRpb24gY29udGV4dCdzIGRlZmF1bHQgdmFsdWVzLiBEdWUgdG8gYm90aCBvZiB0aGUgYWJv
dmUgY2hhbmdlcywgdGhpcyB3b3JrcyBuaWNlbHkgd2l0aCBIaWJlcm5hdGUgdG9vLCBldmVuIGlm
IGluaXRpYWxpemluZyBhdCBzdGFydHVwLiBGb3JtZXJseSwgd2Ugd291bGQgaGF2ZSBoYWQgdG8g
bW9kaWZ5IGVpdGhlciBIaWJlcm5hdGUncyBvd24gY29uZmlndXJhdGlvbiAobG9zaW5nIERhdGFT
b3VyY2Ugc2hhcmluZyB3aXRoIHBsYWluIEpEQkMgY29kZSksIG9yIHRoZSBKMkVFIGNvbnRhaW5l
ciBjb25maWd1cmF0aW9uIChzaGFyaW5nIHZpYSBhIEpOREkgRGF0YVNvdXJjZSkgLSB1c2luZyBh
IGN1c3RvbSBwcm9wZXJ0aWVzIGZpbGUgdG8gYWNoaWV2ZSB0aGlzIGlzIG11Y2ggbmljZXIuDQog
DQo0Lg0KUmV3b3JrZWQgbW9jayBKTkRJIGltcGxlbWVudGF0aW9uIC0gbm93IGNhbGxlZCAiU2lt
cGxlTmFtaW5nQ29udGV4dCIuIEkndmUgbm90IG9ubHkgcG9saXNoZWQgdGhlIGNvZGUgYW5kIHRo
ZSBkb2NzIGJ1dCBhbHNvIGltcGxlbWVudGVkIGEgbGFyZ2VyIHBhcnQgb2YgSk5ESS4gU3ViY29u
dGV4dHMgYXJlIHN1cHBvcnRlZCBub3csIHNvIHN0YW5kYXJkIEpOREkgY29kZSBsaWtlIHRoZSBm
b2xsb3dpbmcgd29ya3Mgbm93IHRvbzoNCiANCkluaXRpYWxDb250ZXh0IGN0eCA9IG5ldyBJbml0
aWFsQ29udGV4dCgpOw0KQ29udGV4dCBzdWJDdHggPSBjdHgubG9va3VwKCJqYXZhOmNvbXAvZW52
Iik7DQpEYXRhU291cmNlIGRzID0gc3ViQ3R4Lmxvb2t1cCgiamRiYy9teWRzIik7DQogDQpGb3Jt
ZXJseSwganVzdCBhIGRpcmVjdCBsb29rdXAgZm9yIHRoZSB3aG9sZSBsb2NhdGlvbiB3b3VsZCBo
YXZlIHdvcmtlZC4gRnVydGhlcm1vcmUsIHRoZSBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBib3Ro
IE5hbWluZ0VudW1lcmF0aW9ucyBub3c6ICJsaXN0IiAod2l0aCBOYW1lQ2xhc3NQYWlycykgYW5k
ICJsaXN0QmluZGluZ3MiICh3aXRoIEJpbmRpbmdzKS4NCiANCiANCkp1ZXJnZW4NCk4YSFNe6ZqK
Wyl7KFtaem7opbQENETXrHcl2Kc2aRdsESZ4K2xqd0VqenowDidayal6e14wdlwTYkrbnUROG23a
st61YnJLJg0KP8a0XTRO3YpaOm03XypreB/FoHXell5mKSstSgdqZx16Ky0ux58eYWxiLHkr3rdi
Pystd2t4H8Wgdd6WXg0K

[Springframework-developer] Re: Locale in rowmap?

[<pr...@se...>]

>> I would agree with Ken here - we must avoid any dependencies 
>> between the JDBC framework and the Web framework.

+1 We use it for both webapp and desktop clients

Trevor D. Cook

Re: [Springframework-developer] Locale in rowmap?

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

Rod Johnson wrote:

>>I would agree with Ken here - we must avoid any dependencies between the
> 
> JDBC
> 
>>framework and the Web framework.
> 
> 
> +1. I know of several companies in the UK using JDBC only at this point.
> It's a great route in for Spring.

+1. To keep JDBC framework seperate.  Rutgers is using the JDBC 
framework in conjuntion with our uPortal project.

Bill

RE: [Springframework-developer] Who's using Spring

[<pr...@se...>]

I think this is a great idea but what is the criteria for who can go on the 
page (what "qualifies" them as a "spring company").  This could be either 
developers who use Spring or websites that feature Spring.  It also should 
specify whether they get added if they are currently using Spring in 
development, or if they have a released project/website utilizing Spring (in 
some stage - alpha, beta - charlie :) - production).  I think that since 
Spring is much more than a webapp we should include everyone who uses Spring, 
but because Spring will probably get the majority of press (at least 
initially) as a competing web framework (compared to Struts or WebWorks for 
example) that we should highlight websites powered by Spring.  I would 
personally suggest 2 sections for the page.  First a "Used by" section for 
develeopers/companies using Spring in their products (whether webapp, client 
apps, etc.).  This would mainly contain software/consulting companies and 
large companies (insurance/banks/universities) who use it in-house.  I would 
then create a second section called "Powered by" for websites based on 
Spring.  The two labels (used/powered) can be changed to whatever everyone 
thinks, but I'm just presenting the concept.  While some companies may be 
listed in both sections, I think the benefit is that we highlight the power of 
Spring as a general framework AND as a web framework.  I would also vote that 
they should have at least a beta product or deployed website, otherwise we'll 
get everyone and their brother on the list. We'll have to trust "internal" 
companies which don't release products publically, but these are simply 
guidelines people will read when asking (or being solicited) to be on the list 
(not a gestapo-like attack squad to hunt down the "unworthy" :) ).

The second issue is what info we should include.  We could have name, logo, 
location (at various levels from country to actual address), website, company 
blurb (who they are - although these could get long and annoying), spring 
blurb (why/how they use it), industry, and probably others I'm not thinking 
of.  My vote would be for: Company Name, hyperlinked logo to website (if no 
logo use text), country, and industry (although I would recommend we create a 
fairly general industry with things like "software" and "education" or it will 
get way too specific like "Distributed CRM Software Consulting").

Anyway, that's my 2 cents.  Also, I have permission from my boss and the 
current/future companies to place them on this list.  Once we formalize the 
list criteria and info we want I'll fire it off.  We should also specify where 
to send this info for the list (do we post it to sourceforge or is there a 
specific email address this stuff should go to).  Other ideas/comments?

Trevor D. Cook

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: July 10, 2003 1:10 PM
To: spr...@li...
Subject: [Springframework-developer] Who's using Spring


That thought about JDBC usage reminds me: it would be great if we could have
a list, or logos, of companies and organizations using Spring.

Can we build a list and check permission as necessary?

Some starting thoughts...

Rutgers University
Werk3AT clients?
fotosource

I can check with a couple of companies in  the UK as to whether they'd be
happy to be listed.

Regards,
Rod

RE: [Springframework-developer] Who's using Spring

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

http://www.rutgers.edu/

By the end of the month, if anything goes smoothly, we should have the
"Graduate Admission System" (GAS) - online application, phase1, release
using Spring. I'll send a link when we deploy it to production.

Regards,
Dmitriy.

-----Original Message-----
From: Alef Arendsen [mailto:al...@jt...] 
Sent: Friday, July 11, 2003 11:32 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Who's using Spring


Well, you can list us if you want (JTeam B.V. Netherlands -
www.jteam.nl)

Within a couple of weeks, we'll have our first operational website using
Spring, I'll send you the address when it's finished.

Alef

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens Rod
Johnson
Verzonden: Thursday, July 10, 2003 7:10 PM
Aan: spr...@li...
Onderwerp: [Springframework-developer] Who's using Spring


That thought about JDBC usage reminds me: it would be great if we could have
a list, or logos, of companies and organizations using Spring.

Can we build a list and check permission as necessary?

Some starting thoughts...

Rutgers University
Werk3AT clients?
fotosource

I can check with a couple of companies in  the UK as to whether they'd be
happy to be listed.

Regards,
Rod




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Who's using Spring

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

Well, you can list us if you want (JTeam B.V. Netherlands -
www.jteam.nl)

Within a couple of weeks, we'll have our first operational website using
Spring, I'll send you the address when it's finished.

Alef

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Rod Johnson
Verzonden: Thursday, July 10, 2003 7:10 PM
Aan: spr...@li...
Onderwerp: [Springframework-developer] Who's using Spring


That thought about JDBC usage reminds me: it would be great if we could
have a list, or logos, of companies and organizations using Spring.

Can we build a list and check permission as necessary?

Some starting thoughts...

Rutgers University
Werk3AT clients?
fotosource

I can check with a couple of companies in  the UK as to whether they'd
be happy to be listed.

Regards,
Rod




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] JavaBeans lifecycle considerations?

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

UC5TLjogSSd2ZSBvYnZpb3VzbHkgcmVuYW1lZCBvdXIgYmVhbnMgIkxpZmVjeWNsZSIgdG8gIkJl
YW5GYWN0b3J5QXdhcmUiIChhbHJlYWR5IGNvbW1pdHRlZCksIGJlY2F1c2UgdGhhdCdzIHdoYXQg
aXQgcmVhbGx5IGlzIGF0IHRoZSBtb21lbnQsIGp1c3QgbGlrZSBBcHBsaWNhdGlvbkNvbnRleHRB
d2FyZS4NCg0KQlRXLCBJJ3ZlIGp1c3QgdGFnZ2VkICJyZWxlYXNlLTAuOSIsIHNwZWNpZnlpbmcg
MjAwMy0wNi0yNiBhcyBkYXRlLiBUaGF0IG1lYW5zIHdlIG5vdyBoYXZlIGEgcHJvcGVyIDAuOSB0
YWcsIGRlc3BpdGUgbXkgb3JpZ2luYWwgZm9yZ2V0ZnVsbmVzcy4uLg0KDQpKdWVyZ2VuDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJvZC5qb2huc29uQGludGVyZmFjZTIx
LmNvbSBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0NClNlbnQ6IEZyaWRheSwg
SnVseSAxMSwgMjAwMyA1OjE3IFBNDQpUbzogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXQ0KQ2M6
IEl2YW4gUmlzdGljOyBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdl
Lm5ldA0KU3ViamVjdDogUkU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBKYXZhQmVhbnMg
bGlmZWN5Y2xlDQpjb25zaWRlcmF0aW9ucz8NCg0KDQo+SW50cm9kdWNpbmcgYSBzZXJ2aWNlIGxp
ZmVjeWNsZSBpbnRlcmZhY2UgKHdpdGggc3RhcnQvc3RvcCANCmNhbGxiYWNrcykgYW5kIHJlY29u
ZmlndXJhdGlvbiBjYXBhYmlsaXRpZXMgc2hvdWxkIGJlIA0Kc3RyYWlnaHRmb3J3YXJkLiBZb3Ug
YXJlIHZlcnkgd2VsY29tZSB0byBqb2luIHVzIGFuZCB3b3JrIG9uIA0KdGhpcyEgDQoNClllcywg
Y29udHJpYnV0aW9uIGlzIHZlcnkgd2VsY29tZS4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIA0K
ZGVmaW5pdGVseSBzb21ldGhpbmcgZm9yIHRoZSAxLjEgcmVsZWFzZSwgbm90IDEuMC4gQXMgSnVl
cmdlbiANCm5vdGVkLCBzbyBmYXIgd2UgaGF2ZW4ndCBoYWQgbXVjaCBuZWVkIGZvciBhIHN0b3Ao
KSBjb25jZXB0LiANClBlcmhhcHMgaXQgd291bGQgYmUgYSBnb29kIHN0YXJ0IHRvIGZvcm11bGF0
ZSB5b3VyIA0KcmVxdWlyZW1lbnRzLCBhbmQgd2hhdCBlbmhhbmNlbWVudHMgdGhlIFNwcmluZyBs
aWZlY3ljbGUgDQptaWdodCBuZWVkIHRvIHN1cHBvcnQgdG8gYWRkcmVzcyB0aGVtLg0KDQpSZWdh
cmRzLA0KUm9kDQo=

RE: [Springframework-developer] JavaBeans lifecycle considerations?

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

>Introducing a service lifecycle interface (with start/stop 
callbacks) and reconfiguration capabilities should be 
straightforward. You are very welcome to join us and work on 
this! 

Yes, contribution is very welcome. Please note that this is 
definitely something for the 1.1 release, not 1.0. As Juergen 
noted, so far we haven't had much need for a stop() concept. 
Perhaps it would be a good start to formulate your 
requirements, and what enhancements the Spring lifecycle 
might need to support to address them.

Regards,
Rod

RE: [Springframework-developer] JavaBeans lifecycle considerations?

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

Hi Ivan,

Component lifecycles have already been discussed at some time, but the =
current support is rather minimal as there hasn't been much need for =
more sophisticated one yet.

Currently, we offer 3 kinds of initialization callbacks:
- "InitializingBean": just an "afterPropertiesSet()" callback after =
populating the bean properties;=20
- "BeanFactoryAware": a "setBeanFactory(BeanFactory)" callback to supply =
the containing factory to the bean instance;
- "ApplicationContextAware": a =
"setApplicationContext(ApplicationContext)" callback to supply the =
containing context to the bean instance.

The latter is only available within a Spring application context, =
offering not just bean factory capabilities but also pluggable message =
sources, resource retrieval (adapted per environment, e.g. file / =
classpath / web context), etc. There's also a convenient =
"ApplicationObjectSupport" base class that implements it, providing an =
"initApplicationContext()" callback.

InitializingBean is often used for simple initialization that depends on =
multiple bean properties, without making the bean aware of anything =
else. BeanFactoryAware is rarely necessary, as most bean references can =
be supplied via respective bean properties anyway. =
ApplicationContextAware provides the bean with full capabilities of a =
Spring application context, e.g. for retrieving custom config files.

Introducing a service lifecycle interface (with start/stop callbacks) =
and reconfiguration capabilities should be straightforward. You are very =
welcome to join us and work on this! Rod and me will be happy to provide =
you with details on the current bean factory and application context =
concepts :-)

Regards,
Juergen


-----Original Message-----
From: Ivan Ristic [mailto:iv...@we...]
Sent: Friday, July 11, 2003 2:01 PM
To: spr...@li...
Subject: [Springframework-developer] JavaBeans lifecycle considerations?



I read the container documentation at=20
http://www.springframework.org/docs/lightweight_container.html
with great interest. I really like the "natural" JavaBeans approach.

Are there any mechanisms in the container framework to handle
component lifecycle? Such as start (possibly to run on its own
thread), stop, dispose?

There is one sentence in the document where you talk how Spring
will support reconfiguration in the future. Are there any concrete
plans for this or are other developers (such as myself 0:) invited
to join and suggest ideas?

I have some ideas and I would rather implement them as part of an
existing framework than create yet-another-framework that no one
except me will use.

--=20
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] JavaBeans lifecycle considerations?

[Ivan R. <iv...@we...>]

I read the container documentation at 
http://www.springframework.org/docs/lightweight_container.html
with great interest. I really like the "natural" JavaBeans approach.

Are there any mechanisms in the container framework to handle
component lifecycle? Such as start (possibly to run on its own
thread), stop, dispose?

There is one sentence in the document where you talk how Spring
will support reconfiguration in the future. Are there any concrete
plans for this or are other developers (such as myself 0:) invited
to join and suggest ideas?

I have some ideas and I would rather implement them as part of an
existing framework than create yet-another-framework that no one
except me will use.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

RE: [Springframework-developer] TSS mailshot

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

Guys,

I've just got the TSS mailshot (as I guess you all have as 
well). There's a link to the Spring release in it. I know 
from experience, this is going to keep our page views up for 
at least a week or two, beyond the users who've already seen 
the thread.

Regards,
Rod

RE: [Springframework-developer] Questions and additions

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

<quote>BTW, how exactly does your TilesView work? As far as I know,
Tiles can be largely used as tag library, without the need for dedicated
integration. The most interesting usage for integration is probably with
content definitions - a la
http://www.javaworld.com/javaworld/jw-01-2002/jw-0104-tilestrut.html
Solution 6, but with Spring instead of Struts. Do you intend to offer a
solution for this, basically a Spring View that renders such content
definitions that consist of Tiles components?</quote>
Exactly! That's what it already does. I've made the TilesViewResolver to
be configurable from the xxx-servlet.xml (see code below). It searches
for the factory and stuff. The TilesView basically is the same as the
integration in Struts, where you can 'forward' to a definition using the
ActionForward. It's kind of simple. The only thing that needs to be
tested a little bit is the Tiles Controller concept (where you can
attach a controller to each tile, that retrieve data for this specific
tile). I hardly ever use this, but well, other people might.

<quote>Regarding code structure, I'm not entirely sure why you need a
TilesViewResolver - what resolution functionality does it add? Wouldn't
TilesView instances, each defining a content page as arranged Tiles
components, work too when they get configured via
ResourceBundleViewResolver or XmlViewResolver?</quote>
Hmm, you might be right here... I'll have a look into that... Anyway,
I've attached the files like they are right now... Just FYI. Don't mind
the packagenames and stuff, documentation still needs to be done... Any
suggestions? Always welcome...

<quote>I'm looking forward to your code! Thanks for your
efforts!</quote>
No problem, It's a cool framework, worth of adding features in order to
make it fit my (and other's) needs more...


---- xxx-servlet.xml ----
<bean id="viewResolver"
class="jteam.jbosssupport.web.util.TilesViewResolver">
        <property name="factoryClass">
 
<value>org.apache.struts.tiles.xmlDefinition.I18nFactorySet</value>
        </property>
        <property name="definitions">
            <props>
			<!-- this is a little weird, definitionfiles
mapped to descriptions -->
                <prop key="/WEB-INF/defs/general.xml">The General
resources</prop>
                <prop key="/WEB-INF/defs/widgets.xml">Some often used
widgets</prop>
                <prop key="/WEB-INF/defs/administrator.xml">Some often
used widgets</prop>
                <prop key="/WEB-INF/defs/customer.xml">Customer
definitions</prop>
                <prop key="/WEB-INF/defs/templates.xml">Often used
templates</prop>
            </props>
        </property>
</bean>

Re: [Springframework-developer] Tags using expression language??

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

QWxlZiwNCiANCkkndmUganVzdCBicm93c2VkIHlvdXIgY29kZSAtIHRoaXMgbG9va3MgdmVyeSBp
bnRlcmVzdGluZyEgSXQgbWFrZXMgaXRlcmF0aW5nIHN1Y2ggcmVwZXRpdGl2ZSBmb3JtIGZpZWxk
cyBsaWtlIGluIHRoZSBwZXRjbGluaWMgbXVjaCBlYXNpZXIuIEknbGwgaGF2ZSBhIGxvb2sgYXQg
dGhlIGltcGxlbWVudGF0aW9uIGRldGFpbHMsIGFuZCBpZiBldmVyeXRoaW5nIHdvcmtzIG91dCBJ
J2xsIGFkZCBhIGNsZWFuIHJvb20gdmVyc2lvbiB0byB0aGUgbWFpbiBzb3VyY2UgdHJlZSBwcm9t
cHRseS4NCiANCkkgd29uZGVyIGlmIHdlIGNvdWxkIG1ha2UgdGhhdCB3b3JrIHdpdGggYW55IEpT
VEwgaW1wbGVtZW50YXRpb24sIG5vdCBqdXN0IHRoZSBKYWthcnRhIG9uZSwgYWx0aG91Z2ggSSB3
b3VsZG4ndCBtaW5kIGEgZGVwZW5kZW5jeSBvbiB0aGUgbGF0dGVyIGZvciB0aGlzIGZlYXR1cmUu
DQogDQpDb29sIHN0dWZmIDotKQ0KIA0KSnVlcmdlbg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8bmds
aWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IEFsZWYgQXJlbmRzZW4gW21haWx0bzphbGVmQGp0
ZWFtLm5sXSANCglHZXNlbmRldDogRGkgMDguMDcuMjAwMyAxOTo0MyANCglBbjogasO8cmdlbiBo
w7ZsbGVyIFt3ZXJrM0FUXTsgc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQgDQoJQ2M6IA0KCUJldHJlZmY6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl
cl0gVGFncyB1c2luZyBleHByZXNzaW9uIGxhbmd1YWdlPz8NCgkNCgkNCg0KCU9rLCBoZXJlIHdl
IGdvLi4uDQoJDQoJTGlrZSB5b3Ugc2FpZCwgYXQgZmlyc3QgZ2xhbmNlLCBpdCBkb2VzIG5vdCBs
b29rIGxpa2UgdGhlIGkyMTpiaW5kIHRhZw0KCW5lZWRzIGV4cHJlc3Npb25hbGl6YXRpb24gKGht
bW0sIG5pY2UgaHVoIDstKS4gSG93ZXZlciwgaW4gdGhlIHBldGNsaW5pYw0KCWRlbW8gYXBwIEkn
bSBzZWVpbmcgYSBsb3Qgb2YgaW5wdXQuanNwcyBpbiB0aGUganNwL2ZpZWxkcyBkaXJlY3Rvcnku
DQoJVGhlc2UgYXJlIHRoaW5ncyBJJ20gaG9waW5nIHRvIHNvbHZlIHVzaW5nIGZvciBpbnN0YW5j
ZSBFTC1iYXNlZCB0YWdzLi4uDQoJQXR0YWNoZWQgeW91J2xsIGZpbmQgYSByZXdvcmtlZCB2ZXJz
aW9uIG9mIHRoZSBvd25lckZvcm0uIEl0IGRvZXMgbm90DQoJdXNlIHRoZSBKU1BzIGZyb20gdGhl
IGZpZWxkcyBkaXJlY3RvcnkgYW55bW9yZSwgYnV0IHVzZXMgb25seSBvbmUNCglpbnB1dC5qc3Ag
dGhhdCB1c2VzIHRoZSBiaW5kc3RhdHVzIG9iamVjdCB0byBjcmVhdGUgdGhlIGlucHV0IGZpZWxk
Lg0KCQ0KCU9rLCBpdCdzIHN0aWxsIGFsbCByb3VnaCBhbmQgcmV3b3JraW5nIHRoZSB0YWdzIGlz
IGEgbGl0dGxlIGJpdCBtb3JlDQoJd29yayB0aGFuIHRoZSAxNSBtaW51dGVzIEkgc3BlbnQgb24g
aXQgbm93LCBidXQgbWF5YmUgeW91J3JlIGdldHRpbmcgdGhlDQoJaWRlYS4NCgkNCglDb25zZXF1
ZW5jZXMgZm9yIGFkZGluZyAvIHJld29ya2luZyB0aGUgdGFnczoNCgkNCgkxLiBkZXBlbmRlbmN5
IG9uIGpha2FydGEtanN0bC0xLjAuMyAoamFrYXJ0YS5hcGFjaGUub3JnL3RhZ2xpYiAtLT4NCglz
dGFuZGFyZCkuDQoJMi4gZGVwZW5kZW5jeSBvbiBqc3RsLTEuMC4zIChqYXZhLnN1bi5jb20pDQoJ
My4gSW4gY2FzZSB5b3Ugd2FudCB0byBoYXZlIGJvdGggdmVyc2lvbiBpbiB0aGVyZSwgYW4gZXh0
ZW5kaW5nIGNsYXNzDQoJZm9yIGVhY2ggdGFnDQoJNC4gRm9yIGVhY2ggdGFnLCBhIEJlYW5JbmZv
IGNsYXNzDQoJNS4gSSB3YXNuJ3QgYWJsZSB0byB1c2UgdGhlIEV2YWxIZWxwZXIgZnJvbSBqYWth
cnRhLCBzbyBJIGNvcGllZCBpdA0KCShobW1tLi4uIG5vdCBzbyBuaWNlLCBpcyBpdCA7LSkNCgkN
CglQcm9iYWJseSBJIGRvbid0IGhhdmUgdGltZSB0aGlzIHdlZWsgb3Igc29tZXRoaW5nIHRvIHJl
ZmFjdG9yIHRoZW0gdG8gYmUNCglhbGwgRUwtYmFzZWQuLi4gSnVzdCBsZXQgbWUga25vdyBpZiB5
b3UnZCBsaWtlIGl0Lg0KCQ0KCVdlbGwsIHRoYXQncyBpdCBmb3Igbm93LCBzdGlsbCBkaXNjb3Zl
cmluZyByZWFsbHkgY29vbCBmZWF0dXJlcyBhbmQNCglhbHJlYWR5IHJ1bm5pbmcgb3V0IChicmFp
biltZW1vcnkgdG8gdGhpbmsgdXAgZXZlcnl0aGluZyBJIGNvdWxkIGRvIHdpdGgNCglTcHJpbmcg
Oy0pDQoJDQoJQ2hlZXJzLA0KCQ0KCUFsZWYNCgkNCg0K

Re: [Springframework-developer] Questions and additions

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

SGkgQWxlZiwNCiANCkFjdHVhbGx5IEkndmUgbG9va2VkIGludG8gVGlsZXMgKGluY2x1ZGluZyBp
dHMgc291cmNlIGNvZGUpIHNvbWUgd2Vla3MgYWdvLCBhbmQgaGFkIHRvIGZpbmQgb3V0IHRoYXQg
aXQncyBxdWl0ZSBoZWF2aWx5IG1lcmdpbmcgd2l0aCBTdHJ1dHMgdG9vLiBJIGxpa2UgdGhlIGlk
ZWEgb2YgVGlsZXMsIGJ1dCBJIGRvbid0IGxpa2UgdGhhdCBzdHJvbmcgU3RydXRzIGRlcGVuZGVu
Y2llcy4gT2YgY291cnNlLCBJIHdlbGNvbWUgYSBTcHJpbmcgVGlsZXNWaWV3IHRoYXQgbWFuYWdl
cyB0byBvdmVyY29tZSB0aGUgbGF0dGVyIQ0KIA0KQW55d2F5LCBJIGRvbid0IGtub3cgaWYgeW91
J3ZlIG5vdGljZWQsIGJ1dCB3ZSBhbHJlYWR5IGhhdmUgYSBWZWxvY2l0eVZpZXcsIGEgWHNsdFZp
ZXcsIGEgUGRmVmlldywgYW5kIGFuIEV4Y2VsVmlldy4gQWxsIHRob3NlIHRoaXJkIHBhcnR5IGxp
YnJhcmllcyBhcmUgaW4gQ1ZTLCBhdCBsZWFzdCB0aGUgbmVjZXNzYXJ5IG9uZXMsIGJ1dCB3ZSBk
b24ndCBpbnRlbmQgdG8gc2hpcCB0aGVtIGluIGRpc3RyaWJ1dGlvbnMuIFdlIGRvbid0IG1pbmQg
c29tZSBsaWIgbWVnYWJ5dGVzIHRoZXJlIGluIENWUyA6LSkNCiANClNvIEknbSBpbmNsaW5lZCB0
byBwdXQgdGhlIFRpbGVzIGludGVncmF0aW9uIGluIHRoZSBtYWluIHNvdXJjZSB0cmVlIHRvbywg
dW5kZXIgd2ViL3NlcnZsZXQvdmlldy90aWxlcy4gSWYgd2Ugc2VwYXJhdGUgdGhpcmQgcGFydHkg
dmlldyBpbXBsZW1lbnRhdGlvbnMgaW4gZ2VuZXJhbCwgd2Ugd291bGQgaGF2ZSB0byBhcHBseSB0
aGF0IHRvIFZlbG9jaXR5LCBYU0xULCBQREYsIGFuZCBFeGNlbCB0b28uIEZvciB0aGUgbW9tZW50
LCBsZXQncyBrZWVwIGFsbCBvZiB0aG9zZSBpbiB0aGUgbWFpbiBzb3VyY2VzLg0KIA0KQlRXLCBo
b3cgZXhhY3RseSBkb2VzIHlvdXIgVGlsZXNWaWV3IHdvcms/IEFzIGZhciBhcyBJIGtub3csIFRp
bGVzIGNhbiBiZSBsYXJnZWx5IHVzZWQgYXMgdGFnIGxpYnJhcnksIHdpdGhvdXQgdGhlIG5lZWQg
Zm9yIGRlZGljYXRlZCBpbnRlZ3JhdGlvbi4gVGhlIG1vc3QgaW50ZXJlc3RpbmcgdXNhZ2UgZm9y
IGludGVncmF0aW9uIGlzIHByb2JhYmx5IHdpdGggY29udGVudCBkZWZpbml0aW9ucyAtIGEgbGEg
aHR0cDovL3d3dy5qYXZhd29ybGQuY29tL2phdmF3b3JsZC9qdy0wMS0yMDAyL2p3LTAxMDQtdGls
ZXN0cnV0Lmh0bWwgU29sdXRpb24gNiwgYnV0IHdpdGggU3ByaW5nIGluc3RlYWQgb2YgU3RydXRz
LiBEbyB5b3UgaW50ZW5kIHRvIG9mZmVyIGEgc29sdXRpb24gZm9yIHRoaXMsIGJhc2ljYWxseSBh
IFNwcmluZyBWaWV3IHRoYXQgcmVuZGVycyBzdWNoIGNvbnRlbnQgZGVmaW5pdGlvbnMgdGhhdCBj
b25zaXN0IG9mIFRpbGVzIGNvbXBvbmVudHM/DQogDQpSZWdhcmRpbmcgY29kZSBzdHJ1Y3R1cmUs
IEknbSBub3QgZW50aXJlbHkgc3VyZSB3aHkgeW91IG5lZWQgYSBUaWxlc1ZpZXdSZXNvbHZlciAt
IHdoYXQgcmVzb2x1dGlvbiBmdW5jdGlvbmFsaXR5IGRvZXMgaXQgYWRkPyBXb3VsZG4ndCBUaWxl
c1ZpZXcgaW5zdGFuY2VzLCBlYWNoIGRlZmluaW5nIGEgY29udGVudCBwYWdlIGFzIGFycmFuZ2Vk
IFRpbGVzIGNvbXBvbmVudHMsIHdvcmsgdG9vIHdoZW4gdGhleSBnZXQgY29uZmlndXJlZCB2aWEg
UmVzb3VyY2VCdW5kbGVWaWV3UmVzb2x2ZXIgb3IgWG1sVmlld1Jlc29sdmVyPw0KIA0KSSdtIGxv
b2tpbmcgZm9yd2FyZCB0byB5b3VyIGNvZGUhIFRoYW5rcyBmb3IgeW91ciBlZmZvcnRzIQ0KIA0K
UmVnYXJkcywNCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0
LS0tLS0gDQoJVm9uOiBBbGVmIEFyZW5kc2VuIFttYWlsdG86YWxlZkBqdGVhbS5ubF0gDQoJR2Vz
ZW5kZXQ6IERvIDEwLjA3LjIwMDMgMjM6MzcgDQoJQW46IHJvZC5qb2huc29uQGludGVyZmFjZTIx
LmNvbSANCglDYzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5u
ZXQgDQoJQmV0cmVmZjogUkU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBRdWVzdGlvbnMg
YW5kIGFkZGl0aW9ucw0KCQ0KCQ0KDQoJPlllcywgdGhpcyBzb3VuZHMgaW50ZXJlc3RpbmcuIEJl
Y2F1c2UgaXQncyBzbyBlYXN5IHRvDQoJaW1wbGVtZW50IHZpZXdzIHdpdGggU3ByaW5nIHdlIHBy
b2JhYmx5IG5lZWQgdG8gdGhpbmsgYWJvdXQNCglob3cgdG8gb3JnYW5pemUgdGhpbmdzLiBPciBt
YXliZSBqdXN0IGluIHRoZSBtYWluIHNvdXJjZSB0cmVlDQoJYW5kIHdlYXIgdGhlIGRlcGVuZGVu
Y2llcz8NCgkNCglJIHdvdWxkIGtlZXAgdGhlbSBzZXBhcmF0ZSAoSSBldmVuIGRvbid0IGxpa2Ug
aXQgdGhhdCBJIGhhZCB0byBnZXQgaW50bw0KCXRoZSBTdHJ1dHMgc291cmNlY29kZSB0byBmaW5k
IG91dCB0aGluZ3MsIHdoZW4gaGFsZiBhIHllYXIgYWdvLCBUaWxlcw0KCWp1c3QgdXNlZCB0byBi
ZSBzZXBhcmF0ZSBwYWNrYWdlLCB0aGF0IGRlbGl2ZXJlZCBpdHMgb3duIHBsdWdpbiBmb3INCglT
dHJ1dHMpLiBJZiB0aGVyZSdzIFZlbG9jaXR5IHJlc29sdmVyIGxhdGVyIG9uIGFuZCBhIFdlYk1h
Y3JvIHJlc29sdmVyDQoJYW5kIHRoaW5ncyBsaWtlIHRoYXQsIHlvdSdsbCBlbmQgdXAgd2l0aCB0
ZW5zIG9mIG1lZ2FieXRlcyBvZiBqYXJzLi4uDQoJQWxzbywgd2hlbiB0aGVyZSdzIGEgc3RhbmRh
cmQgc3RydWN0dXJlIGZvciAnYWRkb25zJywgaXQncyBlYXNpZXIgdG8NCglkb2N1bWVudCB0aGVt
IEkgdGhpbmssIGFuZCBwZW9wbGUgY2FuIGp1c3QgcGljayB3aGF0IHRoZXkgbGlrZS4uLiBXZWxs
LA0KCXdoYXRldmVyLCBsZXQncyBqdXN0IGZpcnN0IGZpbmlzaCBpdCA7LSkuDQoJDQoJSSd2ZSBi
ZWVuIHRlc3RpbmcgYWxsIG92ZXIgd2l0aCB0aGUgVGlsZXNSZXNvbHZlciB0aGluZ3ksIGFuZCBp
dCdzDQoJd29ya2luZyBxdWl0ZSB3ZWxsLiBJIHdhbnQgdG8gdGVzdCBpdCBhIGxpdHRsZSBtb3Jl
IHRvIHNlZSBpZiBldmVyeQ0KCWZlYXR1cmUgVGlsZXMgaGFzIHdvcmtzIGFuZCB0aGVuIC0gYWZ0
ZXIgc29tZSBtb3JlIHJlYWRhYmxlDQoJZG9jdW1lbnRhdGlvbiAtIEknbGwgc2VuZCBpdC4uLg0K
CQ0KCUNoZWVycywNCgkNCglBbGVmDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YuTmV0IGVtYWlsIHNw
b25zb3JlZCBieTogUGFyYXNvZnQNCglFcnJvciBwcm9vZiBXZWIgYXBwcywgYXV0b21hdGUgdGVz
dGluZyAmIG1vcmUuDQoJRG93bmxvYWQgJiBldmFsIFdlYktpbmcgYW5kIGdldCBhIGZyZWUgYm9v
ay4NCgl3d3cucGFyYXNvZnQuY29tL2J1bGxldHByb29mYXBwczENCglfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9w
ZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9z
cHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoNCg==

[Springframework-developer] Who's using Spring

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

That thought about JDBC usage reminds me: it would be great if we could have
a list, or logos, of companies and organizations using Spring.

Can we build a list and check permission as necessary?

Some starting thoughts...

Rutgers University
Werk3AT clients?
fotosource

I can check with a couple of companies in  the UK as to whether they'd be
happy to be listed.

Regards,
Rod

RE: [Springframework-developer] Questions and additions

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

>Yes, this sounds interesting. Because it's so easy to 
implement views with Spring we probably need to think about 
how to organize things. Or maybe just in the main source tree 
and wear the dependencies?

I would keep them separate (I even don't like it that I had to get into
the Struts sourcecode to find out things, when half a year ago, Tiles
just used to be separate package, that delivered its own plugin for
Struts). If there's Velocity resolver later on and a WebMacro resolver
and things like that, you'll end up with tens of megabytes of jars...
Also, when there's a standard structure for 'addons', it's easier to
document them I think, and people can just pick what they like... Well,
whatever, let's just first finish it ;-).

I've been testing all over with the TilesResolver thingy, and it's
working quite well. I want to test it a little more to see if every
feature Tiles has works and then - after some more readable
documentation - I'll send it...

Cheers,

Alef