springframework-developer — Spring Framework developers list

RE: [Springframework-developer] successView changes

[Dion A. <di...@al...>]

Actually I just have a
org.springframework.web.servlet.view.velocity.VelocityViewResolver right
now. 

D

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...] 
Sent: Wednesday, November 10, 2004 11:00 AM
To: spr...@li...
Subject: Re: [Springframework-developer] successView changes

No. I am assuming right now you are using InternalResourceViewResolver. 
All you would need to do is define the view name literal (which should still
be in the config, not hardcoded in the controller) as

redirect:viewFoo.html

in this particular case. Then the controller can just do

return new ModelAndView(getSuccessView(), "id", theId));

InternalResourceViewResolver (or rather its superclass
UrlBasedViewResolver) will see the 'redirect:' prefix, and create and use a
RedirectView itself. So the nice thing is that that controller no longer
needs to know that there is a redirect. Now keep in mind that there's
limitations to the opacity though, in terms of whether control will go to an
internal view or to a redirect, since on a redirect all the model params
need to go on the URL. So same as before, you can't stick in any arbitrary
complex property into the model and expect to be able to do a redirect...

Colin


Dion Almaer wrote:

>So to use the new redirect: I would change from onSubmit to 
>doSubmitAction right?
>
>And then it will magically put the form object as the model and will 
>create the url from that?
>
>Cheers,
>
>Dion
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Wednesday, November 10, 2004 8:08 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] successView changes
>
>Also, if you're willing to go to CVS code (which will be 1.1.2 in a few 
>days), you can rely on the new redirect: prefix support, and get away 
>from the controller knowing that a RedirectView is used at all.
>
>
>Dion Almaer wrote:
>
>  
>
>>Colin -
>>
>>You are the man :)
>>
>>return new ModelAndView(new RedirectView(getSuccessView(), true), 
>>"id", theId));
>>
>>Is all I needed.
>>
>>Cheers,
>>
>>Dion
>>
>>
>>-----Original Message-----
>>From: Colin Sampaleanu [mailto:col...@ex...]
>>Sent: Tuesday, November 09, 2004 11:03 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] successView changes
>>
>>Dion,
>>
>>I presume you are actually using this view as a RedirectView? That's 
>>the only thing that makes sense, given that you're playing around with 
>>the name as if it's a URL, and the fact that it has .html at the end; 
>>I presume this is mapped to another controller?
>>
>>In any case, you shouldn't be manipulating the view name at all. What 
>>you should be doing is just setting the id as a model object, and 
>>letting RedirectView build the URL for you:
>> return new ModelAndView(new RedirectView(getSuccessView(), true), 
>>"id", theId));
>>
>>Now do you have a problem with the controller itself knowing the name 
>>of the param?
>>
>>Colin
>>
>>
>>Dion Almaer wrote:
>>
>> 
>>
>>    
>>
>>>Hi guys -
>>>
>>>I run into the following use case a lot:
>>>
>>>- Create a new FOO
>>>- On success I want to SHOW that FOO
>>>
>>>Ideally I would want to:
>>>
>>><property
>>>name="successView"><value>viewFoo.html?id=$request['id']</value></pro
>>>p
>>>e
>>>rty>
>>>
>>>viewFoo.html?id=$request['id]
>>>
>>>Could of course be something else like: id=$id or
>>>$request.getParameter("id") or whatever.
>>>
>>>But it would be really nice to be able to do something like this 
>>>instead of having my controller do a
>>>
>>>.... getSuccessView() + "id=" + theId ....
>>>
>>>If there another clean way to do this that I am missing?
>>>
>>>Cheers,
>>>
>>>Dion
>>>      
>>>



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

Re: [Springframework-developer] successView changes

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

No. I am assuming right now you are using InternalResourceViewResolver. 
All you would need to do is define the view name literal (which should 
still be in the config, not hardcoded in the controller) as

redirect:viewFoo.html

in this particular case. Then the controller can just do

return new ModelAndView(getSuccessView(), "id", theId));

InternalResourceViewResolver (or rather its superclass 
UrlBasedViewResolver) will see the 'redirect:' prefix, and create and 
use a RedirectView itself. So the nice thing is that that controller no 
longer needs to know that there is a redirect. Now keep in mind that 
there's limitations to the opacity though, in terms of whether control 
will go to an internal view or to a redirect, since on a redirect all 
the model params need to go on the URL. So same as before, you can't 
stick in any arbitrary complex property into the model and expect to be 
able to do a redirect...

Colin


Dion Almaer wrote:

>So to use the new redirect: I would change from onSubmit to doSubmitAction
>right?
>
>And then it will magically put the form object as the model and will create
>the url from that?
>
>Cheers,
>
>Dion
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...] 
>Sent: Wednesday, November 10, 2004 8:08 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] successView changes
>
>Also, if you're willing to go to CVS code (which will be 1.1.2 in a few
>days), you can rely on the new redirect: prefix support, and get away from
>the controller knowing that a RedirectView is used at all.
>
>
>Dion Almaer wrote:
>
>  
>
>>Colin -
>>
>>You are the man :)
>>
>>return new ModelAndView(new RedirectView(getSuccessView(), true), "id", 
>>theId));
>>
>>Is all I needed.
>>
>>Cheers,
>>
>>Dion
>>
>>
>>-----Original Message-----
>>From: Colin Sampaleanu [mailto:col...@ex...]
>>Sent: Tuesday, November 09, 2004 11:03 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] successView changes
>>
>>Dion,
>>
>>I presume you are actually using this view as a RedirectView? That's 
>>the only thing that makes sense, given that you're playing around with 
>>the name as if it's a URL, and the fact that it has .html at the end; I 
>>presume this is mapped to another controller?
>>
>>In any case, you shouldn't be manipulating the view name at all. What 
>>you should be doing is just setting the id as a model object, and 
>>letting RedirectView build the URL for you:
>> return new ModelAndView(new RedirectView(getSuccessView(), true), 
>>"id", theId));
>>
>>Now do you have a problem with the controller itself knowing the name 
>>of the param?
>>
>>Colin
>>
>>
>>Dion Almaer wrote:
>>
>> 
>>
>>    
>>
>>>Hi guys -
>>>
>>>I run into the following use case a lot:
>>>
>>>- Create a new FOO
>>>- On success I want to SHOW that FOO
>>>
>>>Ideally I would want to:
>>>
>>><property
>>>name="successView"><value>viewFoo.html?id=$request['id']</value></prop
>>>e
>>>rty>
>>>
>>>viewFoo.html?id=$request['id]
>>>
>>>Could of course be something else like: id=$id or
>>>$request.getParameter("id") or whatever.
>>>
>>>But it would be really nice to be able to do something like this 
>>>instead of having my controller do a
>>>
>>>.... getSuccessView() + "id=" + theId ....
>>>
>>>If there another clean way to do this that I am missing?
>>>
>>>Cheers,
>>>
>>>Dion
>>>      
>>>

RE: [Springframework-developer] successView changes

[Dion A. <di...@al...>]

So to use the new redirect: I would change from onSubmit to doSubmitAction
right?

And then it will magically put the form object as the model and will create
the url from that?

Cheers,

Dion

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...] 
Sent: Wednesday, November 10, 2004 8:08 AM
To: spr...@li...
Subject: Re: [Springframework-developer] successView changes

Also, if you're willing to go to CVS code (which will be 1.1.2 in a few
days), you can rely on the new redirect: prefix support, and get away from
the controller knowing that a RedirectView is used at all.


Dion Almaer wrote:

>Colin -
>
>You are the man :)
>
>return new ModelAndView(new RedirectView(getSuccessView(), true), "id", 
>theId));
>
>Is all I needed.
>
>Cheers,
>
>Dion
> 
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Tuesday, November 09, 2004 11:03 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] successView changes
>
>Dion,
>
>I presume you are actually using this view as a RedirectView? That's 
>the only thing that makes sense, given that you're playing around with 
>the name as if it's a URL, and the fact that it has .html at the end; I 
>presume this is mapped to another controller?
>
>In any case, you shouldn't be manipulating the view name at all. What 
>you should be doing is just setting the id as a model object, and 
>letting RedirectView build the URL for you:
>  return new ModelAndView(new RedirectView(getSuccessView(), true), 
>"id", theId));
>
>Now do you have a problem with the controller itself knowing the name 
>of the param?
>
>Colin
>
>
>Dion Almaer wrote:
>
>  
>
>>Hi guys -
>>
>>I run into the following use case a lot:
>>
>>- Create a new FOO
>>- On success I want to SHOW that FOO
>>
>>Ideally I would want to:
>>
>><property
>>name="successView"><value>viewFoo.html?id=$request['id']</value></prop
>>e
>>rty>
>>
>>viewFoo.html?id=$request['id]
>>
>>Could of course be something else like: id=$id or
>>$request.getParameter("id") or whatever.
>>
>>But it would be really nice to be able to do something like this 
>>instead of having my controller do a
>>
>>.... getSuccessView() + "id=" + theId ....
>>
>>If there another clean way to do this that I am missing?
>>
>>Cheers,
>>
>>Dion
>> 
>>    
>>



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

Re: [Springframework-developer] Creating reusable component packages with Spring

[Patrick B. <pbu...@gm...>]

On Wed, 10 Nov 2004 16:07:45 +0100, C=E9sar Ordi=F1ana <co...@di...> w=
rote:

> Anyway, in case it could be needed for other beans, what do you think
> about the idea to allow to modify or extend a bean from one definition
> file, which is already defined in a previous definition file, instead of
> completely redefining them?

I see an advantage of this since the project I'm working also needs
the ability to essentially add to the definition of a bean. Our
use-case is the same with respect to adding mappings to a Hibernate
Session Factory.

We have our core code and mappings in a jar file that gets used by
many web apps. Each of these web apps should then be able to define
their own mappings that possibly relate to the core ones, but add
additional app specific entities. We have more than one SessionFactory
since separate parts of the app can be stored in separate, unrelated
databases. With the current setup, if the web app author wants to add
a new mapping, they have to duplicate our SessionFactory definition,
which would make future upgrades problematic since the end user would
need to keep in sync with our latest SessionFactory definitions.

I'm +1 for some mechanism to tell the bean factory to add to the
current bean if already defined.

Patrick

Re: [Springframework-developer] Creating reusable component packages with Spring

[<co...@di...>]

Thanks for the tip Juergen. I like very much the mappingJarLocations 
approach.

Anyway, in case it could be needed for other beans, what do you think 
about the idea to allow to modify or extend a bean from one definition 
file, which is already defined in a previous definition file, instead of 
completely redefining them?

jürgen höller [werk3AT] wrote:

>One way to achieve automatic loading of all Hibernate mapping files would be to put them into the lib directory as separate files, alongside the module jar files, and refer to them as follows:
>
>  <bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
>    ...
>    <property name="mappingDirectoryLocations">
>      <list>
>        <value>WEB-INF/lib</value>
>      </list>
>    </property>
>  </bean>
>
>You could also tell Hibernate to load all mapping files found in your module jars:
>
>  <bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
>    ...
>    <property name="mappingJarLocations">
>      <list>
>        <value>WEB-INF/lib/module1.jar</value>
>        <value>WEB-INF/lib/module2.jar</value>
>        <value>WEB-INF/lib/module3.jar</value>
>      </list>
>    </property>
>  </bean>
>
>To make the latter option more convenient, I've just added a ResourceArrayPropertyEditor that can automatically resolve file patterns as Resource array. "mappingJarLocations" takes a Resource array, so you can specify a pattern there now (as direct value):
>
>  <bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
>    ...
>    <property name="mappingJarLocations">
>      <list>
>        <value>WEB-INF/lib/module*.jar</value>
>      </list>
>    </property>
>  </bean>
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of César Ordiñana
>Sent: Wednesday, November 10, 2004 12:36 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Creating reusable component
>packages with Spring
>
>
>Hi all,
>
>We have just tried to solve the same challenge as James. We have found a 
>partial solution by putting the applicationContext.xml files into each 
>module jar.
>
>For example, if we have a module called module1, we have a 
>"module1-applicationContext.xml" which goes to a "spring" folder inside 
>the module1.jar. Then, if we want to use the module1 into one of our 
>webapps, we only have to add the jar into the WEB-INF/lib folder and add 
>its applicationContext.xml file to the config locations, like this:
>
>  <context-param>
>    <param-name>contextConfigLocation</param-name>
>    <param-value>
>      classpath:spring/module1-applicationContext.xml
>      classpath:spring/module2-applicationContext.xml
>      classpath:spring/module3-applicationContext.xml
>      applicationContext.xml
>    </param-value>
>  </context-param>
>
>It works very well, except for those beans whose properties can be 
>modified by more than one module. One example is the 
>org.springframework.orm.hibernate.LocalSessionFactoryBean  
>mappingResources property. Each of our modules have their own hibernate 
>mappings, with relationships between modules, and all of them have to be 
>handled by the same SessionFactory.
>
>One way to handle it could be to extend the spring beans definition 
>format to allow to modify already defined beans, instead of redefining 
>them, maybe something like:
>
>module1-applicationContext.xml:
>  <bean id="mySessionFactory" definition="add">
>    <property name="mappingResources">
>      <list>
>        <value>module1/Element.hbm.xml</value>
>      </list>
>    </property>
>  </bean> 
>
>module2-applicationContext.xml:
>  <bean id="mySessionFactory" definition="add">
>    <property name="mappingResources">
>      <list>
>        <value>module2/Order.hbm.xml</value>
>        <value>module2/Line.hbm.xml</value>
>      </list>
>    </property>
>  </bean> 
>
>For now, we have solved the LocalSessionFactoryBean issue by extending 
>it and allowing the list of mapping resources to be added by other 
>beans. Also we have developed a simple BeanPostProcessor which allows us 
>to put the hibernate mappings per module, and it adds them to the 
>extended LocalSessionFactoryBean automatically.
>
>Anyway, we are looking also for a more general solution, like the one 
>stated by Rod. Our projects are based on portlets, and we would like to 
>extract common modules of each portlet webapp to be handled by a common 
>parent context. I still haven't tried the 
>ContextSingletonBeanFactoryLocator class.
>Rod Johnson wrote:
>  
>

-- 
Cèsar Ordiñana Navarro
CTO, DiSiD SLL  http://www.disid.com
Parc Tecnològic. Av. Benjamin Franklin, 12
Centre de Negocis Edifici CEEI
46980 València - España
Tel +34 646 10 92 84

Re: [Springframework-developer] successView changes

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

Also, if you're willing to go to CVS code (which will be 1.1.2 in a few 
days), you can rely on the new redirect: prefix support, and get away 
from the controller knowing that a RedirectView is used at all.


Dion Almaer wrote:

>Colin -
>
>You are the man :)
>
>return new ModelAndView(new RedirectView(getSuccessView(), true), "id",
>theId));
>
>Is all I needed.
>
>Cheers,
>
>Dion
> 
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...] 
>Sent: Tuesday, November 09, 2004 11:03 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] successView changes
>
>Dion,
>
>I presume you are actually using this view as a RedirectView? That's the
>only thing that makes sense, given that you're playing around with the name
>as if it's a URL, and the fact that it has .html at the end; I presume this
>is mapped to another controller?
>
>In any case, you shouldn't be manipulating the view name at all. What you
>should be doing is just setting the id as a model object, and letting
>RedirectView build the URL for you:
>  return new ModelAndView(new RedirectView(getSuccessView(), true), "id",
>theId));
>
>Now do you have a problem with the controller itself knowing the name of the
>param?
>
>Colin
>
>
>Dion Almaer wrote:
>
>  
>
>>Hi guys -
>>
>>I run into the following use case a lot:
>>
>>- Create a new FOO
>>- On success I want to SHOW that FOO
>>
>>Ideally I would want to:
>>
>><property
>>name="successView"><value>viewFoo.html?id=$request['id']</value></prope
>>rty>
>>
>>viewFoo.html?id=$request['id]
>>
>>Could of course be something else like: id=$id or
>>$request.getParameter("id") or whatever.
>>
>>But it would be really nice to be able to do something like this 
>>instead of having my controller do a
>>
>>.... getSuccessView() + "id=" + theId ....
>>
>>If there another clean way to do this that I am missing?
>>
>>Cheers,
>>
>>Dion
>> 
>>    
>>

Re: [Springframework-developer] RE: Using multiple view resolvers

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

I added a an enhancement request in Jira a while ago
  http://opensource.atlassian.com/projects/spring/browse/SPR-236
which is about this issue.

I see two possible solutions. One is a general view resolver that itself 
contains a list of other view resolvers, and delegates approproately 
based on a regex. The other way to approach it is to just put the regex 
code itself in either UrlBasedViewResolver or 
InternalResourceViewResolver, where the resolver would just skip its own 
execution if the regex didn't match, and you would just chain one or 
more resolvers normally, but now InternalResourceViewResolver could be 
something other than the last one.

I should be able to get this in for 1.2...

Colin

Alessandro Di Bella wrote:

>Hi Jürgen 
>I understand now. A solution I thought of is to create my own ViewResolver 
>that acts as a proxy and depending on some criteria it will delegate to the 
>appropriate ViewResolver. I still have a problem though, if I have more than 
>a bean that implements org.springframework.web.servlet.ViewResolver, how do I 
>tell the servlet which one to use?
>
>Thanks
>
>Alessandro
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Hi Alessandro,
>>
>>Spring's view names are supposed to be global for the scope of a
>>DispatcherServlet. Hence, all controllers in the same dispatcher will
>>share a single view namespace. There is no support for having "local" view
>>names that just apply to a specific controller, with different controllers
>>returning the same view names but referring to different views.
>>
>>Essentially, Spring does not use the same view name semantics as WebWork
>>here, where view names are usually local: for example, "success" or
>>"form". View names in Spring are rather meant to refer to shared physical
>>resources, thus being global (for the scope of a dispatcher): for example,
>>"orderForm" or "orderList".
>>
>>If you still want to use local-style view names, you could collect some of
>>your controllers into a separate DispatcherServlet context, having their
>>own view namespace there. Or you could use controller-specific prefixes
>>for view names.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Alessandro Di Bella
>>Sent: Tuesday, November 09, 2004 6:29 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] Using multiple view resolvers
>>
>>
>><posted & mailed>
>>
>>Hi,
>>
>>I apologize for posting this in the developer list but i did not get any
>>answer in the users one and I'm stuck.
>>
>>
>>I'm trying to put together a web app and I'm trying to understand how to
>>use the view resolver. I should to get the XmlViewResolver to work but i
>>don't understand how I can associate a specific resolver with a
>>controller. I'll explain better. I have a MultiActionController e several
>>SimpleFormController(s) that are mapped to different paths.
>>I would like to be able to say that if the request is handled by the
>>MultiActionController, the views sholuld be resolved by the
>>XmlViewResolver while if the request if handled by SimpleFormController
>>foo, the views should be resolved by the resolver bar.
>>
>>Is this possible?
>>
>>Thanks
>>
>>Alessandro
>>    
>>

RE: [Springframework-developer] Creating reusable component packages with Spring

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

One way to achieve automatic loading of all Hibernate mapping files =
would be to put them into the lib directory as separate files, alongside =
the module jar files, and refer to them as follows:

  <bean id=3D"sessionFactory" =
class=3D"org.springframework.orm.hibernate.LocalSessionFactoryBean">
    ...
    <property name=3D"mappingDirectoryLocations">
      <list>
        <value>WEB-INF/lib</value>
      </list>
    </property>
  </bean>

You could also tell Hibernate to load all mapping files found in your =
module jars:

  <bean id=3D"sessionFactory" =
class=3D"org.springframework.orm.hibernate.LocalSessionFactoryBean">
    ...
    <property name=3D"mappingJarLocations">
      <list>
        <value>WEB-INF/lib/module1.jar</value>
        <value>WEB-INF/lib/module2.jar</value>
        <value>WEB-INF/lib/module3.jar</value>
      </list>
    </property>
  </bean>

To make the latter option more convenient, I've just added a =
ResourceArrayPropertyEditor that can automatically resolve file patterns =
as Resource array. "mappingJarLocations" takes a Resource array, so you =
can specify a pattern there now (as direct value):

  <bean id=3D"sessionFactory" =
class=3D"org.springframework.orm.hibernate.LocalSessionFactoryBean">
    ...
    <property name=3D"mappingJarLocations">
      <list>
        <value>WEB-INF/lib/module*.jar</value>
      </list>
    </property>
  </bean>

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of C=E9sar Ordi=F1ana
Sent: Wednesday, November 10, 2004 12:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Creating reusable component
packages with Spring


Hi all,

We have just tried to solve the same challenge as James. We have found a =

partial solution by putting the applicationContext.xml files into each=20
module jar.

For example, if we have a module called module1, we have a=20
"module1-applicationContext.xml" which goes to a "spring" folder inside=20
the module1.jar. Then, if we want to use the module1 into one of our=20
webapps, we only have to add the jar into the WEB-INF/lib folder and add =

its applicationContext.xml file to the config locations, like this:

  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      classpath:spring/module1-applicationContext.xml
      classpath:spring/module2-applicationContext.xml
      classpath:spring/module3-applicationContext.xml
      applicationContext.xml
    </param-value>
  </context-param>

It works very well, except for those beans whose properties can be=20
modified by more than one module. One example is the=20
org.springframework.orm.hibernate.LocalSessionFactoryBean =20
mappingResources property. Each of our modules have their own hibernate=20
mappings, with relationships between modules, and all of them have to be =

handled by the same SessionFactory.

One way to handle it could be to extend the spring beans definition=20
format to allow to modify already defined beans, instead of redefining=20
them, maybe something like:

module1-applicationContext.xml:
  <bean id=3D"mySessionFactory" definition=3D"add">
    <property name=3D"mappingResources">
      <list>
        <value>module1/Element.hbm.xml</value>
      </list>
    </property>
  </bean>=20

module2-applicationContext.xml:
  <bean id=3D"mySessionFactory" definition=3D"add">
    <property name=3D"mappingResources">
      <list>
        <value>module2/Order.hbm.xml</value>
        <value>module2/Line.hbm.xml</value>
      </list>
    </property>
  </bean>=20

For now, we have solved the LocalSessionFactoryBean issue by extending=20
it and allowing the list of mapping resources to be added by other=20
beans. Also we have developed a simple BeanPostProcessor which allows us =

to put the hibernate mappings per module, and it adds them to the=20
extended LocalSessionFactoryBean automatically.

Anyway, we are looking also for a more general solution, like the one=20
stated by Rod. Our projects are based on portlets, and we would like to=20
extract common modules of each portlet webapp to be handled by a common=20
parent context. I still haven't tried the=20
ContextSingletonBeanFactoryLocator class.
Rod Johnson wrote:

> James
>
> I agree that this would be useful--especially for Geronimo, which you=20
> and I have discussed before. In fact it's something we could consider=20
> for 1.2, so I'd like to see a discussion here about what it should=20
> entail.
>
> I also agree with Mike re no enforcement of JNDI for cross-referencing =

> if at all possible.
>
> I would like a deployment unit to:
>
> - accommodate any config format, not just XML
> - allow a hierarchy of contexts in a single deployment unit
>
> Rgds
> Rod
>
> jas...@ma... wrote:
>
>> Its an interesting question. Just one immediate thought; I can see=20
>> there being a need for a Spring deployment unit of some kind; e.g. a=20
>> jar containing an applicationContext.xml file in APP-INF/ or=20
>> something - maybe having any additional jars required inside the jar=20
>> in APP-INF/lib.
>>
>> One there's a deployment unit we can add native support to Geronimo=20
>> (and other containers could support it too) plus we could support hot =

>> deployment of units inside Spring natively rather than relying on the =

>> J2EE deployment units (WAR / EAR / RAR)
>>
>> If there was a deployment unit; the only real issue is how to handle=20
>> cross-deployment unit references; but we could always use JNDI / JMX=20
>> for that or use a hierarchy of BeanFactory instances.
>>
>>
>> On 9 Nov 2004, at 22:51, James Cook wrote:
>>
>>> We have been developing a large enterprise application using Spring=20
>>> and it
>>> has proven to be a very effective framework. We use the Data access
>>> abstractions heavily, along with transaction management and =
Hibernate
>>> support.
>>>
>>> Now that we have most of the concepts down, some coworkers and=20
>>> myself are
>>> now considering the challenges inherent in packaging our business=20
>>> objects,
>>> service layers, spring configuration files, etc. into reusable=20
>>> component
>>> packages. We want to be able to give other developers in the company =

>>> a jar
>>> file that contains all of this content and simply drop it into their
>>> project.
>>>
>>> There are a lot of similarities (and differences) between what we=20
>>> face and
>>> what EJB components deal with. EJB has solutions for mapping=20
>>> dependencies in
>>> a component package to the primary application (ejb-ref, etc.) and=20
>>> we are
>>> beginning to talk about how to accomplish similar behavior using=20
>>> Spring.
>>>
>>> Ultimately, there are probably many nuances to this process that we=20
>>> won't
>>> know until we actual do it, but I was wondering if the development=20
>>> team has
>>> some insight into some of the Spring features that already exist=20
>>> that can
>>> assist in some of these challenges? Perhaps also there are some=20
>>> features
>>> that are on the drawing board to assist in this matter also?
>>
--=20
C=E8sar Ordi=F1ana
CTO, DiSiD SLL  http://www.disid.com
Parc Tecnol=F2gic. Av. Benjamin Franklin, 12
Centre de Negocis Edifici CEEI
46980 Val=E8ncia - Espa=F1a
Tel +34 646 10 92 84



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

Re: [Springframework-developer] Creating reusable component packages with Spring

[jb <jbe...@co...>]

I wonder if the solution to the concerns raised regarding persistence of
run-time config changes of a deployed spring based application is a
prerequisite or related problem.   Of course, this is where JMX will be
needed.   Hmmm.   This sounds like something related to what JBoss has done
with its 'microkernal' approach.

So, looking at that approach and others that provide plug-in, service
extension, and so forth, could provide a requirements list.

Just my hastily written and semi-coherent two cents.  :)




----- Original Message ----- 
From: "Rod Johnson" <ro...@in...>
To: <spr...@li...>
Sent: Wednesday, November 10, 2004 4:40 AM
Subject: Re: [Springframework-developer] Creating reusable component
packages with Spring


> James
>
> I agree that this would be useful--especially for Geronimo, which you and
I have discussed before.
> In fact it's something we could consider for 1.2, so I'd like to see a
discussion here about what it
> should entail.
>
> I also agree with Mike re no enforcement of JNDI for cross-referencing if
at all possible.
>
> I would like a deployment unit to:
>
> - accommodate any config format, not just XML
> - allow a hierarchy of contexts in a single deployment unit
>
> Rgds
> Rod
>
> jas...@ma... wrote:
> > Its an interesting question. Just one immediate thought; I can see there
> > being a need for a Spring deployment unit of some kind; e.g. a jar
> > containing an applicationContext.xml file in APP-INF/ or something -
> > maybe having any additional jars required inside the jar in APP-INF/lib.
> >
> > One there's a deployment unit we can add native support to Geronimo (and
> > other containers could support it too) plus we could support hot
> > deployment of units inside Spring natively rather than relying on the
> > J2EE deployment units (WAR / EAR / RAR)
> >
> > If there was a deployment unit; the only real issue is how to handle
> > cross-deployment unit references; but we could always use JNDI / JMX for
> > that or use a hierarchy of BeanFactory instances.
> >
> >
> > On 9 Nov 2004, at 22:51, James Cook wrote:
> >
> >> We have been developing a large enterprise application using Spring
> >> and it
> >> has proven to be a very effective framework. We use the Data access
> >> abstractions heavily, along with transaction management and Hibernate
> >> support.
> >>
> >> Now that we have most of the concepts down, some coworkers and myself
are
> >> now considering the challenges inherent in packaging our business
> >> objects,
> >> service layers, spring configuration files, etc. into reusable
component
> >> packages. We want to be able to give other developers in the company a
> >> jar
> >> file that contains all of this content and simply drop it into their
> >> project.
> >>
> >> There are a lot of similarities (and differences) between what we face
> >> and
> >> what EJB components deal with. EJB has solutions for mapping
> >> dependencies in
> >> a component package to the primary application (ejb-ref, etc.) and we
are
> >> beginning to talk about how to accomplish similar behavior using
Spring.
> >>
> >> Ultimately, there are probably many nuances to this process that we
won't
> >> know until we actual do it, but I was wondering if the development
> >> team has
> >> some insight into some of the Spring features that already exist that
can
> >> assist in some of these challenges? Perhaps also there are some
features
> >> that are on the drawing board to assist in this matter also?
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by:
> >> Sybase ASE Linux Express Edition - download now for FREE
> >> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> >> http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Sybase ASE Linux Express Edition - download now for FREE
> > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
> -- 
>
> ____________________________________________________
> Rod Johnson
> CEO, Interface21 - Spring Services from the Source
> http://www.springframework.com
>
> Founder, Spring Framework:
> http://www.springframework.org
>
> Author, "Expert One-on-One J2EE Development Without EJB"
> (May 2004, with Juergen Hoeller).
> http://www.amazon.com/exec/obidos/ASIN/0764558315/
>
> Author, "Expert One-on-One J2EE Design and Development"
> (October 2002).
> http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/
>
>
> ____________________________________________________
> Interface21 Limited
> Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1
2JY
> Registered in England and Wales No. 5187766
> ____________________________________________________
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Creating reusable component packages with Spring

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

I see three levels of packaging here:

1. What you can already do is specify a config location like =
"classpath*:META-INF/beans.xml", which will load all beans.xml files =
from META-INF directories in all jar files found. Note that those will =
get loaded into the *same* context, though, i.e. into a single =
namespace. This is just a special way of loading bean definition files: =
The jar files are plain and simple, no custom class loaders involved, no =
special detection going on other than looking for certain resources in =
the existing class loader (for example, a web application's class =
loader). And this can be handled within an application (for example a =
WAR file): It does not need special support by the server.

2. For EJB-style deployment with naming references, things become =
harder. It might be appropriate to offer hooks for JNDI exposure here: A =
server like Geronimo could detect special jar files (maybe through the =
file extension), loading a local Spring application context for each jar =
and exposing certain facade beans from there in JNDI. The actual JNDI =
names could be specified at deployment time, like with EJB, putting the =
onus of namespace management on the deployer. Spring bean names are just =
used internally for the local context of each jar file; they do not =
share a common namespace. A web application can then have its own Spring =
root context with its own namespace, linking in the modules as JNDI =
objects. This should still be possible with plain jars, in principle, =
containing special descriptor files in the META-INF directory.

3. If additional libraries (that just apply to a specific module) can be =
contained in the deployment unit, we're crossing into different =
territory again. Essentially, this means having a separate class loader =
per deployment unit. We're beyond a plain jar file and simple namespace =
management here, coming close to an EJB jar or even an EAR file. This =
means we're also incurring the risk of issues like conflicts between =
different library versions etc, and the deployment hassle of respecting =
the different class loaders involved.


Option 1 is rather trivial, as it is essentially just a different flavor =
of loading bean definition files in an application - in all other =
respects, it's still typical Spring usage (in the current sense), for =
example using the existing class loader of a WAR. This will seamlessly =
work in any server.

If the namespace problem arises, option 2 becomes interesting: =
Individual jar files could then get deployed with special deployment =
descriptors (inside or outside the jar), mapping local bean names in the =
jar to global JNDI names - usually for facades of the module in that =
jar. This would already need special support by the server, though, but =
could still work as part of a WAR file. The web application could simply =
expect specific facades at specific JNDI names; the deployer is =
responsible for deploying the module jars accordingly.

Option 3 is essentially the equivalent of local stateless session bean =
deployment, requiring the modules to run in a different class loader =
than the WAR file. It seems to me that this is not typically needed in =
Spring scenarios: It might be sufficient to resort to local EJB =
deployment in such a case, with a Spring context backing the stateless =
sessions beans involved (through Spring's existing EJB support classes). =
Of course, it might still be worthwhile to offer such a full-blown =
deployment unit for plain Spring too. If not requiring module-specific =
library deployment, option 2 is available as a simpler alternative.


An interesting question is whether a variation of option 2 could be =
provided without JNDI: i.e. auto-loading one context per jar file, with =
the root application context directly linking in specific facades from =
there. However, how would one identify a specific facade in a specific =
jar file? In option 2 as outlined above, the deployer would do this for =
each jar file - for example, through including a special descriptor in =
the jar, mapping local bean names to global JNDI names.

For option 2 without JNDI, we'd need to have unique bean definition file =
names in the jar files, which can be clearly identified via the class =
loader. In that case, the root context could load the jar-specific =
contexts as beans, allowing to expose specific facades in those contexts =
as beans in the root context. Each jar-specific context would still have =
its own namespace; just specific beans would get linked into the root =
context under appropriate names. There would be no further relationship =
between the root context and the jar-specific contexts.

A remaining problem for option 2 is how to make specific beans from the =
root context visible to jar-specific contexts - linking in beans the =
other way round. I don't think that it is generally appropriate to load =
the jar-specific contexts as children of the root context; they should =
rather be considered as independent. In the case of a JDBC DataSource, =
one could resort to a shared JNDI location. But in the case of a =
Hibernate SessionFactory, there should be a way to make a local instance =
defined in the root context available to jar-specific contexts - with =
the option to link it in under a specific bean name.


Thoughts? Opinions?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jas...@ma...
Sent: Wednesday, November 10, 2004 9:43 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Creating reusable component
packages with Spring


Its an interesting question. Just one immediate thought; I can see=20
there being a need for a Spring deployment unit of some kind; e.g. a=20
jar containing an applicationContext.xml file in APP-INF/ or something=20
- maybe having any additional jars required inside the jar in=20
APP-INF/lib.

One there's a deployment unit we can add native support to Geronimo=20
(and other containers could support it too) plus we could support hot=20
deployment of units inside Spring natively rather than relying on the=20
J2EE deployment units (WAR / EAR / RAR)

If there was a deployment unit; the only real issue is how to handle=20
cross-deployment unit references; but we could always use JNDI / JMX=20
for that or use a hierarchy of BeanFactory instances.


On 9 Nov 2004, at 22:51, James Cook wrote:
> We have been developing a large enterprise application using Spring=20
> and it
> has proven to be a very effective framework. We use the Data access
> abstractions heavily, along with transaction management and Hibernate
> support.
>
> Now that we have most of the concepts down, some coworkers and myself=20
> are
> now considering the challenges inherent in packaging our business=20
> objects,
> service layers, spring configuration files, etc. into reusable=20
> component
> packages. We want to be able to give other developers in the company a =

> jar
> file that contains all of this content and simply drop it into their
> project.
>
> There are a lot of similarities (and differences) between what we face =

> and
> what EJB components deal with. EJB has solutions for mapping=20
> dependencies in
> a component package to the primary application (ejb-ref, etc.) and we=20
> are
> beginning to talk about how to accomplish similar behavior using=20
> Spring.
>
> Ultimately, there are probably many nuances to this process that we=20
> won't
> know until we actual do it, but I was wondering if the development=20
> team has
> some insight into some of the Spring features that already exist that=20
> can
> assist in some of these challenges? Perhaps also there are some=20
> features
> that are on the drawing board to assist in this matter also?
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

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



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

Re: [Springframework-developer] Creating reusable component packages with Spring

[<co...@di...>]

Hi all,

We have just tried to solve the same challenge as James. We have found a 
partial solution by putting the applicationContext.xml files into each 
module jar.

For example, if we have a module called module1, we have a 
"module1-applicationContext.xml" which goes to a "spring" folder inside 
the module1.jar. Then, if we want to use the module1 into one of our 
webapps, we only have to add the jar into the WEB-INF/lib folder and add 
its applicationContext.xml file to the config locations, like this:

  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      classpath:spring/module1-applicationContext.xml
      classpath:spring/module2-applicationContext.xml
      classpath:spring/module3-applicationContext.xml
      applicationContext.xml
    </param-value>
  </context-param>

It works very well, except for those beans whose properties can be 
modified by more than one module. One example is the 
org.springframework.orm.hibernate.LocalSessionFactoryBean  
mappingResources property. Each of our modules have their own hibernate 
mappings, with relationships between modules, and all of them have to be 
handled by the same SessionFactory.

One way to handle it could be to extend the spring beans definition 
format to allow to modify already defined beans, instead of redefining 
them, maybe something like:

module1-applicationContext.xml:
  <bean id="mySessionFactory" definition="add">
    <property name="mappingResources">
      <list>
        <value>module1/Element.hbm.xml</value>
      </list>
    </property>
  </bean> 

module2-applicationContext.xml:
  <bean id="mySessionFactory" definition="add">
    <property name="mappingResources">
      <list>
        <value>module2/Order.hbm.xml</value>
        <value>module2/Line.hbm.xml</value>
      </list>
    </property>
  </bean> 

For now, we have solved the LocalSessionFactoryBean issue by extending 
it and allowing the list of mapping resources to be added by other 
beans. Also we have developed a simple BeanPostProcessor which allows us 
to put the hibernate mappings per module, and it adds them to the 
extended LocalSessionFactoryBean automatically.

Anyway, we are looking also for a more general solution, like the one 
stated by Rod. Our projects are based on portlets, and we would like to 
extract common modules of each portlet webapp to be handled by a common 
parent context. I still haven't tried the 
ContextSingletonBeanFactoryLocator class.
Rod Johnson wrote:

> James
>
> I agree that this would be useful--especially for Geronimo, which you 
> and I have discussed before. In fact it's something we could consider 
> for 1.2, so I'd like to see a discussion here about what it should 
> entail.
>
> I also agree with Mike re no enforcement of JNDI for cross-referencing 
> if at all possible.
>
> I would like a deployment unit to:
>
> - accommodate any config format, not just XML
> - allow a hierarchy of contexts in a single deployment unit
>
> Rgds
> Rod
>
> jas...@ma... wrote:
>
>> Its an interesting question. Just one immediate thought; I can see 
>> there being a need for a Spring deployment unit of some kind; e.g. a 
>> jar containing an applicationContext.xml file in APP-INF/ or 
>> something - maybe having any additional jars required inside the jar 
>> in APP-INF/lib.
>>
>> One there's a deployment unit we can add native support to Geronimo 
>> (and other containers could support it too) plus we could support hot 
>> deployment of units inside Spring natively rather than relying on the 
>> J2EE deployment units (WAR / EAR / RAR)
>>
>> If there was a deployment unit; the only real issue is how to handle 
>> cross-deployment unit references; but we could always use JNDI / JMX 
>> for that or use a hierarchy of BeanFactory instances.
>>
>>
>> On 9 Nov 2004, at 22:51, James Cook wrote:
>>
>>> We have been developing a large enterprise application using Spring 
>>> and it
>>> has proven to be a very effective framework. We use the Data access
>>> abstractions heavily, along with transaction management and Hibernate
>>> support.
>>>
>>> Now that we have most of the concepts down, some coworkers and 
>>> myself are
>>> now considering the challenges inherent in packaging our business 
>>> objects,
>>> service layers, spring configuration files, etc. into reusable 
>>> component
>>> packages. We want to be able to give other developers in the company 
>>> a jar
>>> file that contains all of this content and simply drop it into their
>>> project.
>>>
>>> There are a lot of similarities (and differences) between what we 
>>> face and
>>> what EJB components deal with. EJB has solutions for mapping 
>>> dependencies in
>>> a component package to the primary application (ejb-ref, etc.) and 
>>> we are
>>> beginning to talk about how to accomplish similar behavior using 
>>> Spring.
>>>
>>> Ultimately, there are probably many nuances to this process that we 
>>> won't
>>> know until we actual do it, but I was wondering if the development 
>>> team has
>>> some insight into some of the Spring features that already exist 
>>> that can
>>> assist in some of these challenges? Perhaps also there are some 
>>> features
>>> that are on the drawing board to assist in this matter also?
>>
-- 
Cèsar Ordiñana
CTO, DiSiD SLL  http://www.disid.com
Parc Tecnològic. Av. Benjamin Franklin, 12
Centre de Negocis Edifici CEEI
46980 València - España
Tel +34 646 10 92 84

Re: [Springframework-developer] Creating reusable component packages with Spring

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

James

I agree that this would be useful--especially for Geronimo, which you and I have discussed before. 
In fact it's something we could consider for 1.2, so I'd like to see a discussion here about what it 
should entail.

I also agree with Mike re no enforcement of JNDI for cross-referencing if at all possible.

I would like a deployment unit to:

- accommodate any config format, not just XML
- allow a hierarchy of contexts in a single deployment unit

Rgds
Rod

jas...@ma... wrote:
> Its an interesting question. Just one immediate thought; I can see there 
> being a need for a Spring deployment unit of some kind; e.g. a jar 
> containing an applicationContext.xml file in APP-INF/ or something - 
> maybe having any additional jars required inside the jar in APP-INF/lib.
> 
> One there's a deployment unit we can add native support to Geronimo (and 
> other containers could support it too) plus we could support hot 
> deployment of units inside Spring natively rather than relying on the 
> J2EE deployment units (WAR / EAR / RAR)
> 
> If there was a deployment unit; the only real issue is how to handle 
> cross-deployment unit references; but we could always use JNDI / JMX for 
> that or use a hierarchy of BeanFactory instances.
> 
> 
> On 9 Nov 2004, at 22:51, James Cook wrote:
> 
>> We have been developing a large enterprise application using Spring 
>> and it
>> has proven to be a very effective framework. We use the Data access
>> abstractions heavily, along with transaction management and Hibernate
>> support.
>>
>> Now that we have most of the concepts down, some coworkers and myself are
>> now considering the challenges inherent in packaging our business 
>> objects,
>> service layers, spring configuration files, etc. into reusable component
>> packages. We want to be able to give other developers in the company a 
>> jar
>> file that contains all of this content and simply drop it into their
>> project.
>>
>> There are a lot of similarities (and differences) between what we face 
>> and
>> what EJB components deal with. EJB has solutions for mapping 
>> dependencies in
>> a component package to the primary application (ejb-ref, etc.) and we are
>> beginning to talk about how to accomplish similar behavior using Spring.
>>
>> Ultimately, there are probably many nuances to this process that we won't
>> know until we actual do it, but I was wondering if the development 
>> team has
>> some insight into some of the Spring features that already exist that can
>> assist in some of these challenges? Perhaps also there are some features
>> that are on the drawing board to assist in this matter also?
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Sybase ASE Linux Express Edition - download now for FREE
>> LinuxWorld Reader's Choice Award Winner for best database on Linux.
>> http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

-- 

____________________________________________________
Rod Johnson
CEO, Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________

RE: [Springframework-developer] RE: Using multiple view resolvers

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

By default, ViewResolvers are detected by type. If you want to have a =
single ViewResolver proxy that in turn delegates to a set of backend =
ViewResolvers, you can either define those backend ViewResolvers as =
inner beans of the ViewResolver proxy definition (inner beans are =
ignored when detecting by type), or switch your DispatcherServlet's =
"detectAllViewResolvers" flag to "false" (via a corresponding init-param =
in web.xml). In the latter case, the dispatcher will look for a single =
ViewResolver bean named "viewResolver" and ignore all others; that =
single ViewResolver is then able to delegate to backend ViewResolver =
beans.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Alessandro Di Bella
Sent: Wednesday, November 10, 2004 10:10 AM
To: spr...@li...
Subject: [Springframework-developer] RE: Using multiple view resolvers


Hi J=FCrgen=20
I understand now. A solution I thought of is to create my own =
ViewResolver=20
that acts as a proxy and depending on some criteria it will delegate to =
the=20
appropriate ViewResolver. I still have a problem though, if I have more =
than=20
a bean that implements org.springframework.web.servlet.ViewResolver, how =
do I=20
tell the servlet which one to use?

Thanks

Alessandro


j=FCrgen h=F6ller [werk3AT] wrote:

> Hi Alessandro,
>=20
> Spring's view names are supposed to be global for the scope of a
> DispatcherServlet. Hence, all controllers in the same dispatcher will
> share a single view namespace. There is no support for having "local" =
view
> names that just apply to a specific controller, with different =
controllers
> returning the same view names but referring to different views.
>=20
> Essentially, Spring does not use the same view name semantics as =
WebWork
> here, where view names are usually local: for example, "success" or
> "form". View names in Spring are rather meant to refer to shared =
physical
> resources, thus being global (for the scope of a dispatcher): for =
example,
> "orderForm" or "orderList".
>=20
> If you still want to use local-style view names, you could collect =
some of
> your controllers into a separate DispatcherServlet context, having =
their
> own view namespace there. Or you could use controller-specific =
prefixes
> for view names.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alessandro Di Bella
> Sent: Tuesday, November 09, 2004 6:29 PM
> To: spr...@li...
> Subject: [Springframework-developer] Using multiple view resolvers
>=20
>=20
> <posted & mailed>
>=20
> Hi,
>=20
> I apologize for posting this in the developer list but i did not get =
any
> answer in the users one and I'm stuck.
>=20
>=20
> I'm trying to put together a web app and I'm trying to understand how =
to
> use the view resolver. I should to get the XmlViewResolver to work but =
i
> don't understand how I can associate a specific resolver with a
> controller. I'll explain better. I have a MultiActionController e =
several
> SimpleFormController(s) that are mapped to different paths.
> I would like to be able to say that if the request is handled by the
> MultiActionController, the views sholuld be resolved by the
> XmlViewResolver while if the request if handled by =
SimpleFormController
> foo, the views should be resolved by the resolver bar.
>=20
> Is this possible?
>=20
> Thanks
>=20
> Alessandro
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&opclick


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

[Springframework-developer] RE: Using multiple view resolvers

[Alessandro Di B. <al...@fu...>]

Hi J=FCrgen=20
I understand now. A solution I thought of is to create my own ViewResolver=
=20
that acts as a proxy and depending on some criteria it will delegate to the=
=20
appropriate ViewResolver. I still have a problem though, if I have more tha=
n=20
a bean that implements org.springframework.web.servlet.ViewResolver, how do=
 I=20
tell the servlet which one to use?

Thanks

Alessandro


j=FCrgen h=F6ller [werk3AT] wrote:

> Hi Alessandro,
>=20
> Spring's view names are supposed to be global for the scope of a
> DispatcherServlet. Hence, all controllers in the same dispatcher will
> share a single view namespace. There is no support for having "local" view
> names that just apply to a specific controller, with different controllers
> returning the same view names but referring to different views.
>=20
> Essentially, Spring does not use the same view name semantics as WebWork
> here, where view names are usually local: for example, "success" or
> "form". View names in Spring are rather meant to refer to shared physical
> resources, thus being global (for the scope of a dispatcher): for example,
> "orderForm" or "orderList".
>=20
> If you still want to use local-style view names, you could collect some of
> your controllers into a separate DispatcherServlet context, having their
> own view namespace there. Or you could use controller-specific prefixes
> for view names.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Alessandro Di Bella
> Sent: Tuesday, November 09, 2004 6:29 PM
> To: spr...@li...
> Subject: [Springframework-developer] Using multiple view resolvers
>=20
>=20
> <posted & mailed>
>=20
> Hi,
>=20
> I apologize for posting this in the developer list but i did not get any
> answer in the users one and I'm stuck.
>=20
>=20
> I'm trying to put together a web app and I'm trying to understand how to
> use the view resolver. I should to get the XmlViewResolver to work but i
> don't understand how I can associate a specific resolver with a
> controller. I'll explain better. I have a MultiActionController e several
> SimpleFormController(s) that are mapped to different paths.
> I would like to be able to say that if the request is handled by the
> MultiActionController, the views sholuld be resolved by the
> XmlViewResolver while if the request if handled by SimpleFormController
> foo, the views should be resolved by the resolver bar.
>=20
> Is this possible?
>=20
> Thanks
>=20
> Alessandro
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&opclick

Re: [Springframework-developer] Creating reusable component packages with Spring

[Mike Cannon-B. <mca...@gm...>]

Please no mandatory JNDI! :)=20

Spring rocks because the bean configuration to a large extent replaces
JNDI in an enterprise application (yes, I know what JNDI is for - but
realistically in _most_ J2EE apps it's a large map to retrieve your
"stuff" from - a Spring context).

Other than that mini-rant, a Spring "component" unit would be awesome.

m

On Wed, 10 Nov 2004 08:42:36 +0000, jas...@ma...
<jas...@ma...> wrote:
> Its an interesting question. Just one immediate thought; I can see
> there being a need for a Spring deployment unit of some kind; e.g. a
> jar containing an applicationContext.xml file in APP-INF/ or something
> - maybe having any additional jars required inside the jar in
> APP-INF/lib.
>=20
> One there's a deployment unit we can add native support to Geronimo
> (and other containers could support it too) plus we could support hot
> deployment of units inside Spring natively rather than relying on the
> J2EE deployment units (WAR / EAR / RAR)
>=20
> If there was a deployment unit; the only real issue is how to handle
> cross-deployment unit references; but we could always use JNDI / JMX
> for that or use a hierarchy of BeanFactory instances.
>=20
>=20
>=20
>=20
> On 9 Nov 2004, at 22:51, James Cook wrote:
> > We have been developing a large enterprise application using Spring
> > and it
> > has proven to be a very effective framework. We use the Data access
> > abstractions heavily, along with transaction management and Hibernate
> > support.
> >
> > Now that we have most of the concepts down, some coworkers and myself
> > are
> > now considering the challenges inherent in packaging our business
> > objects,
> > service layers, spring configuration files, etc. into reusable
> > component
> > packages. We want to be able to give other developers in the company a
> > jar
> > file that contains all of this content and simply drop it into their
> > project.
> >
> > There are a lot of similarities (and differences) between what we face
> > and
> > what EJB components deal with. EJB has solutions for mapping
> > dependencies in
> > a component package to the primary application (ejb-ref, etc.) and we
> > are
> > beginning to talk about how to accomplish similar behavior using
> > Spring.
> >
> > Ultimately, there are probably many nuances to this process that we
> > won't
> > know until we actual do it, but I was wondering if the development
> > team has
> > some insight into some of the Spring features that already exist that
> > can
> > assist in some of these challenges? Perhaps also there are some
> > features
> > that are on the drawing board to assist in this matter also?
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Sybase ASE Linux Express Edition - download now for FREE
> > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
>=20
> James
> -------
> http://radio.weblogs.com/0112098/
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&opclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20


--=20
ATLASSIAN - http://www.atlassian.com

Re: [Springframework-developer] Creating reusable component packages with Spring

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

Its an interesting question. Just one immediate thought; I can see=20
there being a need for a Spring deployment unit of some kind; e.g. a=20
jar containing an applicationContext.xml file in APP-INF/ or something=20=

- maybe having any additional jars required inside the jar in=20
APP-INF/lib.

One there's a deployment unit we can add native support to Geronimo=20
(and other containers could support it too) plus we could support hot=20
deployment of units inside Spring natively rather than relying on the=20
J2EE deployment units (WAR / EAR / RAR)

If there was a deployment unit; the only real issue is how to handle=20
cross-deployment unit references; but we could always use JNDI / JMX=20
for that or use a hierarchy of BeanFactory instances.


On 9 Nov 2004, at 22:51, James Cook wrote:
> We have been developing a large enterprise application using Spring=20
> and it
> has proven to be a very effective framework. We use the Data access
> abstractions heavily, along with transaction management and Hibernate
> support.
>
> Now that we have most of the concepts down, some coworkers and myself=20=

> are
> now considering the challenges inherent in packaging our business=20
> objects,
> service layers, spring configuration files, etc. into reusable=20
> component
> packages. We want to be able to give other developers in the company a=20=

> jar
> file that contains all of this content and simply drop it into their
> project.
>
> There are a lot of similarities (and differences) between what we face=20=

> and
> what EJB components deal with. EJB has solutions for mapping=20
> dependencies in
> a component package to the primary application (ejb-ref, etc.) and we=20=

> are
> beginning to talk about how to accomplish similar behavior using=20
> Spring.
>
> Ultimately, there are probably many nuances to this process that we=20
> won't
> know until we actual do it, but I was wondering if the development=20
> team has
> some insight into some of the Spring features that already exist that=20=

> can
> assist in some of these challenges? Perhaps also there are some=20
> features
> that are on the drawing board to assist in this matter also?
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

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

RE: [Springframework-developer] successView changes

[Dion A. <di...@al...>]

Colin -

You are the man :)

return new ModelAndView(new RedirectView(getSuccessView(), true), "id",
theId));

Is all I needed.

Cheers,

Dion
 

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...] 
Sent: Tuesday, November 09, 2004 11:03 PM
To: spr...@li...
Subject: Re: [Springframework-developer] successView changes

Dion,

I presume you are actually using this view as a RedirectView? That's the
only thing that makes sense, given that you're playing around with the name
as if it's a URL, and the fact that it has .html at the end; I presume this
is mapped to another controller?

In any case, you shouldn't be manipulating the view name at all. What you
should be doing is just setting the id as a model object, and letting
RedirectView build the URL for you:
  return new ModelAndView(new RedirectView(getSuccessView(), true), "id",
theId));

Now do you have a problem with the controller itself knowing the name of the
param?

Colin


Dion Almaer wrote:

>Hi guys -
>
>I run into the following use case a lot:
>
>- Create a new FOO
>- On success I want to SHOW that FOO
>
>Ideally I would want to:
>
><property
>name="successView"><value>viewFoo.html?id=$request['id']</value></prope
>rty>
>
>viewFoo.html?id=$request['id]
>
>Could of course be something else like: id=$id or
>$request.getParameter("id") or whatever.
>
>But it would be really nice to be able to do something like this 
>instead of having my controller do a
>
>.... getSuccessView() + "id=" + theId ....
>
>If there another clean way to do this that I am missing?
>
>Cheers,
>
>Dion
>  
>



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

RE: [Springframework-developer] Anyone know if they're planning to go to TSS Symposium '05?

[Dion A. <di...@al...>]

I may show up

;) 

-----Original Message-----
From: Mike Cannon-Brookes [mailto:mca...@gm...] 
Sent: Tuesday, November 09, 2004 9:52 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Anyone know if they're planning to
go to TSS Symposium '05?

I'll be there :)

On Tue, 09 Nov 2004 16:04:28 -0500, Colin Sampaleanu <col...@ex...>
wrote:
> Rod, Alef and Rob, Mark and I are all going, and I believe Keith is as 
> well. A few others are 'maybe'...
> 
> 
> 
> 
> Seth Ladd wrote:
> 
> >Hello,
> >
> >It seems that TSS has already started pushing their Symposium for '05.
> >
> >http://www.theserverside.com/symposium/
> >
> >It's a bit early to decide or plan for, but their early bird 
> >registration seems to end today.  I was curious if anyone is 
> >hoping/planning to go?  Might make it an easier sell to The Boss.
> >
> >Thanks,
> >Seth
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by:
> >Sybase ASE Linux Express Edition - download now for FREE LinuxWorld 
> >Reader's Choice Award Winner for best database on Linux.
> >http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> >_______________________________________________
> >Springframework-developer mailing list 
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-develope
> >r
> >
> >
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE LinuxWorld 
> Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 


--
ATLASSIAN - http://www.atlassian.com


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

Re: [Springframework-developer] successView changes

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

Dion,

I presume you are actually using this view as a RedirectView? That's the 
only thing that makes sense, given that you're playing around with the 
name as if it's a URL, and the fact that it has .html at the end; I 
presume this is mapped to another controller?

In any case, you shouldn't be manipulating the view name at all. What 
you should be doing is just setting the id as a model object, and 
letting RedirectView build the URL for you:
  return new ModelAndView(new RedirectView(getSuccessView(), true), 
"id", theId));

Now do you have a problem with the controller itself knowing the name of 
the param?

Colin


Dion Almaer wrote:

>Hi guys -
>
>I run into the following use case a lot:
>
>- Create a new FOO
>- On success I want to SHOW that FOO
>
>Ideally I would want to:
>
><property
>name="successView"><value>viewFoo.html?id=$request['id']</value></property>
>
>viewFoo.html?id=$request['id]
>
>Could of course be something else like: id=$id or
>$request.getParameter("id") or whatever.
>
>But it would be really nice to be able to do something like this instead of
>having my controller do a 
>
>.... getSuccessView() + "id=" + theId ....
>
>If there another clean way to do this that I am missing?
>
>Cheers,
>
>Dion
>  
>

Re: [Springframework-developer] Anyone know if they're planning to go to TSS Symposium '05?

[Mike Cannon-B. <mca...@gm...>]

I'll be there :)

On Tue, 09 Nov 2004 16:04:28 -0500, Colin Sampaleanu <col...@ex...> wrote:
> Rod, Alef and Rob, Mark and I are all going, and I believe Keith is as
> well. A few others are 'maybe'...
> 
> 
> 
> 
> Seth Ladd wrote:
> 
> >Hello,
> >
> >It seems that TSS has already started pushing their Symposium for '05.
> >
> >http://www.theserverside.com/symposium/
> >
> >It's a bit early to decide or plan for, but their early bird
> >registration seems to end today.  I was curious if anyone is
> >hoping/planning to go?  Might make it an easier sell to The Boss.
> >
> >Thanks,
> >Seth
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by:
> >Sybase ASE Linux Express Edition - download now for FREE
> >LinuxWorld Reader's Choice Award Winner for best database on Linux.
> >http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 


-- 
ATLASSIAN - http://www.atlassian.com

[Springframework-developer] successView changes

[Dion A. <di...@al...>]

Hi guys -

I run into the following use case a lot:

- Create a new FOO
- On success I want to SHOW that FOO

Ideally I would want to:

<property
name="successView"><value>viewFoo.html?id=$request['id']</value></property>

viewFoo.html?id=$request['id]

Could of course be something else like: id=$id or
$request.getParameter("id") or whatever.

But it would be really nice to be able to do something like this instead of
having my controller do a 

.... getSuccessView() + "id=" + theId ....

If there another clean way to do this that I am missing?

Cheers,

Dion

Re: [Springframework-developer] Preparing for 1.1.2

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

Makes sense - just changed it to "true". However, note that this just =
applies to redirect URLs that start with a slash anyway: URLs that are =
relative in the first place will always be considered as relative to the =
current URL path (which is often appropriate). For an example, have a =
look at imagedb's ImageController.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Seth Ladd
Gesendet: Mi 10.11.2004 00:53
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.1.2



> I think the defualt state in the class for the redirectContextView
> should be true. While the default State in RedirectView for the =
similar
> flag is false, even the JavaDoc for RedirectView says you will almost
> always want to set it true, since nobody wants to have to know the app
> context name just to do a redirect. I presume the reason it's false by
> default there is for historical reasons. So I think it makes sense to
> set it true by default in the view resolver, so people don't have to
> remember to set it true as a property when they define their view =
resolver.

+1 !

Every time we use it, we use 'true'.  I think that's the more sensible =
default.

Thanks,
Seth


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

Re: [Springframework-developer] Preparing for 1.1.2

[Seth L. <set...@gm...>]

> I think the defualt state in the class for the redirectContextView
> should be true. While the default State in RedirectView for the similar
> flag is false, even the JavaDoc for RedirectView says you will almost
> always want to set it true, since nobody wants to have to know the app
> context name just to do a redirect. I presume the reason it's false by
> default there is for historical reasons. So I think it makes sense to
> set it true by default in the view resolver, so people don't have to
> remember to set it true as a property when they define their view resolver.

+1 !

Every time we use it, we use 'true'.  I think that's the more sensible default.

Thanks,
Seth

Re: [Springframework-developer] Preparing for 1.1.2

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

Juergen,

I think the defualt state in the class for the redirectContextView 
should be true. While the default State in RedirectView for the similar 
flag is false, even the JavaDoc for RedirectView says you will almost 
always want to set it true, since nobody wants to have to know the app 
context name just to do a redirect. I presume the reason it's false by 
default there is for historical reasons. So I think it makes sense to 
set it true by default in the view resolver, so people don't have to 
remember to set it true as a property when they define their view resolver.



Colin Sampaleanu wrote:

> Great! I think this is the entry I put in there a while ago and never 
> got around to implementing. Anybody using this should really treat all 
> view names opaquely in the controller, if possible, so the controller 
> has no idea that there's a redirect even happening.. So the controller 
> should define properties (similar to successView) for all view names...
>
>
> jürgen höller [werk3AT] wrote:
>
>> I've just added a further minor new feature, following a JIRA 
>> suggestion:
>>
>> UrlBasedViewResolver supports a special "redirect:" prefix now, 
>> generating RedirectViews for the given rest of the view name. All 
>> regular view names will be resolved as usual, i.e. as 
>> InternalResourceViews or VelocityViews (typically prepending the 
>> specified prefix and appending the specified suffix).
>>
>> The benefit is that redirects can be specified through a special view 
>> name now, rather than through programmatically creating a 
>> ModelAndView with a RedirectView instance. In particular, this means 
>> that you can specify "redirect:myList.do" as "successView" for a 
>> SimpleFormController, just overriding "doSubmitAction" and not 
>> worrying about the success ModelAndView.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of jürgen höller [werk3AT]
>> Sent: Tuesday, November 09, 2004 8:52 AM
>> To: spr...@li...
>> Subject: [Springframework-developer] Preparing for 1.1.2
>>
>>
>> Hi everybody,
>>
>> Once again, I'm about to prepare for release 1.1.2 :-)
>> I've added two minor new features yesterday, following suggestions in 
>> JIRA:
>>
>> * added support for multi-dimensional collections to BeanWrapperImpl 
>> (e.g. "map[myKey][0]" or "map[myKey][0].name")
>> * added "setText(plainText, htmlText)" method to MimeMessageHelper, 
>> for alternative texts in the same mail
>>
>> If anyone has the chance, please give those a try, in particular the 
>> BeanWrapperImpl change.
>> I plan to do the actual release tomorrow now, if we don't encounter 
>> any remaining issues.
>>
>> Juergen
>>  
>

[Springframework-developer] Creating reusable component packages with Spring

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

We have been developing a large enterprise application using Spring and =
it
has proven to be a very effective framework. We use the Data access
abstractions heavily, along with transaction management and Hibernate
support.

Now that we have most of the concepts down, some coworkers and myself =
are
now considering the challenges inherent in packaging our business =
objects,
service layers, spring configuration files, etc. into reusable component
packages. We want to be able to give other developers in the company a =
jar
file that contains all of this content and simply drop it into their
project.

There are a lot of similarities (and differences) between what we face =
and
what EJB components deal with. EJB has solutions for mapping =
dependencies in
a component package to the primary application (ejb-ref, etc.) and we =
are
beginning to talk about how to accomplish similar behavior using Spring.

Ultimately, there are probably many nuances to this process that we =
won't
know until we actual do it, but I was wondering if the development team =
has
some insight into some of the Spring features that already exist that =
can
assist in some of these challenges? Perhaps also there are some features
that are on the drawing board to assist in this matter also?