Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Cameron B. <ca...@da...> - 2003-11-12 15:55:12
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
This sounds fantastic. I am really keen to see this in action.<br>
<br>
Any idea of when it may be availible ? If it is likely to be more than
a week, and if you have the time, could you send me a patchfile against
xwork head, and I'll apply it to a snapshot here.<br>
<br>
Thanks.<br>
<br>
Cameron<br>
<br>
Mike Cannon-Brookes wrote:<br>
<blockquote type="cite" cite="midBBD87A92.3A318%25...@at...">
<blockquote type="cite">
<pre wrap="">The <ref>/ReferenceResolver idea should be easy to add to XWork, after all.
XWork already has reflection-based setting of <param> parameters; <ref>
references could use the very same mechanism. A
SpringServletContextReferenceResolver for WebWork2 could fetch the
ServletContext from a ThreadLocal, grab the root WebApplicationContext from
the ServletContext, and resolve the reference name as bean name. A non-web
SpringClassPathReferenceResolver could access a pre-loaded
ClassPathXmlApplicationContext from a ThreadLocal, and resolve the reference
name as bean name there.
</pre>
</blockquote>
<pre wrap=""><!---->Wow - I should read the whole thread before replying :)
As said, Ross has finished this now - we're just testing and integrating
into the application before committing it back to XWork.
At the moment it works as follows (please correct me if I've got anything
wrong Ross).
There is an ExternalEntityResolver defined on a per package level, so that
you can have different resolvers for different packages (if needed). These
are hierarchically looked up too, so if you specify one for the default
package, it will filter down to all other packages.
Each action can then specify external references to be resolved, as follows:
<package name="admin" namespace="/admin" extends="default"
external-ref-resolver="com.foo.SpringExternalReferenceResolver">
<action name="update" class="com.Foo">
<external-ref name="pageManager">myPageManager</external-ref>
</action>
There is then a single XWork interceptor for all resolver implementations
(com.opensymphony.xwork.interceptors.ExternalReferenceResolutionInterceptor?
). This hands off to the resolver implementation to actually do the
resolution (ie look up "myPageManager" from the Spring context, and then set
it using setPageManager(object) on the action instance).
I believe there were a few modifications to the XWork core needed to make it
work nicely (such as being able to retrieve a PackageConfig from an
ActionConfig to lookup the resolver), but it all hangs together very nicely.
The benefit of resolution being in an interceptor, like all the Xwork
interceptors, is that you can then as the developer control the order in
which your action is setup (ie external references, XWork IoC components,
static parameters, web parameters etc).
</pre>
<blockquote type="cite">
<pre wrap="">I would be delighted to see that approach being adopted in XWork/WebWork2, as
it would allow for a really nice and straightforward combination. In terms of
timing, it would be good to settle that before both Spring 1.0 final (end of
December) and WebWork2 final (any timeframe there?). I'm happy to help on the
Spring side of things, but I guess we won't need any changes in Spring to
allow for that kind of reference support in XWork.
</pre>
</blockquote>
<pre wrap=""><!---->
The only thing I think we decided that would be handy from the Spring side
(that doesn't exist) is the ability to autoconfigure an existing object?
This would consist of giving an object and a series of names (or other
objects?) to the context, and it then working out how they are best
autowired together. This would mean you wouldn't necessarily need the
name="" in the external reference (at the cost of a little speed I suppose)
- but useful for lots of resolutions.
Hope it makes sense.
Cheers,
Mike
</pre>
<blockquote type="cite">
<pre wrap="">Juergen
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
[<a class="moz-txt-link-freetext" href="mailto:spr...@li...">mailto:spr...@li...</a>]On Behalf Of
Cameron Braid
Sent: Wednesday, November 12, 2003 12:36 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2
integration (was: About MVC) - Email found in subject
jürgen höller [werk3AT] wrote:
Hi Lars,
Cameron Braid has been working on XWork/WebWork2 integration and obviously
been pleased with it (you can search our mailing list archives for the whole
thread).
<quote>
The bean/@id attribute relaxing is fantastic thanks!
I can now use the Spring Framework as an Action Factory for
Xwork/WebWork with no duplcation of configuration, using spring to
define business related interceptors : components, transactions,
security and webwork to provide web/view oriented interceptors :
request-params, validation
xwork.xml snippet :
<package name="admin" namespace="/admin" extends="default">
<action name="update" class="com.project.AdminUpdateAction" method="txUpdate">
<result name="redirect">read.action?id=${id}</result>
</action>
</package>
applicationContext.xml snippet :
<bean name="/admin/update"
class="com.datacodex.spring.webwork.WebworkActionFactoryBean">
<property name="sessionFactory">
<ref local="sessionFactory"/>
</property>
<property name="transactionManager">
<ref local="transactionManager"/>
</property>
<property name="transactionAttributes">
<ref local="defaultActionTransactionAttributes"/>
</property>
</bean>
very simple, neat and clean !
Thanks guys for your fantastic framework.
Cameron.
</quote>
I don't know how his integration approach works in detail but it looks
promising. Cameron, can you give any in-depth insights? I assume the
WebworkActionFactoryBean creates the action, being given the class name from
the XWork definition? How does XWork know that it needs to delegate to the
corresponding WebWorkActionFactoryBean - I guess via some custom XWork action
factory? How does that action factory look up the Spring application context?
I have made a few posts on the webwork mailing list.
See
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg0591">http://www.mail-archive.com/ope...@li.../msg0591</a>
9.html to start the thread - since then I have attempted to implement some of
these ideas.
A basic summary :
I extended the WebWork ServletDispatcher, writing a new
SpringServletDispatcher, it makes a call to the static
ActionProxyFactory.setFactory(new
SpringActionProxyFactory()).
SpringActionProxyFactory extends the DefaultActionProxyFactory which overrides
createActionInvocation to use
a SpringActionInvocation
SpringActionInvocation extends DefaultActionInvocation which overrides
createAction to delegate to
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(be
anName)
to use the factory within spring to contruct this action.
The servletContext is obtained using a webwork static helper that retrieves it
from the action context (threadlocal)
This level of integration is only required if you want to use spring as the
action factory.
Most often you will only want to use spring to provide the components that the
actions use, which I think is a better soloution.
As an alternative, I still see value in extending XWork's XML action
definition format with a <ref> tag, in addition to the existing <param> tag.
Those ref tags could then get resolved via a ReferenceResolver interface,
possibly with a SpringReferenceResolver implementation that looks up the
reference names in an application context. I've suggested that a while ago,
but I don't think that anyone has adopted the idea yet, as it involves an
extension of the XWork core.
I really like your idea of supporting an external ref type tag as core in
xwork/webwork since it offers the simplest, and most elegent soloution.
<action name="listAccounts" class="project.controller.ListAccounts">
...
<ref name="accountsDao">accountsDao</ref>
...
</action>
Using one of these later ideas means that the action and refrences are totally
defined in the webwork configuration, and components are defined in spring,
which is a good separation in my mind.
When using spring as the action facory I was starting to find it difficult to
see what was going on in regards to the actions since some configuration was
done in xwork.xml and some in the spring context.
I can have a go at adding <ref> support to the xwork configuration code - in
my snadbox. In the meantime we can discuss further and see what the other
webwork developers think.
Before reading about this idea, I implemented a simple prototype (not
production ready) system to get components from spring using a webwork
interceptor.
What happens here is you configure the interceptor in the xwork.xml file just
like any other webwork interceptor, using parameter to provide a mapping of
action proeprty to spring bean name.
see
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg0595">http://www.mail-archive.com/ope...@li.../msg0595</a>
7.html
A basic summary :
<action name="listAccounts" class="project.controller.ListAccounts">
...
<interceptor-ref name="springComponent">
<param name="mapping">
accountsDao=accountsDao
</param>
</interceptor-ref>
...
</action>
this example reflectively invokes
action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext(serv
letContext).getBean(beanName))
obtaining the servlet context from the action context.
I would prefer to use the <ref> tag since it is a lot more meaningful, and
allows for plugable RefrenceResolvers .
Thanks,
Cameron
Juergen
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
[<a class="moz-txt-link-freetext" href="mailto:spr...@li...">mailto:spr...@li...</a>]On Behalf
Of Lars Fischer
Sent: Wednesday, November 12, 2003 11:32 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
found in subject
I think it would be a good idea to put a focus on WebWork 2 integration.
WebWork is a very popular framework and I think Spring would gain
further popularity when providing a way to integrate WebWork "out of the
box".
IMO the main advantage of WebWork is that it's very easy to understand even
with missing documentation. Spring MVC maybe technically superior
(I don't know) but it's too complicated to get started with.
The combination of Spring as Container and WebWork 2 as MVC framework
is very powerful.
What do you think about this ?
Regards,
Lars
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! <a class="moz-txt-link-freetext" href="http://www.apachecon.com/">http://www.apachecon.com/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>
</pre>
</blockquote>
<pre wrap=""><!---->
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! <a class="moz-txt-link-freetext" href="http://www.apachecon.com/">http://www.apachecon.com/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72" class="moz-signature">--
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler <a class="moz-txt-link-freetext" href="http://www.martinfowler.com/distributedComputing/refactoring.pdf">http://www.martinfowler.com/distributedComputing/refactoring.pdf</a>]</pre>
</body>
</html>
|
|
From: Rod J. <rod...@in...> - 2003-11-12 15:38:38
|
Hang on. It's only possible to ascertain the intersection at runtime. If
it's an AND, the runtime evaluation will never happen, which will mean that
the part of the intersection that was dynamic won't ever be evaluated and
the intersection will be bigger than it should be.
So I think it's correct. This does mean that there's a cost involved in
intersections with dynamic method matchers, which are inherently expensive.
However, we really need to write a lot more test cases for Pointcut and
MethodMatcher unions and intersections. I'm pretty sure there are some bugs
in the present composition implementation, but I was keen to put the
framework in place first.
Regards,
Rod
----- Original Message -----
From: "Dmitriy Kopylenko" <dko...@ru...>
To: <spr...@li...>
Sent: Wednesday, November 12, 2003 3:27 PM
Subject: RE: [Springframework-developer] Copy paste error ?
> I'll fix that.
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> roger holbrook
> Sent: Wednesday, November 12, 2003 10:21 AM
> To: spr...@li...
> Subject: [Springframework-developer] Copy paste error ?
>
>
>
> The following code in MethodMatchers.IntersectionMethodMatcher
> looks like a candidate:
>
> public boolean isRuntime() {
> - return a.isRuntime() || b.isRuntime();
> + return a.isRuntime() && b.isRuntime();
> }
>
> Roger
>
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest developments in
> Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
> http://www.apachecon.com/ _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Kopylenko, D. <dko...@ac...> - 2003-11-12 15:30:11
|
Fixed.
-----Original Message-----
From: Dmitriy Kopylenko [mailto:dko...@ru...]
Sent: Wednesday, November 12, 2003 10:28 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Copy paste error ?
I'll fix that.
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
roger holbrook
Sent: Wednesday, November 12, 2003 10:21 AM
To: spr...@li...
Subject: [Springframework-developer] Copy paste error ?
The following code in MethodMatchers.IntersectionMethodMatcher
looks like a candidate:
public boolean isRuntime() {
- return a.isRuntime() || b.isRuntime();
+ return a.isRuntime() && b.isRuntime();
}
Roger
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest developments in
Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
http://www.apachecon.com/ _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest developments in
Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
http://www.apachecon.com/ _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Dmitriy K. <dko...@ru...> - 2003-11-12 15:28:04
|
I'll fix that.
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
roger holbrook
Sent: Wednesday, November 12, 2003 10:21 AM
To: spr...@li...
Subject: [Springframework-developer] Copy paste error ?
The following code in MethodMatchers.IntersectionMethodMatcher
looks like a candidate:
public boolean isRuntime() {
- return a.isRuntime() || b.isRuntime();
+ return a.isRuntime() && b.isRuntime();
}
Roger
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest developments in
Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
http://www.apachecon.com/ _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: roger h. <apo...@sn...> - 2003-11-12 15:22:11
|
The following code in MethodMatchers.IntersectionMethodMatcher
looks like a candidate:
public boolean isRuntime() {
- return a.isRuntime() || b.isRuntime();
+ return a.isRuntime() && b.isRuntime();
}
Roger
|
|
From: Colin S. <col...@ex...> - 2003-11-12 15:05:42
|
In general, if I can think of a hole in Spring's current bean factory/context code, it's in the area of configuring and using bean factory/appContext trees. Juergen's code to create a bean factory/context from multiple xml files is very useful when you essentially want to have each layer in an application produce part of an overall appContext, but it breaks down if you need multiple web-apps up at the top, since in that scenario what you really need is a tree. Hence the ContextFactory interface and impl. I posted here some time in September. But I don't think that solution was terribly clean. I do think some code to address this need should be a base part of Spring... Rod Johnson wrote: >Mark, > >At the moment it's equivalent to each bean instance managing its own POJOs, >just as if you created them using the new operator. > >What I am considering is adding an additional parent bean factory that is a >singleton. This enables common objects to be shared. > >What might be even nicer would be 3 tiers: >1. shared across JVM >2. shared per EJB deployment >3. per EJB instance > >The only problem is that using a singleton at all in an EJB context is >somewhat fraught. E.g. it won't work across a cluster. > >Regards, >Rod > >----- Original Message ----- >From: "MacMahon, Mark" <M.M...@em...> >To: <spr...@li...> >Sent: Wednesday, November 12, 2003 11:51 AM >Subject: [Springframework-developer] AbstractEnterpriseBean+mutiple >beanfactory instances problem > > > > >>Hi All, >> >>I just have a quick question regarding the use of Spring from a >>Stateful/Stateless session bean. >> >>If Each implementation of Spring's AbstractEnterpriseBean loads its own >>BeanFactory, how can I guarantee that the beans loaded from the >> >> >BeanFactory > > >>are truly singleton? >> >>Shouldn't the XmlBeanFactoryLoader keep a static reference to the >>BeanFactory to ensure that it is loaded only once in a JVM and thus shared >>across all Session Bean instances in the instance pool? >>Am I missing something? >> >>Thanks in advance, >> >>Mark. >> >> >>____________________________________________________ >> >>emuse technologies >>U24 Trinity Enterprise Centre, Pearse Street, Dublin 2, Ireland. >>Tel: +353 (0)1 6717317 Fax: +353 (0)1 6717319 >>website: <http://www.emusetechnologies.com/> >>email: in...@em... <mailto:in...@em...> >>____________________________________________________ >> >>This message has been scanned for viruses using GroupShield for Exchange >>Server. >> >>CONFIDENTIALITY NOTICE - The information contained in this email message >> >> >is > > >>intended only for confidential use of the named recipient. If the reader >> >> >is > > >>not the intended recipient or the person responsible for delivering it to >>the recipient, you are hereby notified that you have received this >>communication in error and that any review, dissemination or copying of >> >> >this > > >>communication is strictly prohibited. If you have received this in error, >>please notify the sender immediately. >> >>The information, opinions and recommendations contained herein are and >> >> >must > > >>be construed solely as statements of opinion and not statements of fact. >> >> >No > > >>warranty, expressed or implied, as to the accuracy, timeliness, >>completeness, merchantability or fitness for any particular purpose of any >>such recommendation or information is given or made by emuse technologies >> >> >in > > >>any form or manner whatsoever. >> >> |
|
From: Colin S. <col...@ex...> - 2003-11-12 14:45:36
|
That makes a certain amount of sense now. It's not necessarily the case here, but sometimes you see projects go through pretty big convolutions in merging their CVS dirs and build output, just so they can produce a distributable by doing a (filtered) zip of everything. In a lot of those cases, it's actually easier/cleaner to use some intermediate dirs under 'target' (or whatever the output dir is called). Think about docs for example. If you use plain HTML files then a static 'docs' dir under the root makes at least some sense. Once you start doing transformations to produce the final documentation, this starts to break down, and it makes more sense to put various different kinds of source docs under something like 'src/docs/xxxx' , then the build steps produce and combine the output somewhere else. Anyways, this is not a religious thing for me :-), so I'll leave dist and docs/api where they are for now, and move everything else under target... Rod Johnson wrote: >Good point. dist and docs/api are pretty common practice. > >----- Original Message ----- >From: "jürgen höller [werk3AT]" <jue...@we...> >To: <spr...@li...> >Sent: Wednesday, November 12, 2003 9:20 AM >Subject: Re: [Springframework-developer] Moving all build output under >'target' > > >I don't mind the ".classes"/".testclasses"/etc directories being moved, but >I'm not so sure about the "dist" and "docs/api" directories. They are the >ones that get included in the release zips, at exactly that location: The >release zip directory structure matches our CVS module structure 1:1 >currently (omitting a lot of directories of course), and I believe that's a >good thing. > >Thus, I'd like to keep the docs/api and dist directories where they are. The >Petclinic and Countries sample apps use similar directories in their build >scripts, so this is consistent within the whole project. And switching from >a release zip to a CVS snapshot is straightforward, as the directory >structures match. > >Juergen > > >Von: spr...@li... im Auftrag von >Rod Johnson >Gesendet: Mi 12.11.2003 09:14 >An: spr...@li... >Betreff: Re: [Springframework-developer] Moving all build output under >'target' > > > > > > >>Does anybody object to me changing the build to put all directories (and >>thus all artifacts) produced by the build to be under a top-level dir >>called 'target'? I don't find the present setup, with 'x' number of >>directories produced under the project root, to be too clean or very >>standard. >> >> > >Good idea. > > > |
|
From: <jue...@we...> - 2003-11-12 13:58:53
|
> <package name=3D"admin" namespace=3D"/admin" extends=3D"default"
> external-ref-resolver=3D"com.foo.SpringExternalReferenceResolver">
> <action name=3D"update" class=3D"com.Foo">
> <external-ref name=3D"pageManager">myPageManager</external-ref>
> </action>
>=20
> This would consist of giving an object and a series of names (or other
> objects?) to the context, and it then working out how they are best
> autowired together. This would mean you wouldn't necessarily need the
> name=3D"" in the external reference (at the cost of a little speed I =
suppose)
> - but useful for lots of resolutions.
I guess you mean it wouldn't necessarily need the *body* of the =
external-ref tag? The "name" is supposed to be the name of the action =
property, i.e. referring to the "setPageManager" setter, isn't it?
To support resolving by type too, the ExternalReferenceResolver =
interface's "resolveReference" method would need to pass in the required =
type in addition to the name, i.e. both PageManager.class (as retrieved =
by introspection of the action property "pageManager") as type and =
"myPageManager" as name:
public interface ExternalReferenceResolver {
Object resolveReference(Class requiredType, String name);
}
The SpringXxxReferenceResolver implementation could then call =
getBean(name, requiredType) on the application context if the name is =
given - this method already exists as overloaded alternative to =
getBean(name).
If the name is null, i.e. the body of the <external-ref> tag was empty, =
the Spring resolver implementation could call =
BeanFactoryUtils.beanOfTypeIncludingAncestors(applicationContext, =
requiredType, true, true) which returns a single object or throws an =
exception. A similar BeanFactoryUtils.beansOfTypeIncludingAncestors =
method exists already in 1.0 M2; beanOfTypeIncludingAncestors is a new =
convenience method that will be released in the upcoming 1.0 M3 next =
week.
You could even try to add autowiring functionality, e.g. via an =
"external-ref-autowire=3Dtrue/false" setting. If autowiring is =
activated, the resolver interceptor could iterate over all the action's =
non-simple (non-primitive and non-String) properties that haven't =
explicit <external-ref> tags, and invoke resolveReference for each type. =
We have a similar mechanism for Spring bean factories: It works nicely =
if you've just got one single bean per type and no optional =
dependencies.
Juergen
|
|
From: Mike Cannon-B. <mi...@at...> - 2003-11-12 13:02:53
|
> The <ref>/ReferenceResolver idea should be easy to add to XWork, after al=
l.
> XWork already has reflection-based setting of <param> parameters; <ref>
> references could use the very same mechanism. A
> SpringServletContextReferenceResolver for WebWork2 could fetch the
> ServletContext from a ThreadLocal, grab the root WebApplicationContext fr=
om
> the ServletContext, and resolve the reference name as bean name. A non-we=
b
> SpringClassPathReferenceResolver could access a pre-loaded
> ClassPathXmlApplicationContext from a ThreadLocal, and resolve the refere=
nce
> name as bean name there.
Wow - I should read the whole thread before replying :)
As said, Ross has finished this now - we're just testing and integrating
into the application before committing it back to XWork.
At the moment it works as follows (please correct me if I've got anything
wrong Ross).
There is an ExternalEntityResolver defined on a per package level, so that
you can have different resolvers for different packages (if needed). These
are hierarchically looked up too, so if you specify one for the default
package, it will filter down to all other packages.
Each action can then specify external references to be resolved, as follows=
:
<package name=3D"admin" namespace=3D"/admin" extends=3D"default"
external-ref-resolver=3D"com.foo.SpringExternalReferenceResolver">
<action name=3D"update" class=3D"com.Foo">
<external-ref name=3D"pageManager">myPageManager</external-ref>
</action>
There is then a single XWork interceptor for all resolver implementations
(com.opensymphony.xwork.interceptors.ExternalReferenceResolutionInterceptor=
?
). This hands off to the resolver implementation to actually do the
resolution (ie look up "myPageManager" from the Spring context, and then se=
t
it using setPageManager(object) on the action instance).
I believe there were a few modifications to the XWork core needed to make i=
t
work nicely (such as being able to retrieve a PackageConfig from an
ActionConfig to lookup the resolver), but it all hangs together very nicely=
.
The benefit of resolution being in an interceptor, like all the Xwork
interceptors, is that you can then as the developer control the order in
which your action is setup (ie external references, XWork IoC components,
static parameters, web parameters etc).
=20
> I would be delighted to see that approach being adopted in XWork/WebWork2=
, as
> it would allow for a really nice and straightforward combination. In term=
s of
> timing, it would be good to settle that before both Spring 1.0 final (end=
of
> December) and WebWork2 final (any timeframe there?). I'm happy to help on=
the
> Spring side of things, but I guess we won't need any changes in Spring to
> allow for that kind of reference support in XWork.
The only thing I think we decided that would be handy from the Spring side
(that doesn't exist) is the ability to autoconfigure an existing object?
This would consist of giving an object and a series of names (or other
objects?) to the context, and it then working out how they are best
autowired together. This would mean you wouldn't necessarily need the
name=3D"" in the external reference (at the cost of a little speed I suppose)
- but useful for lots of resolutions.
Hope it makes sense.
Cheers,
Mike
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf O=
f
> Cameron Braid
> Sent: Wednesday, November 12, 2003 12:36 PM
> To: spr...@li...
> Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2
> integration (was: About MVC) - Email found in subject
>=20
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> Hi Lars,
>=20
> Cameron Braid has been working on XWork/WebWork2 integration and obviousl=
y
> been pleased with it (you can search our mailing list archives for the wh=
ole
> thread).
>=20
> <quote>
> The bean/@id attribute relaxing is fantastic thanks!
>=20
> I can now use the Spring Framework as an Action Factory for
> Xwork/WebWork with no duplcation of configuration, using spring to
> define business related interceptors : components, transactions,
> security and webwork to provide web/view oriented interceptors :
> request-params, validation
>=20
> xwork.xml snippet :
>=20
> <package name=3D"admin" namespace=3D"/admin" extends=3D"default">
> <action name=3D"update" class=3D"com.project.AdminUpdateAction" method=3D"txUpd=
ate">
> <result name=3D"redirect">read.action?id=3D${id}</result>
> </action>
> </package>
>=20
> applicationContext.xml snippet :
>=20
> <bean name=3D"/admin/update"
> class=3D"com.datacodex.spring.webwork.WebworkActionFactoryBean">
> <property name=3D"sessionFactory">
> <ref local=3D"sessionFactory"/>
> </property>
> <property name=3D"transactionManager">
> <ref local=3D"transactionManager"/>
> </property>
> <property name=3D"transactionAttributes">
> <ref local=3D"defaultActionTransactionAttributes"/>
> </property>
> </bean>
>=20
> very simple, neat and clean !
>=20
> Thanks guys for your fantastic framework.
>=20
> Cameron.
> </quote>
>=20
> I don't know how his integration approach works in detail but it looks
> promising. Cameron, can you give any in-depth insights? I assume the
> WebworkActionFactoryBean creates the action, being given the class name f=
rom
> the XWork definition? How does XWork know that it needs to delegate to th=
e
> corresponding WebWorkActionFactoryBean - I guess via some custom XWork ac=
tion
> factory? How does that action factory look up the Spring application cont=
ext?
>=20
>=20
> I have made a few posts on the webwork mailing list.
>=20
> See=20
> http://www.mail-archive.com/ope...@li.../ms=
g0591
> 9.html to start the thread - since then I have attempted to implement som=
e of
> these ideas.
>=20
> A basic summary :
>=20
> I extended the WebWork ServletDispatcher, writing a new
> SpringServletDispatcher, it makes a call to the static
> ActionProxyFactory.setFactory(new
> SpringActionProxyFactory()).
>=20
> SpringActionProxyFactory extends the DefaultActionProxyFactory which over=
rides
> createActionInvocation to use
> a SpringActionInvocation
>=20
> SpringActionInvocation extends DefaultActionInvocation which overrides
> createAction to delegate to
> WebApplicationContextUtils.getWebApplicationContext(servletContext).getBe=
an(be
> anName)=20
> to use the factory within spring to contruct this action.
>=20
> The servletContext is obtained using a webwork static helper that retriev=
es it
> from the action context (threadlocal)
>=20
> This level of integration is only required if you want to use spring as t=
he
> action factory.
>=20
> Most often you will only want to use spring to provide the components tha=
t the
> actions use, which I think is a better soloution.
>=20
>=20
> As an alternative, I still see value in extending XWork's XML action
> definition format with a <ref> tag, in addition to the existing <param> t=
ag.
> Those ref tags could then get resolved via a ReferenceResolver interface,
> possibly with a SpringReferenceResolver implementation that looks up the
> reference names in an application context. I've suggested that a while ag=
o,
> but I don't think that anyone has adopted the idea yet, as it involves an
> extension of the XWork core.
>=20
>=20
> I really like your idea of supporting an external ref type tag as core in
> xwork/webwork since it offers the simplest, and most elegent soloution.
>=20
> <action name=3D"listAccounts" class=3D"project.controller.ListAccounts">
> ...
> <ref name=3D"accountsDao">accountsDao</ref>
> ...
> </action>
> Using one of these later ideas means that the action and refrences are to=
tally
> defined in the webwork configuration, and components are defined in sprin=
g,
> which is a good separation in my mind.
>=20
> When using spring as the action facory I was starting to find it difficul=
t to
> see what was going on in regards to the actions since some configuration =
was
> done in xwork.xml and some in the spring context.
>=20
> I can have a go at adding <ref> support to the xwork configuration code -=
in
> my snadbox. In the meantime we can discuss further and see what the othe=
r
> webwork developers think.
>=20
> Before reading about this idea, I implemented a simple prototype (not
> production ready) system to get components from spring using a webwork
> interceptor. =20
>=20
> What happens here is you configure the interceptor in the xwork.xml file =
just
> like any other webwork interceptor, using parameter to provide a mapping =
of
> action proeprty to spring bean name.
>=20
> see=20
> http://www.mail-archive.com/ope...@li.../ms=
g0595
> 7.html
>=20
> A basic summary :
>=20
> <action name=3D"listAccounts" class=3D"project.controller.ListAccounts">
> ...
> <interceptor-ref name=3D"springComponent">
> <param name=3D"mapping">
> accountsDao=3DaccountsDao
> </param>
> </interceptor-ref>
> ...
> </action>
> this example reflectively invokes
> action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext=
(serv
> letContext).getBean(beanName))
> obtaining the servlet context from the action context.
>=20
> I would prefer to use the <ref> tag since it is a lot more meaningful, an=
d
> allows for plugable RefrenceResolvers .
>=20
> Thanks,
>=20
> Cameron
>=20
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Lars Fischer
> Sent: Wednesday, November 12, 2003 11:32 AM
> To: spr...@li...
> Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
> found in subject
>=20
>=20
> I think it would be a good idea to put a focus on WebWork 2 integration.
> WebWork is a very popular framework and I think Spring would gain
> further popularity when providing a way to integrate WebWork "out of the
> box".
>=20
> IMO the main advantage of WebWork is that it's very easy to understand ev=
en
> with missing documentation. Spring MVC maybe technically superior
> (I don't know) but it's too complicated to get started with.
>=20
> The combination of Spring as Container and WebWork 2 as MVC framework
> is very powerful.
>=20
> What do you think about this ?
>=20
> Regards,
> Lars
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2003-11-12 13:02:15
|
Hi Mike, I'm *DELIGHTED* to hear that! :-) I didn't know that you respectively = Ross had already picked up my idea...=20 Regarding the naming and implementation of such reference resolvers, I'd = like to re-suggest what I wrote to Cameron a few minutes ago: A Spring = reference resolver that accesses the root web application context via = the ServletContext should probably be called = "SpringServletContextReferenceResolver" or the like, while a non-web = Spring reference resolver could be called = "SpringClassPathReferenceResolver", using Spring's = ClassPathXmlApplicationContext. I guess the main focus is on web = applications anyway, so this is just meant as minor hint towards non-web = usage. <self-quote> The <ref>/ReferenceResolver idea should be easy to add to XWork, after = all. XWork already has reflection-based setting of <param> parameters; = <ref> references could use the very same mechanism. A = SpringServletContextReferenceResolver for WebWork2 could fetch the = ServletContext from a ThreadLocal, grab the root WebApplicationContext = from the ServletContext, and resolve the reference name as bean name. A = non-web SpringClassPathReferenceResolver could access a pre-loaded = ClassPathXmlApplicationContext from a ThreadLocal, and resolve the = reference name as bean name there. </self-quote> BTW, can you comment on the timeframe for a WebWork2 final release or at = least an RC? As I've already mentioned before, we're targeting beginning = of December for Spring 1.0 RC1 and end of December for 1.0 final. It = would be nice to have that kind of Spring/WebWork integration already = available by then, with proper releases of both frameworks. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Mike Cannon-Brookes Sent: Wednesday, November 12, 2003 1:49 PM To: Spring Developer Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2 integration (was:About MVC) - Email found in subject > As an alternative, I still see value in extending XWork's XML action > definition format with a <ref> tag, in addition to the existing = <param> tag. > Those ref tags could then get resolved via a ReferenceResolver = interface, > possibly with a SpringReferenceResolver implementation that looks up = the > reference names in an application context. I've suggested that a while = ago, > but I don't think that anyone has adopted the idea yet, as it involves = an > extension of the XWork core. Juergen, This is exactly what Ross (one of our new developers) has been = implementing and it looks like it will work very nicely indeed. The benefit is that = you keep XWork actions in xwork.xml, Spring beans in applicationContext.xml = - so you have good separation. Cheers, Mike >=20 > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On = Behalf > Of Lars Fischer > Sent: Wednesday, November 12, 2003 11:32 AM > To: spr...@li... > Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - = Email > found in subject >=20 >=20 > I think it would be a good idea to put a focus on WebWork 2 = integration. > WebWork is a very popular framework and I think Spring would gain > further popularity when providing a way to integrate WebWork "out of = the > box". >=20 > IMO the main advantage of WebWork is that it's very easy to understand = even > with missing documentation. Spring MVC maybe technically superior > (I don't know) but it's too complicated to get started with. >=20 > The combination of Spring as Container and WebWork 2 as MVC framework > is very powerful. >=20 > What do you think about this ? >=20 > Regards, > Lars >=20 >>> Do you not think that configuring some of this peripheral >>> data should be at the view level? If not the view, then >>> where..? In common scenarios I come across, the secondary >>> model is quite specific to a view (though not of course the >>> TYPE of view) >>=20 >>> From what I've seen there's three commons scenerio's >>=20 >> 1. Reference data needed to render the view. This is the stuff we = have >> already. >> 2. Data related to the view but not necessarily needed to render it >> (additional news in a sidebox, perhaps a menu). >> 3. Componentized views having corresponding controller (portlet) >>=20 >> The first case can perfectly be implemented using our current = reference >> data implementation (a list of elements in a select box of a form for >> instance). One controller, having reference data, specifically = belonging >> to the controller >>=20 >> The second case (sideboxes containing news, a menu that needs >> information not related to the main view) I consider to be a simple >> Tiles approach and I think a somewhat more advanced version of the >> reference data features we have now, would do. Something like you >> proposed maybe. Reference data, however, not in fact related to the >> controller! >>=20 >> The third case however, is a completely different one and somewhat = looks >> like the portlet approach. I think this is a bit too far-fetched to >> implement in Spring, although I'd like to offer view-tech independent >> stuff for this. Parallel controllers rendering views independent of >> eachother. >>=20 >> It's just some rambling, but maybe we could brainstorm about this = more >> in order to come with something brilliant :)... >>=20 >> Alef >>=20 >>=20 >>=20 >>=20 >>=20 >> ------------------------------------------------------- >> This SF.Net email sponsored by: ApacheCon 2003, >> 16-19 November in Las Vegas. Learn firsthand the latest >> developments in Apache, PHP, Perl, XML, Java, MySQL, >> WebDAV, and more! http://www.apachecon.com/ >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> = https://lists.sourceforge.net/lists/listinfo/springframework-developer >>=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Mike Cannon-B. <mi...@at...> - 2003-11-12 12:49:46
|
> As an alternative, I still see value in extending XWork's XML action > definition format with a <ref> tag, in addition to the existing <param> tag. > Those ref tags could then get resolved via a ReferenceResolver interface, > possibly with a SpringReferenceResolver implementation that looks up the > reference names in an application context. I've suggested that a while ago, > but I don't think that anyone has adopted the idea yet, as it involves an > extension of the XWork core. Juergen, This is exactly what Ross (one of our new developers) has been implementing and it looks like it will work very nicely indeed. The benefit is that you keep XWork actions in xwork.xml, Spring beans in applicationContext.xml - so you have good separation. Cheers, Mike > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On Behalf > Of Lars Fischer > Sent: Wednesday, November 12, 2003 11:32 AM > To: spr...@li... > Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email > found in subject > > > I think it would be a good idea to put a focus on WebWork 2 integration. > WebWork is a very popular framework and I think Spring would gain > further popularity when providing a way to integrate WebWork "out of the > box". > > IMO the main advantage of WebWork is that it's very easy to understand even > with missing documentation. Spring MVC maybe technically superior > (I don't know) but it's too complicated to get started with. > > The combination of Spring as Container and WebWork 2 as MVC framework > is very powerful. > > What do you think about this ? > > Regards, > Lars > >>> Do you not think that configuring some of this peripheral >>> data should be at the view level? If not the view, then >>> where..? In common scenarios I come across, the secondary >>> model is quite specific to a view (though not of course the >>> TYPE of view) >> >>> From what I've seen there's three commons scenerio's >> >> 1. Reference data needed to render the view. This is the stuff we have >> already. >> 2. Data related to the view but not necessarily needed to render it >> (additional news in a sidebox, perhaps a menu). >> 3. Componentized views having corresponding controller (portlet) >> >> The first case can perfectly be implemented using our current reference >> data implementation (a list of elements in a select box of a form for >> instance). One controller, having reference data, specifically belonging >> to the controller >> >> The second case (sideboxes containing news, a menu that needs >> information not related to the main view) I consider to be a simple >> Tiles approach and I think a somewhat more advanced version of the >> reference data features we have now, would do. Something like you >> proposed maybe. Reference data, however, not in fact related to the >> controller! >> >> The third case however, is a completely different one and somewhat looks >> like the portlet approach. I think this is a bit too far-fetched to >> implement in Spring, although I'd like to offer view-tech independent >> stuff for this. Parallel controllers rendering views independent of >> eachother. >> >> It's just some rambling, but maybe we could brainstorm about this more >> in order to come with something brilliant :)... >> >> Alef >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: ApacheCon 2003, >> 16-19 November in Las Vegas. Learn firsthand the latest >> developments in Apache, PHP, Perl, XML, Java, MySQL, >> WebDAV, and more! http://www.apachecon.com/ >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <rod...@in...> - 2003-11-12 12:48:25
|
I've introduced a refactoring allowing the caching of interceptor chains via a MethodInvocationFactory, or even pooling of MethodInvocations. No caching is implemented for now. Regards, Rod |
|
From: Mike Cannon-B. <mi...@at...> - 2003-11-12 12:47:26
|
Lars, For what it's worth we're working on some WW2 / Spring integration at the moment (along the lines of what Juergen, Cameron and others have suggested) - including minor modifications to XW to support external references, and then a Spring external reference resolver. I think it will work very nicely, we'll keep you posted :) Cheers, Mike ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support On 12/11/03 9:32 PM, "Lars Fischer" (lar...@gm...) penned the words: > I think it would be a good idea to put a focus on WebWork 2 integration. > WebWork is a very popular framework and I think Spring would gain > further popularity when providing a way to integrate WebWork "out of the > box". > > IMO the main advantage of WebWork is that it's very easy to understand even > with missing documentation. Spring MVC maybe technically superior > (I don't know) but it's too complicated to get started with. > > The combination of Spring as Container and WebWork 2 as MVC framework > is very powerful. > > What do you think about this ? > > Regards, > Lars > >>> Do you not think that configuring some of this peripheral >>> data should be at the view level? If not the view, then >>> where..? In common scenarios I come across, the secondary >>> model is quite specific to a view (though not of course the >>> TYPE of view) >> >>> From what I've seen there's three commons scenerio's >> >> 1. Reference data needed to render the view. This is the stuff we have >> already. >> 2. Data related to the view but not necessarily needed to render it >> (additional news in a sidebox, perhaps a menu). >> 3. Componentized views having corresponding controller (portlet) >> >> The first case can perfectly be implemented using our current reference >> data implementation (a list of elements in a select box of a form for >> instance). One controller, having reference data, specifically belonging >> to the controller >> >> The second case (sideboxes containing news, a menu that needs >> information not related to the main view) I consider to be a simple >> Tiles approach and I think a somewhat more advanced version of the >> reference data features we have now, would do. Something like you >> proposed maybe. Reference data, however, not in fact related to the >> controller! >> >> The third case however, is a completely different one and somewhat looks >> like the portlet approach. I think this is a bit too far-fetched to >> implement in Spring, although I'd like to offer view-tech independent >> stuff for this. Parallel controllers rendering views independent of >> eachother. >> >> It's just some rambling, but maybe we could brainstorm about this more >> in order to come with something brilliant :)... >> >> Alef >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: ApacheCon 2003, >> 16-19 November in Las Vegas. Learn firsthand the latest >> developments in Apache, PHP, Perl, XML, Java, MySQL, >> WebDAV, and more! http://www.apachecon.com/ >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: MacMahon, M. <M.M...@em...> - 2003-11-12 12:30:26
|
Hi Rod, Thanks for the swift reply (as ever!). <QUOTE> What might be even nicer would be 3 tiers: 1. shared across JVM 2. shared per EJB deployment 3. per EJB instance </QUOTE> I think (1) should be the default. In fact, I would nearly go as far to question the usefulness of Spring in an EJB without this - developers would go back to making horrible getInstance() calls! I take your point about clustered environments - IMHO we could live with one beanfactory per jvm. For now is it best that I override loadBeanFactory() too keep my own static reference. Thanks again, Mark -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: 12 November 2003 12:08 To: spr...@li... Subject: Re: [Springframework-developer] AbstractEnterpriseBean+mutiple beanfactory instances problem Mark, At the moment it's equivalent to each bean instance managing its own POJOs, just as if you created them using the new operator. What I am considering is adding an additional parent bean factory that is a singleton. This enables common objects to be shared. What might be even nicer would be 3 tiers: 1. shared across JVM 2. shared per EJB deployment 3. per EJB instance The only problem is that using a singleton at all in an EJB context is somewhat fraught. E.g. it won't work across a cluster. Regards, Rod ----- Original Message ----- From: "MacMahon, Mark" <M.M...@em...> To: <spr...@li...> Sent: Wednesday, November 12, 2003 11:51 AM Subject: [Springframework-developer] AbstractEnterpriseBean+mutiple beanfactory instances problem > > Hi All, > > I just have a quick question regarding the use of Spring from a > Stateful/Stateless session bean. > > If Each implementation of Spring's AbstractEnterpriseBean loads its own > BeanFactory, how can I guarantee that the beans loaded from the BeanFactory > are truly singleton? > > Shouldn't the XmlBeanFactoryLoader keep a static reference to the > BeanFactory to ensure that it is loaded only once in a JVM and thus shared > across all Session Bean instances in the instance pool? > Am I missing something? > > Thanks in advance, > > Mark. > > > ____________________________________________________ > > emuse technologies > U24 Trinity Enterprise Centre, Pearse Street, Dublin 2, Ireland. > Tel: +353 (0)1 6717317 Fax: +353 (0)1 6717319 > website: <http://www.emusetechnologies.com/> > email: in...@em... <mailto:in...@em...> > ____________________________________________________ > > This message has been scanned for viruses using GroupShield for Exchange > Server. > > CONFIDENTIALITY NOTICE - The information contained in this email message is > intended only for confidential use of the named recipient. If the reader is > not the intended recipient or the person responsible for delivering it to > the recipient, you are hereby notified that you have received this > communication in error and that any review, dissemination or copying of this > communication is strictly prohibited. If you have received this in error, > please notify the sender immediately. > > The information, opinions and recommendations contained herein are and must > be construed solely as statements of opinion and not statements of fact. No > warranty, expressed or implied, as to the accuracy, timeliness, > completeness, merchantability or fitness for any particular purpose of any > such recommendation or information is given or made by emuse technologies in > any form or manner whatsoever. > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-11-12 12:25:23
|
Cameron,
Wow, that was a quick reply! :-)
Your approach of using Spring as action factory for XWork, IoC-wiring =
XWork action objects, is similar to Don Brown's Struts-Spring project =
where Spring is used as action factory for Struts, IoC-wiring Struts =
action objects. I generally tend to view Spring as middle tier component =
provider rather than action factory when used with other web frameworks.
As you've noted, you typically need some kind of double configuration =
for action factory usage: Spring wires the actions and gives them a =
name, but the web framework still needs to define the actions and link =
to the Spring action factory. I totally agree that the separation is =
cleaner when just accessing Spring components from such actions. The =
latter would also seamlessly allow for a Spring root web application =
context (with middle tier components) being accessed by various =
dispatcher servlets (with web actions), even by multiple different web =
MVC frameworks within the same web application!
The <ref>/ReferenceResolver idea should be easy to add to XWork, after =
all. XWork already has reflection-based setting of <param> parameters; =
<ref> references could use the very same mechanism. A =
SpringServletContextReferenceResolver for WebWork2 could fetch the =
ServletContext from a ThreadLocal, grab the root WebApplicationContext =
from the ServletContext, and resolve the reference name as bean name. A =
non-web SpringClassPathReferenceResolver could access a pre-loaded =
ClassPathXmlApplicationContext from a ThreadLocal, and resolve the =
reference name as bean name there.
I would be delighted to see that approach being adopted in =
XWork/WebWork2, as it would allow for a really nice and straightforward =
combination. In terms of timing, it would be good to settle that before =
both Spring 1.0 final (end of December) and WebWork2 final (any =
timeframe there?). I'm happy to help on the Spring side of things, but I =
guess we won't need any changes in Spring to allow for that kind of =
reference support in XWork.
Juergen
-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Cameron Braid
Sent: Wednesday, November 12, 2003 12:36 PM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2 =
integration (was: About MVC) - Email found in subject
j=FCrgen h=F6ller [werk3AT] wrote:
Hi Lars,
Cameron Braid has been working on XWork/WebWork2 integration and =
obviously been pleased with it (you can search our mailing list archives =
for the whole thread).
<quote>
The bean/@id attribute relaxing is fantastic thanks!
I can now use the Spring Framework as an Action Factory for=20
Xwork/WebWork with no duplcation of configuration, using spring to=20
define business related interceptors : components, transactions,=20
security and webwork to provide web/view oriented interceptors :=20
request-params, validation
xwork.xml snippet :
<package name=3D"admin" namespace=3D"/admin" extends=3D"default">
<action name=3D"update" class=3D"com.project.AdminUpdateAction" =
method=3D"txUpdate">
<result name=3D"redirect">read.action?id=3D${id}</result>
</action>
</package>
applicationContext.xml snippet :
<bean name=3D"/admin/update" =
class=3D"com.datacodex.spring.webwork.WebworkActionFactoryBean">
<property name=3D"sessionFactory">
<ref local=3D"sessionFactory"/>
</property>
<property name=3D"transactionManager">
<ref local=3D"transactionManager"/>
</property>
<property name=3D"transactionAttributes">
<ref local=3D"defaultActionTransactionAttributes"/>
</property>
</bean>
very simple, neat and clean !
Thanks guys for your fantastic framework.
Cameron.
</quote>
I don't know how his integration approach works in detail but it looks =
promising. Cameron, can you give any in-depth insights? I assume the =
WebworkActionFactoryBean creates the action, being given the class name =
from the XWork definition? How does XWork know that it needs to delegate =
to the corresponding WebWorkActionFactoryBean - I guess via some custom =
XWork action factory? How does that action factory look up the Spring =
application context?
=20
I have made a few posts on the webwork mailing list.
See =
http://www.mail-archive.com/ope...@li.../ms=
g05919.html to start the thread - since then I have attempted to =
implement some of these ideas.
A basic summary :
I extended the WebWork ServletDispatcher, writing a new =
SpringServletDispatcher, it makes a call to the static =
ActionProxyFactory.setFactory(new=20
SpringActionProxyFactory()). =20
SpringActionProxyFactory extends the DefaultActionProxyFactory which =
overrides createActionInvocation to use=20
a SpringActionInvocation
SpringActionInvocation extends DefaultActionInvocation which overrides =
createAction to delegate to =
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBe=
an(beanName)=20
to use the factory within spring to contruct this action.
The servletContext is obtained using a webwork static helper that =
retrieves it from the action context (threadlocal)
This level of integration is only required if you want to use spring as =
the action factory.
Most often you will only want to use spring to provide the components =
that the actions use, which I think is a better soloution.
As an alternative, I still see value in extending XWork's XML action =
definition format with a <ref> tag, in addition to the existing <param> =
tag. Those ref tags could then get resolved via a ReferenceResolver =
interface, possibly with a SpringReferenceResolver implementation that =
looks up the reference names in an application context. I've suggested =
that a while ago, but I don't think that anyone has adopted the idea =
yet, as it involves an extension of the XWork core.
=20
I really like your idea of supporting an external ref type tag as core =
in xwork/webwork since it offers the simplest, and most elegent =
soloution.
<action name=3D"listAccounts" class=3D"project.controller.ListAccounts">
...
<ref name=3D"accountsDao">accountsDao</ref>
...
</action>
Using one of these later ideas means that the action and refrences are =
totally defined in the webwork configuration, and components are defined =
in spring, which is a good separation in my mind.
When using spring as the action facory I was starting to find it =
difficult to see what was going on in regards to the actions since some =
configuration was done in xwork.xml and some in the spring context.
I can have a go at adding <ref> support to the xwork configuration code =
- in my snadbox. In the meantime we can discuss further and see what =
the other webwork developers think.
Before reading about this idea, I implemented a simple prototype (not =
production ready) system to get components from spring using a webwork =
interceptor. =20
What happens here is you configure the interceptor in the xwork.xml file =
just like any other webwork interceptor, using parameter to provide a =
mapping of action proeprty to spring bean name.
see =
http://www.mail-archive.com/ope...@li.../ms=
g05957.html
A basic summary :
<action name=3D"listAccounts" class=3D"project.controller.ListAccounts">
...
<interceptor-ref name=3D"springComponent">
<param name=3D"mapping">
accountsDao=3DaccountsDao
</param>
</interceptor-ref>
...
</action>
this example reflectively invokes =
action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext=
(servletContext).getBean(beanName))
obtaining the servlet context from the action context.
I would prefer to use the <ref> tag since it is a lot more meaningful, =
and allows for plugable RefrenceResolvers .
Thanks,
Cameron
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Lars Fischer
Sent: Wednesday, November 12, 2003 11:32 AM
To: spr...@li...
Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
found in subject
I think it would be a good idea to put a focus on WebWork 2 integration.
WebWork is a very popular framework and I think Spring would gain
further popularity when providing a way to integrate WebWork "out of the
box".
IMO the main advantage of WebWork is that it's very easy to understand =
even
with missing documentation. Spring MVC maybe technically superior
(I don't know) but it's too complicated to get started with.
The combination of Spring as Container and WebWork 2 as MVC framework
is very powerful.
What do you think about this ?
Regards,
Lars
|
|
From: Rod J. <rod...@in...> - 2003-11-12 12:08:26
|
Mark, At the moment it's equivalent to each bean instance managing its own POJOs, just as if you created them using the new operator. What I am considering is adding an additional parent bean factory that is a singleton. This enables common objects to be shared. What might be even nicer would be 3 tiers: 1. shared across JVM 2. shared per EJB deployment 3. per EJB instance The only problem is that using a singleton at all in an EJB context is somewhat fraught. E.g. it won't work across a cluster. Regards, Rod ----- Original Message ----- From: "MacMahon, Mark" <M.M...@em...> To: <spr...@li...> Sent: Wednesday, November 12, 2003 11:51 AM Subject: [Springframework-developer] AbstractEnterpriseBean+mutiple beanfactory instances problem > > Hi All, > > I just have a quick question regarding the use of Spring from a > Stateful/Stateless session bean. > > If Each implementation of Spring's AbstractEnterpriseBean loads its own > BeanFactory, how can I guarantee that the beans loaded from the BeanFactory > are truly singleton? > > Shouldn't the XmlBeanFactoryLoader keep a static reference to the > BeanFactory to ensure that it is loaded only once in a JVM and thus shared > across all Session Bean instances in the instance pool? > Am I missing something? > > Thanks in advance, > > Mark. > > > ____________________________________________________ > > emuse technologies > U24 Trinity Enterprise Centre, Pearse Street, Dublin 2, Ireland. > Tel: +353 (0)1 6717317 Fax: +353 (0)1 6717319 > website: <http://www.emusetechnologies.com/> > email: in...@em... <mailto:in...@em...> > ____________________________________________________ > > This message has been scanned for viruses using GroupShield for Exchange > Server. > > CONFIDENTIALITY NOTICE - The information contained in this email message is > intended only for confidential use of the named recipient. If the reader is > not the intended recipient or the person responsible for delivering it to > the recipient, you are hereby notified that you have received this > communication in error and that any review, dissemination or copying of this > communication is strictly prohibited. If you have received this in error, > please notify the sender immediately. > > The information, opinions and recommendations contained herein are and must > be construed solely as statements of opinion and not statements of fact. No > warranty, expressed or implied, as to the accuracy, timeliness, > completeness, merchantability or fitness for any particular purpose of any > such recommendation or information is given or made by emuse technologies in > any form or manner whatsoever. > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: MacMahon, M. <M.M...@em...> - 2003-11-12 11:57:28
|
Hi All, I just have a quick question regarding the use of Spring from a Stateful/Stateless session bean. If Each implementation of Spring's AbstractEnterpriseBean loads its own BeanFactory, how can I guarantee that the beans loaded from the BeanFactory are truly singleton? Shouldn't the XmlBeanFactoryLoader keep a static reference to the BeanFactory to ensure that it is loaded only once in a JVM and thus shared across all Session Bean instances in the instance pool? Am I missing something? Thanks in advance, Mark. ____________________________________________________ emuse technologies U24 Trinity Enterprise Centre, Pearse Street, Dublin 2, Ireland. Tel: +353 (0)1 6717317 Fax: +353 (0)1 6717319 website: <http://www.emusetechnologies.com/> email: in...@em... <mailto:in...@em...> ____________________________________________________ This message has been scanned for viruses using GroupShield for Exchange Server. CONFIDENTIALITY NOTICE - The information contained in this email message is intended only for confidential use of the named recipient. If the reader is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately. The information, opinions and recommendations contained herein are and must be construed solely as statements of opinion and not statements of fact. No warranty, expressed or implied, as to the accuracy, timeliness, completeness, merchantability or fitness for any particular purpose of any such recommendation or information is given or made by emuse technologies in any form or manner whatsoever. |
|
From: Cameron B. <ca...@da...> - 2003-11-12 11:39:56
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
jürgen höller [werk3AT] wrote:<br>
<blockquote type="cite"
cite="mid...@co...">
<pre wrap="">Hi Lars,
Cameron Braid has been working on XWork/WebWork2 integration and obviously been pleased with it (you can search our mailing list archives for the whole thread).
<quote>
The bean/@id attribute relaxing is fantastic thanks!
I can now use the Spring Framework as an Action Factory for
Xwork/WebWork with no duplcation of configuration, using spring to
define business related interceptors : components, transactions,
security and webwork to provide web/view oriented interceptors :
request-params, validation
xwork.xml snippet :
<package name="admin" namespace="/admin" extends="default">
<action name="update" class="com.project.AdminUpdateAction" method="txUpdate">
<result name="redirect">read.action?id=${id}</result>
</action>
</package>
applicationContext.xml snippet :
<bean name="/admin/update" class="com.datacodex.spring.webwork.WebworkActionFactoryBean">
<property name="sessionFactory">
<ref local="sessionFactory"/>
</property>
<property name="transactionManager">
<ref local="transactionManager"/>
</property>
<property name="transactionAttributes">
<ref local="defaultActionTransactionAttributes"/>
</property>
</bean>
very simple, neat and clean !
Thanks guys for your fantastic framework.
Cameron.
</quote>
I don't know how his integration approach works in detail but it looks promising. Cameron, can you give any in-depth insights? I assume the WebworkActionFactoryBean creates the action, being given the class name from the XWork definition? How does XWork know that it needs to delegate to the corresponding WebWorkActionFactoryBean - I guess via some custom XWork action factory? How does that action factory look up the Spring application context?
</pre>
</blockquote>
I have made a few posts on the webwork mailing list.<br>
<br>
See
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg05919.html">http://www.mail-archive.com/ope...@li.../msg05919.html</a>
to start the thread - since then I have attempted to implement some of
these ideas.<br>
<br>
<u>A basic summary :</u><br>
<br>
I extended the WebWork ServletDispatcher, writing a new
SpringServletDispatcher, it makes a call to the static
ActionProxyFactory.setFactory(new <br>
SpringActionProxyFactory()). <br>
<br>
SpringActionProxyFactory extends the DefaultActionProxyFactory which
overrides createActionInvocation to use <br>
a SpringActionInvocation<br>
<br>
SpringActionInvocation extends DefaultActionInvocation which
overrides createAction to delegate to
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(beanName)
<br>
to use the factory within spring to contruct this action.<br>
<br>
The servletContext is obtained using a webwork static helper that
retrieves it from the action context (threadlocal)<br>
<br>
This level of integration is only required if you want to use spring as
the action factory.<br>
<br>
Most often you will only want to use spring to provide the components
that the actions use, which I think is a better soloution.<br>
<br>
<blockquote type="cite"
cite="mid...@co...">
<pre wrap="">As an alternative, I still see value in extending XWork's XML action definition format with a <ref> tag, in addition to the existing <param> tag. Those ref tags could then get resolved via a ReferenceResolver interface, possibly with a SpringReferenceResolver implementation that looks up the reference names in an application context. I've suggested that a while ago, but I don't think that anyone has adopted the idea yet, as it involves an extension of the XWork core.
</pre>
</blockquote>
I really like your idea of supporting an external ref type tag as core
in xwork/webwork since it offers the simplest, and most elegent
soloution.<br>
<pre><font face="Courier New, Courier, monospace"><action name="listAccounts" class="project.controller.ListAccounts">
...</font></pre>
<pre><font face="Courier New, Courier, monospace"> <ref name="accountsDao">accountsDao</ref></font></pre>
<pre><font face="Courier New, Courier, monospace"> ...</font></pre>
<pre><font face="Courier New, Courier, monospace"></action></font></pre>
Using one of these later ideas means that the action and refrences are
totally defined in the webwork configuration, and components are
defined in spring, which is a good separation in my mind.<br>
<br>
When using spring as the action facory I was starting to find it
difficult to see what was going on in regards to the actions since some
configuration was done in xwork.xml and some in the spring context.<br>
<br>
I can have a go at adding <ref> support to the xwork
configuration code - in my snadbox. In the meantime we can discuss
further and see what the other webwork developers think.<br>
<br>
Before reading about this idea, I implemented a simple prototype (not
production ready) system to get components from spring using a webwork
interceptor. <br>
<br>
What
happens here is you configure the interceptor in the xwork.xml file
just like any other webwork interceptor, using parameter to provide a
mapping of action proeprty to spring bean name.<br>
<br>
see
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg05957.html">http://www.mail-archive.com/ope...@li.../msg05957.html</a><br>
<br>
<u>A basic summary :</u><br>
<pre>
<font face="Courier New, Courier, monospace"><action name="listAccounts" class="project.controller.ListAccounts">
...</font></pre>
<pre><font face="Courier New, Courier, monospace"> <interceptor-ref name="springComponent"></font></pre>
<pre><font face="Courier New, Courier, monospace"> <param name="mapping"></font></pre>
<pre><font face="Courier New, Courier, monospace"> accountsDao=accountsDao</font></pre>
<pre><font face="Courier New, Courier, monospace"> </param></font></pre>
<pre><font face="Courier New, Courier, monospace"> </interceptor-ref></font></pre>
<pre><font face="Courier New, Courier, monospace"> ...</font></pre>
<pre><font face="Courier New, Courier, monospace"></action></font></pre>
this example reflectively invokes
action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(beanName))<br>
obtaining the servlet context from the action context.<br>
<br>
I would prefer to use the <ref> tag since it is a lot more
meaningful, and allows for plugable RefrenceResolvers .<br>
<br>
Thanks,<br>
<br>
Cameron<br>
<br>
<blockquote type="cite"
cite="mid...@co...">
<pre wrap="">Juergen
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
[<a class="moz-txt-link-freetext" href="mailto:spr...@li...">mailto:spr...@li...</a>]On Behalf
Of Lars Fischer
Sent: Wednesday, November 12, 2003 11:32 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
found in subject
I think it would be a good idea to put a focus on WebWork 2 integration.
WebWork is a very popular framework and I think Spring would gain
further popularity when providing a way to integrate WebWork "out of the
box".
IMO the main advantage of WebWork is that it's very easy to understand even
with missing documentation. Spring MVC maybe technically superior
(I don't know) but it's too complicated to get started with.
The combination of Spring as Container and WebWork 2 as MVC framework
is very powerful.
What do you think about this ?
Regards,
Lars
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Do you not think that configuring some of this peripheral
data should be at the view level? If not the view, then
where..? In common scenarios I come across, the secondary
model is quite specific to a view (though not of course the
TYPE of view)
</pre>
</blockquote>
<pre wrap="">>From what I've seen there's three commons scenerio's
1. Reference data needed to render the view. This is the stuff we have
already.
2. Data related to the view but not necessarily needed to render it
(additional news in a sidebox, perhaps a menu).
3. Componentized views having corresponding controller (portlet)
The first case can perfectly be implemented using our current reference
data implementation (a list of elements in a select box of a form for
instance). One controller, having reference data, specifically belonging
to the controller
The second case (sideboxes containing news, a menu that needs
information not related to the main view) I consider to be a simple
Tiles approach and I think a somewhat more advanced version of the
reference data features we have now, would do. Something like you
proposed maybe. Reference data, however, not in fact related to the
controller!
The third case however, is a completely different one and somewhat looks
like the portlet approach. I think this is a bit too far-fetched to
implement in Spring, although I'd like to offer view-tech independent
stuff for this. Parallel controllers rendering views independent of
eachother.
It's just some rambling, but maybe we could brainstorm about this more
in order to come with something brilliant :)...
Alef
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! <a class="moz-txt-link-freetext" href="http://www.apachecon.com/">http://www.apachecon.com/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>
</pre>
</blockquote>
<pre wrap=""><!---->
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! <a class="moz-txt-link-freetext" href="http://www.apachecon.com/">http://www.apachecon.com/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! <a class="moz-txt-link-freetext" href="http://www.apachecon.com/">http://www.apachecon.com/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72" class="moz-signature">--
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler <a class="moz-txt-link-freetext" href="http://www.martinfowler.com/distributedComputing/refactoring.pdf">http://www.martinfowler.com/distributedComputing/refactoring.pdf</a>]</pre>
</body>
</html>
|
|
From: <jue...@we...> - 2003-11-12 11:05:51
|
Hi Lars,
Cameron Braid has been working on XWork/WebWork2 integration and =
obviously been pleased with it (you can search our mailing list archives =
for the whole thread).
<quote>
The bean/@id attribute relaxing is fantastic thanks!
I can now use the Spring Framework as an Action Factory for=20
Xwork/WebWork with no duplcation of configuration, using spring to=20
define business related interceptors : components, transactions,=20
security and webwork to provide web/view oriented interceptors :=20
request-params, validation
xwork.xml snippet :
<package name=3D"admin" namespace=3D"/admin" extends=3D"default">
<action name=3D"update" class=3D"com.project.AdminUpdateAction" =
method=3D"txUpdate">
<result name=3D"redirect">read.action?id=3D${id}</result>
</action>
</package>
applicationContext.xml snippet :
<bean name=3D"/admin/update" =
class=3D"com.datacodex.spring.webwork.WebworkActionFactoryBean">
<property name=3D"sessionFactory">
<ref local=3D"sessionFactory"/>
</property>
<property name=3D"transactionManager">
<ref local=3D"transactionManager"/>
</property>
<property name=3D"transactionAttributes">
<ref local=3D"defaultActionTransactionAttributes"/>
</property>
</bean>
very simple, neat and clean !
Thanks guys for your fantastic framework.
Cameron.
</quote>
I don't know how his integration approach works in detail but it looks =
promising. Cameron, can you give any in-depth insights? I assume the =
WebworkActionFactoryBean creates the action, being given the class name =
from the XWork definition? How does XWork know that it needs to delegate =
to the corresponding WebWorkActionFactoryBean - I guess via some custom =
XWork action factory? How does that action factory look up the Spring =
application context?
As an alternative, I still see value in extending XWork's XML action =
definition format with a <ref> tag, in addition to the existing <param> =
tag. Those ref tags could then get resolved via a ReferenceResolver =
interface, possibly with a SpringReferenceResolver implementation that =
looks up the reference names in an application context. I've suggested =
that a while ago, but I don't think that anyone has adopted the idea =
yet, as it involves an extension of the XWork core.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Lars Fischer
Sent: Wednesday, November 12, 2003 11:32 AM
To: spr...@li...
Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
found in subject
I think it would be a good idea to put a focus on WebWork 2 integration.
WebWork is a very popular framework and I think Spring would gain
further popularity when providing a way to integrate WebWork "out of the
box".
IMO the main advantage of WebWork is that it's very easy to understand =
even
with missing documentation. Spring MVC maybe technically superior
(I don't know) but it's too complicated to get started with.
The combination of Spring as Container and WebWork 2 as MVC framework
is very powerful.
What do you think about this ?
Regards,
Lars
> > Do you not think that configuring some of this peripheral=20
> > data should be at the view level? If not the view, then=20
> > where..? In common scenarios I come across, the secondary=20
> > model is quite specific to a view (though not of course the=20
> > TYPE of view)
>=20
> >From what I've seen there's three commons scenerio's
>=20
> 1. Reference data needed to render the view. This is the stuff we have
> already.
> 2. Data related to the view but not necessarily needed to render it
> (additional news in a sidebox, perhaps a menu).
> 3. Componentized views having corresponding controller (portlet)
>=20
> The first case can perfectly be implemented using our current =
reference
> data implementation (a list of elements in a select box of a form for
> instance). One controller, having reference data, specifically =
belonging
> to the controller
>=20
> The second case (sideboxes containing news, a menu that needs
> information not related to the main view) I consider to be a simple
> Tiles approach and I think a somewhat more advanced version of the
> reference data features we have now, would do. Something like you
> proposed maybe. Reference data, however, not in fact related to the
> controller!
>=20
> The third case however, is a completely different one and somewhat =
looks
> like the portlet approach. I think this is a bit too far-fetched to
> implement in Spring, although I'd like to offer view-tech independent
> stuff for this. Parallel controllers rendering views independent of
> eachother.
>=20
> It's just some rambling, but maybe we could brainstorm about this more
> in order to come with something brilliant :)...
>=20
> Alef
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <dar...@hs...> - 2003-11-12 10:37:40
|
<Alef> From what I've seen there's three commons scenerio's 1. Reference data needed to render the view. This is the stuff we have already. 2. Data related to the view but not necessarily needed to render it (additional news in a sidebox, perhaps a menu). 3. Componentized views having corresponding controller (portlet) The first case can perfectly be implemented using our current reference data implementation (a list of elements in a select box of a form for instance). One controller, having reference data, specifically belonging to the controller The second case (sideboxes containing news, a menu that needs information not related to the main view) I consider to be a simple Tiles approach and I think a somewhat more advanced version of the reference data features we have now, would do. Something like you proposed maybe. Reference data, however, not in fact related to the controller! The third case however, is a completely different one and somewhat looks like the portlet approach. I think this is a bit too far-fetched to implement in Spring, although I'd like to offer view-tech independent stuff for this. Parallel controllers rendering views independent of eachother. It's just some rambling, but maybe we could brainstorm about this more in order to come with something brilliant :)... </Alef> Hi Alef, We're definitely on the same wavelength here, and you're right - it's the 2nd scenario that I was focusing on earlier. Portlets are indeed a very different kettle of fish. As Juergen just mentioned, some changes were made yesterday co-incidentally that I wasn't aware of, but which may facilitate efforts in this direction. I'll go and see what's different and gather some more thoughts. Cheers! Darren. _____________________________________________________ This transmission has been issued by a member of the HSBC Group "HSBC" for the information of the addressee only and should not be reproduced and / or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy. |
|
From: Lars F. <lar...@gm...> - 2003-11-12 10:32:56
|
I think it would be a good idea to put a focus on WebWork 2 integration. WebWork is a very popular framework and I think Spring would gain further popularity when providing a way to integrate WebWork "out of the box". IMO the main advantage of WebWork is that it's very easy to understand even with missing documentation. Spring MVC maybe technically superior (I don't know) but it's too complicated to get started with. The combination of Spring as Container and WebWork 2 as MVC framework is very powerful. What do you think about this ? Regards, Lars > > Do you not think that configuring some of this peripheral > > data should be at the view level? If not the view, then > > where..? In common scenarios I come across, the secondary > > model is quite specific to a view (though not of course the > > TYPE of view) > > >From what I've seen there's three commons scenerio's > > 1. Reference data needed to render the view. This is the stuff we have > already. > 2. Data related to the view but not necessarily needed to render it > (additional news in a sidebox, perhaps a menu). > 3. Componentized views having corresponding controller (portlet) > > The first case can perfectly be implemented using our current reference > data implementation (a list of elements in a select box of a form for > instance). One controller, having reference data, specifically belonging > to the controller > > The second case (sideboxes containing news, a menu that needs > information not related to the main view) I consider to be a simple > Tiles approach and I think a somewhat more advanced version of the > reference data features we have now, would do. Something like you > proposed maybe. Reference data, however, not in fact related to the > controller! > > The third case however, is a completely different one and somewhat looks > like the portlet approach. I think this is a bit too far-fetched to > implement in Spring, although I'd like to offer view-tech independent > stuff for this. Parallel controllers rendering views independent of > eachother. > > It's just some rambling, but maybe we could brainstorm about this more > in order to come with something brilliant :)... > > Alef > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <dar...@hs...> - 2003-11-12 10:31:26
|
<Juergen> I don't know if you've noticed that I've added a related feature yesterday: AbstractView has now not only the standard setAttributes(Properties) and setAttributesCSV(String) but also setAttributesMap(Map). The latter allows not only for String values but also for refs, lists, maps, and props as static model attributes. </Juergen> Actually I wasn't aware when I scribbled down my thoughts. Spooky! I'll familiarise myself with it all pronto. Regards, Darren _____________________________________________________ This transmission has been issued by a member of the HSBC Group "HSBC" for the information of the addressee only and should not be reproduced and / or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy. |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-11-12 10:06:43
|
> Do you not think that configuring some of this peripheral > data should be at the view level? If not the view, then > where..? In common scenarios I come across, the secondary > model is quite specific to a view (though not of course the > TYPE of view) From what I've seen there's three commons scenerio's 1. Reference data needed to render the view. This is the stuff we have already. 2. Data related to the view but not necessarily needed to render it (additional news in a sidebox, perhaps a menu). 3. Componentized views having corresponding controller (portlet) The first case can perfectly be implemented using our current reference data implementation (a list of elements in a select box of a form for instance). One controller, having reference data, specifically belonging to the controller The second case (sideboxes containing news, a menu that needs information not related to the main view) I consider to be a simple Tiles approach and I think a somewhat more advanced version of the reference data features we have now, would do. Something like you proposed maybe. Reference data, however, not in fact related to the controller! The third case however, is a completely different one and somewhat looks like the portlet approach. I think this is a bit too far-fetched to implement in Spring, although I'd like to offer view-tech independent stuff for this. Parallel controllers rendering views independent of eachother. It's just some rambling, but maybe we could brainstorm about this more in order to come with something brilliant :)... Alef |
|
From: <jue...@we...> - 2003-11-12 10:02:38
|
Darren,
I don't know if you've noticed that I've added a related feature =
yesterday: AbstractView has now not only the standard =
setAttributes(Properties) and setAttributesCSV(String) but also =
setAttributesMap(Map). The latter allows not only for String values but =
also for refs, lists, maps, and props as static model attributes.
To make refs work, I've reworked XmlViewResolver and =
ResourceBundleViewResolver to create their view bean factories as =
children of the surrounding application context. Else, you would not be =
able to reference beans in the application context from view =
definitions.
To not put beans themselves as static attributes into the model but =
rather other objects, maybe use a FactoryBean that returns the model =
attribute? The name of the attribute would be determined by the map key =
in the view definition then. It might still make sense to support a =
special ModelReference bean that creates a whole map of attribute =
key/value pairs.
And BTW, <ref external=3D"..."/> is somewhat deprecated as there is no =
strict check for just referencing external beans. <ref bean=3D"..."/> is =
now the generic one that can reference any bean in any reachable =
context, while <ref local=3D"..."/> can just reference local beans in =
the same XML file (via XML ids).
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Wednesday, November 12, 2003 2:50 AM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] About MVC - Email
found in subject
On Tuesday 11 November 2003 23:27, Darren Davison wrote:
> Is there something already in Spring MVC that lends itself to this =
kind
> of behaviour?
without really thinking this through much (since it's gone 1:30am and I =
have=20
to be up again in 4 hours)..
If an interface..
public interface ModelReference {
public Map getModel();
}
.. is implemented by some arbitrary business objects, then a view could =
be=20
defined as..
<bean id=3D"myVelocityView"
class=3D"org.springframework.web.servlet.view.velocity.VelocityView">
<property name=3D"templateName"><value>main.vm</value></property> =20
<!-- standard attribs -->
<property name=3D"attributes">
<props>
<prop key=3D"title">A Velocity Page</prop>
</props>
</property> =20
<!-- new property: list of ModelReference implementing bus. objects =
-->
<property name=3D"references">
<list>
<ref external=3D"myBean"/>
<ref external=3D"myOtherBean"/>
</list>
</property> =20
</bean>
AbstractView is amended with the following (part pseudo-code)..
public abstract class AbstractView extends WebApplicationObjectSupport=20
implements View {
//added
private Map referenceObjects =3D new HashMap();
...
//added
public final void setReferencesList(List references) { =20
for each list item
get bean from app context if exists
if bean instanceof ModelReference=20
call bean.getModel()=20
consolidate into referenceObjects field
end
end
}
//amended
public final void render(Map model, HttpServletRequest request,=20
HttpServletResponse response)
=20
...
Map mergedModel =3D new HashMap(this.staticAttributes);
mergedModel.putAll(referenceObjects);
mergedModel.putAll(model);
...
}
}
- The controller still has final say and can overwrite model values =
from=20
the static list or the reference list
- Arbitrary beans can now add to the model that a view renders on a per =
view basis taking advantage of whatever container resources or custom =
logic=20
is required
- multiple views can use the same ref objects via the hierarchical view =
structure
- It's a kind of half-way house between static attributes and model =
data=20
returned by the controller but as shown isn't parameterised so =
reasonably=20
rigid
- maybe the interface can be dropped and the actual method to call for =
any=20
given bean can be specified in the config too. One less dependency for =
the=20
business object
Goodnight.
--=20
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Rod J. <rod...@in...> - 2003-11-12 09:35:30
|
Good point. dist and docs/api are pretty common practice. ----- Original Message ----- From: "jürgen höller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Wednesday, November 12, 2003 9:20 AM Subject: Re: [Springframework-developer] Moving all build output under 'target' I don't mind the ".classes"/".testclasses"/etc directories being moved, but I'm not so sure about the "dist" and "docs/api" directories. They are the ones that get included in the release zips, at exactly that location: The release zip directory structure matches our CVS module structure 1:1 currently (omitting a lot of directories of course), and I believe that's a good thing. Thus, I'd like to keep the docs/api and dist directories where they are. The Petclinic and Countries sample apps use similar directories in their build scripts, so this is consistent within the whole project. And switching from a release zip to a CVS snapshot is straightforward, as the directory structures match. Juergen Von: spr...@li... im Auftrag von Rod Johnson Gesendet: Mi 12.11.2003 09:14 An: spr...@li... Betreff: Re: [Springframework-developer] Moving all build output under 'target' > Does anybody object to me changing the build to put all directories (and > thus all artifacts) produced by the build to be under a top-level dir > called 'target'? I don't find the present setup, with 'x' number of > directories produced under the project root, to be too clean or very > standard. Good idea. ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
1239 messages has been excluded from this view by a project administrator.
