springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Spring wiki

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

Mike told me that it would have been available this week=2E Didn=27t hear=
 from him=2E=2E=2E

Dmitriy=2E

----- Original Message -----
From=3A j=C3=BCrgen h=C3=B6ller =5Bwerk3AT=5D =3Cjuergen=2Ehoeller=40werk=
3at=2Ecom=3E
Date=3A Tuesday=2C April 13=2C 2004 5=3A02 pm
Subject=3A =5BSpringframework-developer=5D Spring wiki

=3E Guys=2C
=3E =

=3E We need a wiki ASAP=2C most importantly for preliminary docs on =

=3E upcoming 1=2E1 features that aren=27t covered in the reference docs =

=3E yet=2E Any volunteers for proceeding with a Confluence setup=3F Not =

=3E only Pico but even TSS have a Confluence instance now=2E=2E=2E Spring=
 =

=3E really deserves one too=2C particularly as it=27s used within =

=3E Confluence itself =3A-)
=3E =

=3E Juergen
=3E =

=3E =

=3E -------------------------------------------------------
=3E This SF=2ENet email is sponsored by=3A IBM Linux Tutorials
=3E Free Linux tutorial presented by Daniel Robbins=2C President and CEO =
of
=3E GenToo technologies=2E Learn everything from fundamentals to system
=3E administration=2Ehttp=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=1470=26alloc=5F=
id638=26op=3Dclick
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E Springframework-developer mailing list
=3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframework-de=
veloper
=3E 

[Springframework-developer] Spring wiki

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

Guys,
=20
We need a wiki ASAP, most importantly for preliminary docs on upcoming =
1.1 features that aren't covered in the reference docs yet. Any =
volunteers for proceeding with a Confluence setup? Not only Pico but =
even TSS have a Confluence instance now... Spring really deserves one =
too, particularly as it's used within Confluence itself :-)
=20
Juergen

Re: [Springframework-developer] Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

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

Torsten,
=20
Sorry for the late reply - I think I finally got it ;-)
=20
Regarding the version number, it's OK to stay with 1.0.0 if that is =
recommended for Eclipse plugins. (I noticed this with FreeMarker's =
Eclipse plugin too.) I'll also leave the file name as-is if you say it =
is viable :-)
=20
I'll do the actual upload to SourceForge together with Spring 1.0.1 on =
Sunday. I'd also like to announce the plugin release in the Spring 1.0.1 =
announcement mail.
=20
So if you encounter any issues till Sunday, feel free to address them =
and send me a new zip. Has anyone else already tried this plugin =
release?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Torsten Juergeleit
Gesendet: Mi 07.04.2004 18:01
An: spr...@li...
Betreff: Re: [Springframework-developer] Spring IDE - Eclipse Plugin: =
Migration of SpringUI finished; Version 1.0.0 ready



J=FCrgen,

some infos regarding "Eclipse for Runaways" ;-)

> Ehm, (Eclipse newbie here), you want me to upload
> the updatesite zip as file release? Shouldn't it
> rather be some installation zip a la
> "spring-ide-eclipse.zip"?

The file
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/upda=
tesite_1.0.0.zip
is not a "normal" archive with Eclipse plugins which
you can unzip in the Eclipse plugins folder. Instead
it's a copy of the whole update site
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/
which you can download (and use locally) if you are
sitting behind a restrictive proxy / firewall (like me
:-( ) which does not allow your Eclipse update manager
to install Eclipse plugins via an internet connection.

Distributing Eclipse plugins via the Eclipse update
manager mechanism is the way recommended by the
Eclipse team. The update site (which allows to install
the plugins via Eclipse update manager) should be IMHO
our preferred distribution channel. The additional
file release is only a goody for corporate admins
supporting a network installation of multiple Eclipse
users or Eclipse users behind a restricted proxy.

With the update site we have no information about the
download / usage count. But who cares about numbers
;-)


IMHO using the prefix "spring-ide-" for the file
release of the update site is redundant. This prefix
is the same as the package name of the corresponding
file release. So we will have (in addition to the
already existing file release package
"springframework") a new package named "spring-ide /
eclipse" or "spring-ide-eclipse".

For an example please refer to the old SpringUI file
releases
http://sourceforge.net/project/showfiles.php?group_id=3D99715


> Regarding the version number, we use "1.0" rather
> than "1.0.0" with the Spring distribution itself, so
> it's probably advisable to use the same numbering
> scheme with the Eclipse plugin.

Hhmm, the versioning schema for Eclipse plugins /
features / fragments is <major>.<minor>.<service>.

Quote from
http://www.eclipse.org/documentation/html/plugins/org.eclipse.platform.do=
c.isv/doc/reference/misc/eclipse_install.html
:

"...
The version identifier follows the format defined by
Eclipse for plug-in version identifiers (see javadoc
for PluginVersionIdentifier class). It is a 3-part
numeric identifier consisting of major, minor and
service components (eg. 2.4.11)
..."

No problem with an initial release 1.0 but how about
maintenance releases?


Btw. where should the Eclipse update site be hosted?
Is
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/
ok?

If we are hosting it on
http://www.springframework.org/ then we need a place
to upload new versions ready to be transfered to our
website. IMHO sending new versions via mail is no
viable option.

Torsten

--- j=FCrgen_h=F6ller_[werk3AT]
<jue...@we...> wrote:
> Torsten,
>
> Ehm, (Eclipse newbie here), you want me to upload
> the updatesite zip as file release? Shouldn't it
> rather be some installation zip a la
> "spring-ide-eclipse.zip"? I guess I have to learn
> something about how Eclipse plugins are distributed
> :-)
>
> Regarding the version number, we use "1.0" rather
> than "1.0.0" with the Spring distribution itself, so
> it's probably advisable to use the same numbering
> scheme with the Eclipse plugin.
>
> As we're about to release Spring 1.0.1 next week,
> I'd like to do the Eclipse plugin 1.0 release in the
> same SourceForge upload session, and annouce both in
> the same mail. So there's still time to educate me
> in terms of Eclipse plugin distributions ;-)
>
> Juergen
>
>
> -----Original Message-----
> From:
>
spr...@li...
>
[mailto:spr...@li...]On
> Behalf
> Of Torsten Juergeleit
> Sent: Monday, April 05, 2004 10:43 PM
> To: spr...@li...
> Subject: [Springframework-developer] Spring IDE -
> Eclipse Plugin:
> Migration of SpringUI finished; Version 1.0.0 ready
>
>
> I finished migrating the SpringUI Eclipse plugin
> into
> the Spring CVS (new module 'spring-ide/eclipse/').
>
> Now I am looking for a place to host the Eclipse
> plugin's update site (web site with a config XML
> file
> and two folders holding the plugin data). The update
> site is used by Eclipse's update manager to download
> different versions of the plugin directly from with
> the IDE. Also an HTML file and a few screen copies
> (with some infos about the plugin and it's update
> site) has to be hosted somewhere.
>
> To give an example I have stored the stuff in
> Spring's
> (unused) webspace on SF.NET. The installation infos
> can be found on
>
http://springframework.sourceforge.net/spring-ide/eclipse/
> and the update site is available from
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/.
>
>
> Does it make sense to host the plugin's update site
> and the corresponding HTML page on
> http://www.springframework.org/ or is SF.NET ok (the
> download of the Spring framework itself is hosted on
> SF.NET too)?
>
>
> J=FCrgen, you can create a file release on SF.NET for
> the plugin, if you like. The corresponding archive
> with version 1.0.0 of the plugin's update site is
> available from
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/upda=
tesite_1.0.0.zip.
>
> Torsten
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
> http://promotions.yahoo.com/design_giveaway/
>
>
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet and JSFs

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

But what criteria do you base your dispatching on when there's no URL? =
Request parameters?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Eduardo Issao Ito
Gesendet: Di 13.04.2004 22:15
An: spr...@li...
Betreff: Re: [Springframework-developer] Portlet and JSFs



j=FCrgen h=F6ller [werk3AT] wrote:
>>Portlets can not access the URL that the client used to initiate the =
request on the portal.
>
>
> While that makes sense, it effectively makes me wonder whether we need =
a Portlet dispatcher: With Servlets, dispatching is all about flexible =
URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks, similar =
to doGet, doPost, etc from the Servlet API.
>
> So for typical Portlets, it's probably most important to allow for =
easy access to Spring facilities from those methods, rather than =
dispatch to some other components from a Portlet doView method. Portlet =
support classes similar to the ones I just added for Struts come to my =
mind.
>
> This doesn't seem to be much effort at all. Am I on the wrong track =
here?
>
> Juergen

While in most cases a Portlet should be simple (just display some info),
sometimes one portlet can be a complete web application in itself. In =
this case,
having an MVC framework can make a huge difference. Imagine implementing =
a whole
web application inside a servlet doPost(), and no framework underneath. =
With
portlets you only have doView() to do the same thing...

A PortletDispatcher should be very similar to ServletDispatcher and =
reuse
everything that is possible from the actual mvc framework. Ideally, =
implementing
a portlet with Spring should be the same as implementing a servlet.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

[<jef...@si...>]

> Have a look at http://www.gridsphere.org/gridsphere/gridsphere <

Looks very good. Are there any public sites running gridsphere? URL's?

Jeff W. Boring=20



-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
Nadeem Bitar
Sent: Tuesday, April 13, 2004 1:46 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


On =B2=D0, 2004-04-13 at 11:13 -0400, William G. Thompson, Jr. wrote:

> jef...@si... wrote:
> >>Would anyone be willing and have time to collaborate on this?
> >=20
> >=20
> > yes. I start work next week for a new company where I'll be =
developing a
> > portal product. I have experience with Spring & Hibernate but have =
only
used
> > Struts as the MVC. I am currently evaluating Jetspeed and uPortal.
uPortal
> > has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is =
not
ready
> > yet but they report good progress.
> >=20

Have a look at http://www.gridsphere.org/gridsphere/gridsphere=20

> > If a Spring PortletDispatcher supported JSR-168 then it seems like =
it
would
> > work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?
>=20
> Exactly!
>=20
>   What
> > release of Spring would the PortletDispatcher be in, 1.01 or 1.1?
>=20
> I would push for as soon as it is fully baked...for the timing to =
work=20
> out right for us we'll need something workable in about a month...and =

> hopefully in an official Spring release by August.
>=20
> later.
> Bill
>=20
>=20
> >=20
> > Jeff W. Boring=20
> >=20
> >=20
> >=20
> >=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On =
Behalf
> > Of Ben Alex
> > Sent: Friday, April 09, 2004 2:33 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >=20
> >=20
> > Hi
> >=20
> >=20
> >>JSF and Portlet functionality don't have to be provided in=20
> >>one and the same release. I have been looking a bit into the=20
> >>portlet stuff and it doesn't same all that difficult.
> >>
> >>I think I'll experiment with it during the next couple of=20
> >>weeks. Major issue is the common supporting functionality=20
> >>(ContextLoader, WebAppCtx,
> >>Databinding) between our Web stuff and our future Portlet=20
> >>stuff (and probably also the JSF stuff). Revising the=20
> >>supporting functionality right now (or for 1.1) is not an option =
imo.
> >>
> >>I probably can't avoid having to copy-and-paste a lot of code=20
> >>while experimenting and since that's *not* something we want=20
> >>to have in a release, I'm afraid you're right :(.
> >=20
> >=20
> > Several people have previously mentioned portlets and JSF. We are =
trying
to
> > decide whether to implement portlets in our next project, or just =
stick
to
> > include files and/or something like Sitemesh, Tiles etc.
> >=20
> > Regarding portlets, there is the Pico-based Exo project
> > (http://exo.sourceforge.net/) and Pluto
(http://jakarta.apache.org/pluto/).
> > Has anyone done any work on integrating portlets, JSF or projects =
such
as
> > these into Spring? Would anyone be willing and have time to =
collaborate
on
> > this?
> >=20
> > Best regards
> > Ben
> >=20
> >=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
--=20
************************
Nadeem Bitar
Software Engineer
IzuCode, LLC
858-337-6159
5230 Fiore Terrace #k208
San Diego, Ca 92122
************************=20



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet and JSFs

[Eduardo I. I. <zi...@su...>]

jürgen höller [werk3AT] wrote:
>>Portlets can not access the URL that the client used to initiate the request on the portal.
> 
> 
> While that makes sense, it effectively makes me wonder whether we need a Portlet dispatcher: With Servlets, dispatching is all about flexible URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks, similar to doGet, doPost, etc from the Servlet API.
> 
> So for typical Portlets, it's probably most important to allow for easy access to Spring facilities from those methods, rather than dispatch to some other components from a Portlet doView method. Portlet support classes similar to the ones I just added for Struts come to my mind.
> 
> This doesn't seem to be much effort at all. Am I on the wrong track here?
> 
> Juergen

While in most cases a Portlet should be simple (just display some info), 
sometimes one portlet can be a complete web application in itself. In this case, 
having an MVC framework can make a huge difference. Imagine implementing a whole 
web application inside a servlet doPost(), and no framework underneath. With 
portlets you only have doView() to do the same thing...

A PortletDispatcher should be very similar to ServletDispatcher and reuse 
everything that is possible from the actual mvc framework. Ideally, implementing 
a portlet with Spring should be the same as implementing a servlet.

Re: [Springframework-developer] Portlet and JSFs

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

jürgen höller [werk3AT] wrote:

>>Portlets can not access the URL that the client used to initiate the request on the portal.
> 
> While that makes sense, it effectively makes me wonder whether we need a Portlet dispatcher: With Servlets, dispatching is all about flexible URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks, similar to doGet, doPost, etc from the Servlet API.
> 
> So for typical Portlets, it's probably most important to allow for easy access to Spring facilities from those methods, rather than dispatch to some other components from a Portlet doView method. Portlet support classes similar to the ones I just added for Struts come to my mind.
> 
> This doesn't seem to be much effort at all. Am I on the wrong track here?

I haven't followed the Struts threads, but I think you are on the right 
track...we probably need:

* portlet application context  (specified in portlet config?)
* data binding
* view resolution (we'd like to use jstl)
* perhaps some portlet specific controllers

later.
Bill


> 
> Juergen
> 
> 
>  
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von Faizan Hussain
> Gesendet: Di 13.04.2004 20:38
> An: spr...@li...
> Betreff: RE: [Springframework-developer] Portlet and JSFs
> 
> 
> 
> Please see my comments at the bottom
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> William G. Thompson, Jr.
> Sent: Friday, April 09, 2004 7:35 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
> 
> Ben Alex wrote:
> 
>>Hi Bill
>>
>>
>>
>>>Rutgers is very interested in Spring support for the Portlet
>>>API in the form of a PortletDispatcher as it were.  We run
>>>the uPortal[1] platform and the latest release embeds Pluto. 
>>>We are just now embarking on dev cycle for new porlets that
>>>takes us thru september, if possible these new portlets would
>>>live behind a Spring PortletDispatcher.
>>>
>>>We have had some preliminary dicussions with Alef about what
>>>it might look like, and should be in a better positition to
>>>try out some ideas/code in a few weeks.
>>
>>
>>I took a look at uPortal but wondered how hard it would be to get Spring
> 
> MVC
> 
>>capabilities living within a portlet window. Have you actually done
> 
> anything
> 
>>like this as yet, or are your Spring applications essentially
> 
> "traditional"
> 
>>(dedicated JSP/VM etc)?
>>
> 
> 
> So far all of our Spring apps are "traditional"; leveraging the full
> compliment of the Spring stack (WebMVC, DAO, JDBC Abstraction,
> ApplicationContext, declaritive transaction management, AOP, etc.) and
> living in a dedicated Servlet context.
> 
> We have used Spring DAO/JDBC support for a few simple Channels
> (Portlets), but that is the extent of it.
> 
> We are extremely pleased with the Spring development model and would
> like to bring our portal project in line.
> 
> I don't think it should be too hard to bring SerlvetDispatcher behavior
> to the Portlet API.  The big difference is that Portlets participated in
> a two step call (ActionRequest/Response and RenderRequest/Response) and
> also have additional lifecycle events, PortletMode (View, Edit,
> Help,...) and WindowMode (min, max, normal, etc.) that impact behavior
> of the service.
> 
> later.
> Bill
> 
> Since we got into this discussion, I would like to add few more differences
> between Portlets and Serverlets.
> - Portlets generate fragments, whereas servlets generate complete documents.
> - Unlike servlets portlets are not bound directly to a URL.
> 
> According to my understanding there are few things that portlets have but
> servlets don't
> 
> - Portlets are able to perform portlet rewriting, so as to create links that
> are independent of the portal server implementation
> - portlets has two different session scopes in which to store object:
> application wide and portlet private.
> -Portlets has access to user profile information that is definitely far
> beyond the basic user and role information provided in the servlet
> specifications.
> 
> Similarly there are few things that servlets can do but portlets can not do
> that. For example
> 
> -Portlets can not alter the HTTP headers or set response encoding.
> -Portlets can not access the URL that the client used to initiate the
> request on the portal.
> 
> Later.
> 
> Faizan
> 

RE: [Springframework-developer] Portlet and JSFs

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

Juergen,

I'll look more closely into the Struts support classes tonight...

Bill, Alef, Ben,
what do you think?

Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Tuesday, April 13, 2004 3:12 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


> Portlets can not access the URL that the client used to initiate the=20
> request on the portal.

While that makes sense, it effectively makes me wonder whether we need =
a
Portlet dispatcher: With Servlets, dispatching is all about flexible =
URL
mapping. AFAIK, Portlets have doView, doEdit etc callbacks, similar to
doGet, doPost, etc from the Servlet API.

So for typical Portlets, it's probably most important to allow for easy
access to Spring facilities from those methods, rather than dispatch to =
some
other components from a Portlet doView method. Portlet support classes
similar to the ones I just added for Struts come to my mind.

This doesn't seem to be much effort at all. Am I on the wrong track =
here?

Juergen


=20

________________________________

Von: spr...@li... im Auftrag =
von
Faizan Hussain
Gesendet: Di 13.04.2004 20:38
An: spr...@li...
Betreff: RE: [Springframework-developer] Portlet and JSFs



Please see my comments at the bottom


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On =
Behalf Of
William G. Thompson, Jr.
Sent: Friday, April 09, 2004 7:35 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs

Ben Alex wrote:
> Hi Bill
>
>
>>Rutgers is very interested in Spring support for the Portlet API in=20
>>the form of a PortletDispatcher as it were.  We run the uPortal[1]=20
>>platform and the latest release embeds Pluto. We are just now=20
>>embarking on dev cycle for new porlets that takes us thru september,=20
>>if possible these new portlets would live behind a Spring=20
>>PortletDispatcher.
>>
>>We have had some preliminary dicussions with Alef about what it might =

>>look like, and should be in a better positition to try out some=20
>>ideas/code in a few weeks.
>
>
> I took a look at uPortal but wondered how hard it would be to get=20
> Spring
MVC
> capabilities living within a portlet window. Have you actually done
anything
> like this as yet, or are your Spring applications essentially
"traditional"
> (dedicated JSP/VM etc)?
>

So far all of our Spring apps are "traditional"; leveraging the full
compliment of the Spring stack (WebMVC, DAO, JDBC Abstraction,
ApplicationContext, declaritive transaction management, AOP, etc.) and
living in a dedicated Servlet context.

We have used Spring DAO/JDBC support for a few simple Channels =
(Portlets),
but that is the extent of it.

We are extremely pleased with the Spring development model and would =
like to
bring our portal project in line.

I don't think it should be too hard to bring SerlvetDispatcher behavior =
to
the Portlet API.  The big difference is that Portlets participated in a =
two
step call (ActionRequest/Response and RenderRequest/Response) and also =
have
additional lifecycle events, PortletMode (View, Edit,
Help,...) and WindowMode (min, max, normal, etc.) that impact behavior =
of
the service.

later.
Bill

Since we got into this discussion, I would like to add few more =
differences
between Portlets and Serverlets.
- Portlets generate fragments, whereas servlets generate complete =
documents.
- Unlike servlets portlets are not bound directly to a URL.

According to my understanding there are few things that portlets have =
but
servlets don't

- Portlets are able to perform portlet rewriting, so as to create links =
that
are independent of the portal server implementation
- portlets has two different session scopes in which to store object:
application wide and portlet private. -Portlets has access to user =
profile
information that is definitely far beyond the basic user and role
information provided in the servlet specifications.

Similarly there are few things that servlets can do but portlets can =
not do
that. For example

-Portlets can not alter the HTTP headers or set response encoding. =
-Portlets
can not access the URL that the client used to initiate the request on =
the
portal.

Later.

Faizan


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet and JSFs

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

> Portlets can not access the URL that the client used to initiate the =
request on the portal.

While that makes sense, it effectively makes me wonder whether we need a =
Portlet dispatcher: With Servlets, dispatching is all about flexible URL =
mapping. AFAIK, Portlets have doView, doEdit etc callbacks, similar to =
doGet, doPost, etc from the Servlet API.

So for typical Portlets, it's probably most important to allow for easy =
access to Spring facilities from those methods, rather than dispatch to =
some other components from a Portlet doView method. Portlet support =
classes similar to the ones I just added for Struts come to my mind.

This doesn't seem to be much effort at all. Am I on the wrong track =
here?

Juergen


=20

________________________________

Von: spr...@li... im Auftrag =
von Faizan Hussain
Gesendet: Di 13.04.2004 20:38
An: spr...@li...
Betreff: RE: [Springframework-developer] Portlet and JSFs



Please see my comments at the bottom


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
William G. Thompson, Jr.
Sent: Friday, April 09, 2004 7:35 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs

Ben Alex wrote:
> Hi Bill
>
>
>>Rutgers is very interested in Spring support for the Portlet
>>API in the form of a PortletDispatcher as it were.  We run
>>the uPortal[1] platform and the latest release embeds Pluto.=20
>>We are just now embarking on dev cycle for new porlets that
>>takes us thru september, if possible these new portlets would
>>live behind a Spring PortletDispatcher.
>>
>>We have had some preliminary dicussions with Alef about what
>>it might look like, and should be in a better positition to
>>try out some ideas/code in a few weeks.
>
>
> I took a look at uPortal but wondered how hard it would be to get =
Spring
MVC
> capabilities living within a portlet window. Have you actually done
anything
> like this as yet, or are your Spring applications essentially
"traditional"
> (dedicated JSP/VM etc)?
>

So far all of our Spring apps are "traditional"; leveraging the full
compliment of the Spring stack (WebMVC, DAO, JDBC Abstraction,
ApplicationContext, declaritive transaction management, AOP, etc.) and
living in a dedicated Servlet context.

We have used Spring DAO/JDBC support for a few simple Channels
(Portlets), but that is the extent of it.

We are extremely pleased with the Spring development model and would
like to bring our portal project in line.

I don't think it should be too hard to bring SerlvetDispatcher behavior
to the Portlet API.  The big difference is that Portlets participated in
a two step call (ActionRequest/Response and RenderRequest/Response) and
also have additional lifecycle events, PortletMode (View, Edit,
Help,...) and WindowMode (min, max, normal, etc.) that impact behavior
of the service.

later.
Bill

Since we got into this discussion, I would like to add few more =
differences
between Portlets and Serverlets.
- Portlets generate fragments, whereas servlets generate complete =
documents.
- Unlike servlets portlets are not bound directly to a URL.

According to my understanding there are few things that portlets have =
but
servlets don't

- Portlets are able to perform portlet rewriting, so as to create links =
that
are independent of the portal server implementation
- portlets has two different session scopes in which to store object:
application wide and portlet private.
-Portlets has access to user profile information that is definitely far
beyond the basic user and role information provided in the servlet
specifications.

Similarly there are few things that servlets can do but portlets can not =
do
that. For example

-Portlets can not alter the HTTP headers or set response encoding.
-Portlets can not access the URL that the client used to initiate the
request on the portal.

Later.

Faizan


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

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

The site is unreachable...

-----Original Message-----
From: Nadeem Bitar [mailto:na...@ea...] 
Sent: Tuesday, April 13, 2004 1:46 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


On 火, 2004-04-13 at 11:13 -0400, William G. Thompson, Jr. wrote:

> jef...@si... wrote:
> >>Would anyone be willing and have time to collaborate on this?
> > 
> > 
> > yes. I start work next week for a new company where I'll be 
> > developing a portal product. I have experience with Spring & 
> > Hibernate but have only used Struts as the MVC. I am currently 
> > evaluating Jetspeed and uPortal. uPortal has a 168-portlet adaptor 
> > out now. Jetspeed-2 (based on Pluto) is not ready yet but they 
> > report good progress.
> > 

Have a look at http://www.gridsphere.org/gridsphere/gridsphere 

> > If a Spring PortletDispatcher supported JSR-168 then it seems like 
> > it would work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this 
> > right?
> 
> Exactly!
> 
>   What
> > release of Spring would the PortletDispatcher be in, 1.01 or 1.1?
> 
> I would push for as soon as it is fully baked...for the timing to work
> out right for us we'll need something workable in about a month...and 
> hopefully in an official Spring release by August.
> 
> later.
> Bill
> 
> 
> > 
> > Jeff W. Boring
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On 
> > Behalf Of Ben Alex
> > Sent: Friday, April 09, 2004 2:33 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> > 
> > 
> > Hi
> > 
> > 
> >>JSF and Portlet functionality don't have to be provided in
> >>one and the same release. I have been looking a bit into the 
> >>portlet stuff and it doesn't same all that difficult.
> >>
> >>I think I'll experiment with it during the next couple of
> >>weeks. Major issue is the common supporting functionality 
> >>(ContextLoader, WebAppCtx,
> >>Databinding) between our Web stuff and our future Portlet 
> >>stuff (and probably also the JSF stuff). Revising the 
> >>supporting functionality right now (or for 1.1) is not an option imo.
> >>
> >>I probably can't avoid having to copy-and-paste a lot of code
> >>while experimenting and since that's *not* something we want 
> >>to have in a release, I'm afraid you're right :(.
> > 
> > 
> > Several people have previously mentioned portlets and JSF. We are 
> > trying to decide whether to implement portlets in our next project, 
> > or just stick to include files and/or something like Sitemesh, Tiles 
> > etc.
> > 
> > Regarding portlets, there is the Pico-based Exo project
> > (http://exo.sourceforge.net/) and Pluto 
> > (http://jakarta.apache.org/pluto/).
> > Has anyone done any work on integrating portlets, JSF or projects such
as
> > these into Spring? Would anyone be willing and have time to collaborate
on
> > this?
> > 
> > Best regards
> > Ben
> > 
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of 
> GenToo technologies. Learn everything from fundamentals to system 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-- 
************************
Nadeem Bitar
Software Engineer
IzuCode, LLC
858-337-6159
5230 Fiore Terrace #k208
San Diego, Ca 92122
************************ 



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.0.1

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

OK, lets go for that then. Verbose is not a problem, as users won't norma=
lly
use (or bother looking at) that class.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, April 09, 2004 6:57 AM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, a=
s
it hits the nail: "prototype-based" is what it is. I've got a new favouri=
te
:-)

Juergen


________________________________

Von: spr...@li... im Auftrag von
Rod Johnson
Gesendet: Do 08.04.2004 20:21
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



AbstractDynamicTargetSource is OK by me, although I'm not in love with it.
Technically of course a dynamic target source need not use the bean facto=
ry
at all. But AbstractPrototypeBasedTargetSource is a bit wordy...

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, April 08, 2004 5:27 PM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


Final decision here? I still vote for "AbstractDynamicTargetSource"; at
least against "AbstractPrototypeTargetSource".

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Monday, April 05, 2004 9:51 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.1


Actually, I still prefer "AbstractDynamicTargetSource": Target beans bein=
g
defined as prototypes is a requirement for any meaningful dynamic target
source strategy (no matter if one-shot, ThreadLocal or pooled), therefore=
 I
consider it fine that AbstractDynamicTargetSource implicitly works with
prototype target beans. But just PrototypeTargetSource delivers actual
one-instance-per-method-invocation semantics, rather than pooling instanc=
es
or the like.

Juergen


________________________________

Von: spr...@li... im Auftrag von
j=FCrgen h=F6ller [werk3AT]
Gesendet: So 04.04.2004 16:25
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



That's what I meant with the different meaning of the term "prototype":
AbstractPrototypeTargetSource just assumes that the bean that it referenc=
es
is a prototype, allowing to expose targets with ThreadLocal or pooling
semantics. On the other hand, PrototypeTargetSource actually exposes a
"prototype" target, i.e. a new target object on each method invocation
(analogous to the term "prototype" used in bean definitions).

I agree that the term "prototype" isn't wrong in
AbstractPrototypeTargetSource, but it's used with somewhat different mean=
ing
than in PrototypeTargetSource. To avoid confusion for people that dig int=
o
Spring's javadoc or even implementation, we should use different terms he=
re,
i.e. use the term "prototype" for a more specific meaning (preferably the
one analogous to bean definitions).

I'm open for other suggestions, of course!

Juergen


________________________________

Von: spr...@li... im Auftrag von
Rod Johnson
Gesendet: So 04.04.2004 16:08
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I guess AbstractDynamicTargetSource is an improvement. I agree the naming
pattern isn't great, but the abstract base class _does_ work with prototy=
pe
definitions, so having Prototype in its name does make sense. It's not a
generic "Dynamic" TargetSource because it works with bean names and
getBeans() assuming a prototype.

Any other suggestions? If this is renamed, I'd rather that it was
undebatably right.

R


----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, April 03, 2004 6:46 PM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


A minor naming issue that I've noticed: We have an
AbstractPrototypeTargetSource, which serves as base class for
PrototypeTargetSource, ThreadLocalTargetSource and
AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming
pattern anywhere else in the framework. (I've actually removed a similar
naming pattern in the AbstractAutoProxyCreator area before 1.0 final.)

Furthermore, "AbstractPrototypeTargetSource" is actually a bit misleading=
,
as we're using a broader meaning of the word prototype here than found in
bean definitions. "PrototypeTargetSource" matches the bean definition ter=
m
exactly, but the base class is more generic: So what about renaming it to
"AbstractDynamicTargetSource" or the like, indicating that it serves as b=
ase
class for all non-singleton TargetSources?

Like the AopUtils move, this should be fine in terms of compatibility lev=
el,
as the base class is not part of the public API but rather an internal
implementation detail. PrototypeTargetSource and co will still be fully
backward compatible after that change, and I doubt that anyone has
implemented custom TargetSources yet (and even if, it's trivial to adapt).

Juergen


________________________________

Von: spr...@li... im Auftrag von
Rod Johnson
Gesendet: Fr 02.04.2004 16:53
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I suggest that we sit on this code for at least a week until we release i=
t,
so we can catch anything else. How about we target Monday week for releas=
e?

A 1.0.1 release should be driven by stability, not date, so we should see=
 if
any more issues come out of the woodwork.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, April 02, 2004 10:57 AM
Subject: [Springframework-developer] Preparing for 1.0.1


Hi everybody,

From my point of view, the code is ready for release 1.0.1. There were a
couple of bug fixes and minor enhancements since 1.0 final. The most
important fix is proper Hibernate/JTA resource management when flush fail=
s.
Enhancements include the introduction of the MessageCodesResolver interfa=
ce
in the validation package, and a more efficient internal implementation o=
f
AbstractMessageSource. See the changelog for details.

Please give the current CVS snapshot a try. There shouldn't be any issues=
,
as changes are minor and just affect specific functionality. I'd like to
target mid next week for the release, i.e. two weeks after 1.0 final. In =
the
meantime, the only thing I plan to address is the lack of remoting covera=
ge
in the reference docs. If anyone feels the need to improve other parts of
the docs, please do so till mid next week!

Juergen


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet and JSFs

[Nadeem B. <na...@ea...>]

On =B2=D0, 2004-04-13 at 11:13 -0400, William G. Thompson, Jr. wrote:

> jef...@si... wrote:
> >>Would anyone be willing and have time to collaborate on this?
> >=20
> >=20
> > yes. I start work next week for a new company where I'll be developing =
a
> > portal product. I have experience with Spring & Hibernate but have only=
 used
> > Struts as the MVC. I am currently evaluating Jetspeed and uPortal. uPor=
tal
> > has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is not r=
eady
> > yet but they report good progress.
> >=20

Have a look at http://www.gridsphere.org/gridsphere/gridsphere=20

> > If a Spring PortletDispatcher supported JSR-168 then it seems like it w=
ould
> > work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?
>=20
> Exactly!
>=20
>   What
> > release of Spring would the PortletDispatcher be in, 1.01 or 1.1?
>=20
> I would push for as soon as it is fully baked...for the timing to work=20
> out right for us we'll need something workable in about a month...and=20
> hopefully in an official Spring release by August.
>=20
> later.
> Bill
>=20
>=20
> >=20
> > Jeff W. Boring=20
> >=20
> >=20
> >=20
> >=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On Behalf
> > Of Ben Alex
> > Sent: Friday, April 09, 2004 2:33 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >=20
> >=20
> > Hi
> >=20
> >=20
> >>JSF and Portlet functionality don't have to be provided in=20
> >>one and the same release. I have been looking a bit into the=20
> >>portlet stuff and it doesn't same all that difficult.
> >>
> >>I think I'll experiment with it during the next couple of=20
> >>weeks. Major issue is the common supporting functionality=20
> >>(ContextLoader, WebAppCtx,
> >>Databinding) between our Web stuff and our future Portlet=20
> >>stuff (and probably also the JSF stuff). Revising the=20
> >>supporting functionality right now (or for 1.1) is not an option imo.
> >>
> >>I probably can't avoid having to copy-and-paste a lot of code=20
> >>while experimenting and since that's *not* something we want=20
> >>to have in a release, I'm afraid you're right :(.
> >=20
> >=20
> > Several people have previously mentioned portlets and JSF. We are tryin=
g to
> > decide whether to implement portlets in our next project, or just stick=
 to
> > include files and/or something like Sitemesh, Tiles etc.
> >=20
> > Regarding portlets, there is the Pico-based Exo project
> > (http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/plut=
o/).
> > Has anyone done any work on integrating portlets, JSF or projects such =
as
> > these into Spring? Would anyone be willing and have time to collaborate=
 on
> > this?
> >=20
> > Best regards
> > Ben
> >=20
> >=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
--=20
************************
Nadeem Bitar
Software Engineer
IzuCode, LLC
858-337-6159
5230 Fiore Terrace #k208
San Diego, Ca 92122
************************=20

RE: [Springframework-developer] Portlet and JSFs

[Faizan H. <fa...@ru...>]

+11 for portlets (since me and Dmitriy work together and one one makes =
us
eleven this is called synergy ;-))

Faizan=20


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Dmitriy Kopylenko
Sent: Tuesday, April 13, 2004 1:12 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs

+1 Portlet! Portlet! Portlet! ;-))

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
jef...@si...
Sent: Tuesday, April 13, 2004 12:11 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs


> we'll need something workable in about a month <

Us too!=20

Jeff W. Boring=20




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
William G. Thompson, Jr.
Sent: Tuesday, April 13, 2004 11:13 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


jef...@si... wrote:
>>Would anyone be willing and have time to collaborate on this?
>=20
>=20
> yes. I start work next week for a new company where I'll be developing =

> a portal product. I have experience with Spring & Hibernate but have=20
> only
used
> Struts as the MVC. I am currently evaluating Jetspeed and uPortal.=20
> uPortal has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) =

> is not
ready
> yet but they report good progress.
>=20
> If a Spring PortletDispatcher supported JSR-168 then it seems like it
would
> work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?

Exactly!

  What
> release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

I would push for as soon as it is fully baked...for the timing to work=20
out right for us we'll need something workable in about a month...and=20
hopefully in an official Spring release by August.

later.
Bill


>=20
> Jeff W. Boring
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On=20
> Behalf Of Ben Alex
> Sent: Friday, April 09, 2004 2:33 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
>=20
>=20
> Hi
>=20
>=20
>>JSF and Portlet functionality don't have to be provided in
>>one and the same release. I have been looking a bit into the=20
>>portlet stuff and it doesn't same all that difficult.
>>
>>I think I'll experiment with it during the next couple of
>>weeks. Major issue is the common supporting functionality=20
>>(ContextLoader, WebAppCtx,
>>Databinding) between our Web stuff and our future Portlet=20
>>stuff (and probably also the JSF stuff). Revising the=20
>>supporting functionality right now (or for 1.1) is not an option imo.
>>
>>I probably can't avoid having to copy-and-paste a lot of code
>>while experimenting and since that's *not* something we want=20
>>to have in a release, I'm afraid you're right :(.
>=20
>=20
> Several people have previously mentioned portlets and JSF. We are=20
> trying
to
> decide whether to implement portlets in our next project, or just=20
> stick to include files and/or something like Sitemesh, Tiles etc.
>=20
> Regarding portlets, there is the Pico-based Exo project
> (http://exo.sourceforge.net/) and Pluto
(http://jakarta.apache.org/pluto/).
> Has anyone done any work on integrating portlets, JSF or projects such =

> as these into Spring? Would anyone be willing and have time to=20
> collaborate on this?
>=20
> Best regards
> Ben
>=20
>=20



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

[Faizan H. <fa...@ru...>]

Please see my comments at the bottom


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
William G. Thompson, Jr.
Sent: Friday, April 09, 2004 7:35 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs

Ben Alex wrote:
> Hi Bill
>=20
>=20
>>Rutgers is very interested in Spring support for the Portlet=20
>>API in the form of a PortletDispatcher as it were.  We run=20
>>the uPortal[1] platform and the latest release embeds Pluto. =20
>>We are just now embarking on dev cycle for new porlets that=20
>>takes us thru september, if possible these new portlets would=20
>>live behind a Spring PortletDispatcher.
>>
>>We have had some preliminary dicussions with Alef about what=20
>>it might look like, and should be in a better positition to=20
>>try out some ideas/code in a few weeks.
>=20
>=20
> I took a look at uPortal but wondered how hard it would be to get =
Spring
MVC
> capabilities living within a portlet window. Have you actually done
anything
> like this as yet, or are your Spring applications essentially
"traditional"
> (dedicated JSP/VM etc)?
>=20

So far all of our Spring apps are "traditional"; leveraging the full=20
compliment of the Spring stack (WebMVC, DAO, JDBC Abstraction,=20
ApplicationContext, declaritive transaction management, AOP, etc.) and=20
living in a dedicated Servlet context.

We have used Spring DAO/JDBC support for a few simple Channels=20
(Portlets), but that is the extent of it.

We are extremely pleased with the Spring development model and would=20
like to bring our portal project in line.

I don't think it should be too hard to bring SerlvetDispatcher behavior=20
to the Portlet API.  The big difference is that Portlets participated in =

a two step call (ActionRequest/Response and RenderRequest/Response) and=20
also have additional lifecycle events, PortletMode (View, Edit,=20
Help,...) and WindowMode (min, max, normal, etc.) that impact behavior=20
of the service.

later.
Bill

Since we got into this discussion, I would like to add few more =
differences
between Portlets and Serverlets.
- Portlets generate fragments, whereas servlets generate complete =
documents.
- Unlike servlets portlets are not bound directly to a URL.

According to my understanding there are few things that portlets have =
but
servlets don't

- Portlets are able to perform portlet rewriting, so as to create links =
that
are independent of the portal server implementation
- portlets has two different session scopes in which to store object:
application wide and portlet private.
-Portlets has access to user profile information that is definitely far
beyond the basic user and role information provided in the servlet
specifications.

Similarly there are few things that servlets can do but portlets can not =
do
that. For example

-Portlets can not alter the HTTP headers or set response encoding.
-Portlets can not access the URL that the client used to initiate the
request on the portal.

Later.

Faizan


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

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

+1 Portlet! Portlet! Portlet! ;-))

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
jef...@si...
Sent: Tuesday, April 13, 2004 12:11 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs


> we'll need something workable in about a month <

Us too!=20

Jeff W. Boring=20




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
William G. Thompson, Jr.
Sent: Tuesday, April 13, 2004 11:13 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


jef...@si... wrote:
>>Would anyone be willing and have time to collaborate on this?
>=20
>=20
> yes. I start work next week for a new company where I'll be developing =

> a portal product. I have experience with Spring & Hibernate but have=20
> only
used
> Struts as the MVC. I am currently evaluating Jetspeed and uPortal.=20
> uPortal has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) =

> is not
ready
> yet but they report good progress.
>=20
> If a Spring PortletDispatcher supported JSR-168 then it seems like it
would
> work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?

Exactly!

  What
> release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

I would push for as soon as it is fully baked...for the timing to work=20
out right for us we'll need something workable in about a month...and=20
hopefully in an official Spring release by August.

later.
Bill


>=20
> Jeff W. Boring
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On=20
> Behalf Of Ben Alex
> Sent: Friday, April 09, 2004 2:33 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
>=20
>=20
> Hi
>=20
>=20
>>JSF and Portlet functionality don't have to be provided in
>>one and the same release. I have been looking a bit into the=20
>>portlet stuff and it doesn't same all that difficult.
>>
>>I think I'll experiment with it during the next couple of
>>weeks. Major issue is the common supporting functionality=20
>>(ContextLoader, WebAppCtx,
>>Databinding) between our Web stuff and our future Portlet=20
>>stuff (and probably also the JSF stuff). Revising the=20
>>supporting functionality right now (or for 1.1) is not an option imo.
>>
>>I probably can't avoid having to copy-and-paste a lot of code
>>while experimenting and since that's *not* something we want=20
>>to have in a release, I'm afraid you're right :(.
>=20
>=20
> Several people have previously mentioned portlets and JSF. We are=20
> trying
to
> decide whether to implement portlets in our next project, or just=20
> stick to include files and/or something like Sitemesh, Tiles etc.
>=20
> Regarding portlets, there is the Pico-based Exo project
> (http://exo.sourceforge.net/) and Pluto
(http://jakarta.apache.org/pluto/).
> Has anyone done any work on integrating portlets, JSF or projects such =

> as these into Spring? Would anyone be willing and have time to=20
> collaborate on this?
>=20
> Best regards
> Ben
>=20
>=20



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

[<jef...@si...>]

> we'll need something workable in about a month <

Us too! 

Jeff W. Boring 




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of William G. Thompson, Jr.
Sent: Tuesday, April 13, 2004 11:13 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


jef...@si... wrote:
>>Would anyone be willing and have time to collaborate on this?
> 
> 
> yes. I start work next week for a new company where I'll be developing a
> portal product. I have experience with Spring & Hibernate but have only
used
> Struts as the MVC. I am currently evaluating Jetspeed and uPortal. uPortal
> has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is not
ready
> yet but they report good progress.
> 
> If a Spring PortletDispatcher supported JSR-168 then it seems like it
would
> work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?

Exactly!

  What
> release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

I would push for as soon as it is fully baked...for the timing to work 
out right for us we'll need something workable in about a month...and 
hopefully in an official Spring release by August.

later.
Bill


> 
> Jeff W. Boring 
> 
> 
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Ben Alex
> Sent: Friday, April 09, 2004 2:33 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
> 
> 
> Hi
> 
> 
>>JSF and Portlet functionality don't have to be provided in 
>>one and the same release. I have been looking a bit into the 
>>portlet stuff and it doesn't same all that difficult.
>>
>>I think I'll experiment with it during the next couple of 
>>weeks. Major issue is the common supporting functionality 
>>(ContextLoader, WebAppCtx,
>>Databinding) between our Web stuff and our future Portlet 
>>stuff (and probably also the JSF stuff). Revising the 
>>supporting functionality right now (or for 1.1) is not an option imo.
>>
>>I probably can't avoid having to copy-and-paste a lot of code 
>>while experimenting and since that's *not* something we want 
>>to have in a release, I'm afraid you're right :(.
> 
> 
> Several people have previously mentioned portlets and JSF. We are trying
to
> decide whether to implement portlets in our next project, or just stick to
> include files and/or something like Sitemesh, Tiles etc.
> 
> Regarding portlets, there is the Pico-based Exo project
> (http://exo.sourceforge.net/) and Pluto
(http://jakarta.apache.org/pluto/).
> Has anyone done any work on integrating portlets, JSF or projects such as
> these into Spring? Would anyone be willing and have time to collaborate on
> this?
> 
> Best regards
> Ben
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Struts Spring Plugin

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

I just checked the Struts 1.1 RequestProcessor implementation: You're =
right, it's one instance per Action type, not one instance per mapping. =
Thus, I've just removed the delegateAction instance variable; our only =
choice is to freshly fetch the Spring-managed Action bean on each =
execution. It's not much slower anyway, according to my ad-hoc =
benchmark.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dirk Markert
Sent: Tuesday, April 13, 2004 1:12 PM
To: j=FCrgen h=F6ller [werk3AT]
Subject: Re[2]: [Springframework-developer] Struts Spring Plugin


Hello J=FCrgen,

I think there is a problem with your implementation. Struts will
create only _one_ instance for the same Action class in a module.
Thus, if you have to mappings with the same action class they will
point to the same spring bean.

Tuesday, April 13, 2004, 12:31:15 PM, you wrote:

jhw> Of course, you're right that the synchronized block should
jhw> include the return statement - thanks for spotting this. The
jhw> synchronization there isn't terribly important though, as it's
jhw> just about unnecessarily re-fetching the bean from the
jhw> application context.

jhw> The only reason for the delegateAction member attribute is
jhw> speed: to avoid repeated lookups of the Action bean in the Spring
jhw> application context. It might be worth benchmarking whether the
jhw> synchronized block isn't the bigger performance threat here,
jhw> though, as the context.getBean call boils down to a HashMap
jhw> lookup.

jhw> It's a pity that Struts doesn't pass in the ActionMapping
jhw> in some Action initialization callback. As far as I can tell, the
jhw> mapping is determined at Action initialization time, so this
jhw> would have been feasible. If we had such a callback, we could
jhw> simply fetch the delegate Action at initialization time,
jhw> completely avoiding the need for synchronization.

jhw> Juergen


jhw> -----Original Message-----
jhw> From: spr...@li...
jhw> [mailto:spr...@li...]On =
Behalf
jhw> Of Dirk Markert
jhw> Sent: Tuesday, April 13, 2004 10:54 AM
jhw> To: j=FCrgen h=F6ller [werk3AT]
jhw> Subject: Re[2]: [Springframework-developer] Struts Spring Plugin


jhw> Hello J=FCrgen,

jhw> I just had a look at the implementation of DelegatingActionProxy. I
jhw> wonder why you are using a membar attribute delegateAction. The =
class has to
jhw> be thread safe, and I thing using this attribute it isn't. In =
getDelegateAction
jhw> your synchronized access does not include the return statement.

jhw> Do I miss something?


jhw> Best regards,
jhw> Dirk



jhw> -------------------------------------------------------
jhw> This SF.Net email is sponsored by: IBM Linux Tutorials
jhw> Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
jhw> GenToo technologies. Learn everything from fundamentals to system
jhw> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
jhw> _______________________________________________
jhw> Springframework-developer mailing list
jhw> Spr...@li...
jhw> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer


jhw> -------------------------------------------------------
jhw> This SF.Net email is sponsored by: IBM Linux Tutorials
jhw> Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
jhw> GenToo technologies. Learn everything from fundamentals to system
jhw> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&oplick
jhw> _______________________________________________
jhw> Springframework-developer mailing list
jhw> Spr...@li...
jhw> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer



--=20
Best regards,
Dirk
N=18=ACHS^=B5=E9sSX=AC=B2s'=B2S=DEu=BC^=04=C2=E2z=ECS=BA=DA+?=A9l=16=B7z.=
)=EE=C6=DB=AD=A2=B8s-s=DE=B1=E9=EDy=D6=F2
=A9=E2zThm=B8=A7=B0=FA=DE=B2'^z=D6=A7t!=0E=A1=F1z=9D:(=B5=E7!z?h''=AC-=E6=
=AB=9D=EB=DE=AF+aSx=1F=AE?Y=BAwZ(tm)=E9=EDj[-=A2=CC=AC=B5=E9svh=A7S=CBkj=D8=
=A8z=1Bm=A7=FF=DAv=CA,vw(>=F6=9D?=D0=E3=BD-Z?=EB

Re: [Springframework-developer] Portlet and JSFs

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

jef...@si... wrote:
>>Would anyone be willing and have time to collaborate on this?
> 
> 
> yes. I start work next week for a new company where I'll be developing a
> portal product. I have experience with Spring & Hibernate but have only used
> Struts as the MVC. I am currently evaluating Jetspeed and uPortal. uPortal
> has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is not ready
> yet but they report good progress.
> 
> If a Spring PortletDispatcher supported JSR-168 then it seems like it would
> work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?

Exactly!

  What
> release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

I would push for as soon as it is fully baked...for the timing to work 
out right for us we'll need something workable in about a month...and 
hopefully in an official Spring release by August.

later.
Bill


> 
> Jeff W. Boring 
> 
> 
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Ben Alex
> Sent: Friday, April 09, 2004 2:33 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
> 
> 
> Hi
> 
> 
>>JSF and Portlet functionality don't have to be provided in 
>>one and the same release. I have been looking a bit into the 
>>portlet stuff and it doesn't same all that difficult.
>>
>>I think I'll experiment with it during the next couple of 
>>weeks. Major issue is the common supporting functionality 
>>(ContextLoader, WebAppCtx,
>>Databinding) between our Web stuff and our future Portlet 
>>stuff (and probably also the JSF stuff). Revising the 
>>supporting functionality right now (or for 1.1) is not an option imo.
>>
>>I probably can't avoid having to copy-and-paste a lot of code 
>>while experimenting and since that's *not* something we want 
>>to have in a release, I'm afraid you're right :(.
> 
> 
> Several people have previously mentioned portlets and JSF. We are trying to
> decide whether to implement portlets in our next project, or just stick to
> include files and/or something like Sitemesh, Tiles etc.
> 
> Regarding portlets, there is the Pico-based Exo project
> (http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/pluto/).
> Has anyone done any work on integrating portlets, JSF or projects such as
> these into Spring? Would anyone be willing and have time to collaborate on
> this?
> 
> Best regards
> Ben
> 
> 

RE: [Springframework-developer] Portlet and JSFs

[<jef...@si...>]

>Would anyone be willing and have time to collaborate on this? <

yes. I start work next week for a new company where I'll be developing a
portal product. I have experience with Spring & Hibernate but have only used
Struts as the MVC. I am currently evaluating Jetspeed and uPortal. uPortal
has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is not ready
yet but they report good progress.

If a Spring PortletDispatcher supported JSR-168 then it seems like it would
work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right? What
release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

Jeff W. Boring 




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ben Alex
Sent: Friday, April 09, 2004 2:33 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs


Hi

> JSF and Portlet functionality don't have to be provided in 
> one and the same release. I have been looking a bit into the 
> portlet stuff and it doesn't same all that difficult.
> 
> I think I'll experiment with it during the next couple of 
> weeks. Major issue is the common supporting functionality 
> (ContextLoader, WebAppCtx,
> Databinding) between our Web stuff and our future Portlet 
> stuff (and probably also the JSF stuff). Revising the 
> supporting functionality right now (or for 1.1) is not an option imo.
> 
> I probably can't avoid having to copy-and-paste a lot of code 
> while experimenting and since that's *not* something we want 
> to have in a release, I'm afraid you're right :(.

Several people have previously mentioned portlets and JSF. We are trying to
decide whether to implement portlets in our next project, or just stick to
include files and/or something like Sitemesh, Tiles etc.

Regarding portlets, there is the Pico-based Exo project
(http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/pluto/).
Has anyone done any work on integrating portlets, JSF or projects such as
these into Spring? Would anyone be willing and have time to collaborate on
this?

Best regards
Ben



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Preparing for 1.0.1

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

The CVS version is in production. No issues reported so far...

Regards,
Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]=20
Sent: Tuesday, April 13, 2004 9:46 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.1


I've been using the CVS version without issues; actually it's even in=20
production...    I have on my todo list to create a test case for=20
testing the new Hibernate JTA stuff with CMT; I've been busy, but will=20
make sure this is done by the weekend...

Regards,
Colin


j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>=20
>As we're about to release Spring 1.0.1 by the beginning of next week,=20
>we need to re-test the current CVS contents thoroughly. The most =
important
area is Hibernate/JTA integration: Flushing failures should now be =
handled
properly; and ThreadLocal Sessions should work without =
JtaTransactionManager
too, as long as there's a Hibernate TransactionManagerLookup =
configured.
>=20
>As a side note: Hibernate's TransactionManagerLookup can be configured =

>via Spring too, passing a javax.transaction.TransactionManager into
LocalSessionFactoryBean's "jtaTransactionManager" property. Normally, =
this
will be a JndiObjectFactoryBean reference, possibly shared with
JtaTransactionManager (i.e. passed into the latter's =
"transactionManager"
property too).
>=20
>If anyone finds some further areas in the documentation that need=20
>completion or polishing, please address them this week rather than =
next one
:-)
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag=20
>von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Fr 09.04.2004 07:57
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like =
it,=20
>as it hits the nail: "prototype-based" is what it is. I've got a new=20
>favourite :-)
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag=20
>von Rod Johnson
>Gesendet: Do 08.04.2004 20:21
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>AbstractDynamicTargetSource is OK by me, although I'm not in love with =

>it. Technically of course a dynamic target source need not use the =
bean=20
>factory at all. But AbstractPrototypeBasedTargetSource is a bit=20
>wordy...
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Thursday, April 08, 2004 5:27 PM
>Subject: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>Final decision here? I still vote for "AbstractDynamicTargetSource"; =
at=20
>least against "AbstractPrototypeTargetSource".
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On =
Behalf=20
>Of j=FCrgen h=F6ller [werk3AT]
>Sent: Monday, April 05, 2004 9:51 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>Actually, I still prefer "AbstractDynamicTargetSource": Target beans=20
>being defined as prototypes is a requirement for any meaningful =
dynamic=20
>target source strategy (no matter if one-shot, ThreadLocal or pooled), =

>therefore I consider it fine that AbstractDynamicTargetSource=20
>implicitly works with prototype target beans. But just=20
>PrototypeTargetSource delivers actual=20
>one-instance-per-method-invocation semantics, rather than pooling=20
>instances or the like.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag=20
>von j=FCrgen h=F6ller [werk3AT]
>Gesendet: So 04.04.2004 16:25
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>That's what I meant with the different meaning of the term =
"prototype":=20
>AbstractPrototypeTargetSource just assumes that the bean that it=20
>references is a prototype, allowing to expose targets with ThreadLocal =

>or pooling semantics. On the other hand, PrototypeTargetSource =
actually=20
>exposes a "prototype" target, i.e. a new target object on each method=20
>invocation (analogous to the term "prototype" used in bean=20
>definitions).
>
>I agree that the term "prototype" isn't wrong in=20
>AbstractPrototypeTargetSource, but it's used with somewhat different=20
>meaning than in PrototypeTargetSource. To avoid confusion for people=20
>that dig into Spring's javadoc or even implementation, we should use=20
>different terms here, i.e. use the term "prototype" for a more =
specific=20
>meaning (preferably the one analogous to bean definitions).
>
>I'm open for other suggestions, of course!
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag=20
>von Rod Johnson
>Gesendet: So 04.04.2004 16:08
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>I guess AbstractDynamicTargetSource is an improvement. I agree the=20
>naming pattern isn't great, but the abstract base class _does_ work=20
>with prototype definitions, so having Prototype in its name does make=20
>sense. It's not a generic "Dynamic" TargetSource because it works with =

>bean names and
>getBeans() assuming a prototype.
>
>Any other suggestions? If this is renamed, I'd rather that it was=20
>undebatably right.
>
>R
>
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Saturday, April 03, 2004 6:46 PM
>Subject: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>A minor naming issue that I've noticed: We have an=20
>AbstractPrototypeTargetSource, which serves as base class for=20
>PrototypeTargetSource, ThreadLocalTargetSource and=20
>AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming=20
>pattern anywhere else in the framework. (I've actually removed a=20
>similar naming pattern in the AbstractAutoProxyCreator area before 1.0 =

>final.)
>
>Furthermore, "AbstractPrototypeTargetSource" is actually a bit=20
>misleading, as we're using a broader meaning of the word prototype =
here=20
>than found in bean definitions. "PrototypeTargetSource" matches the=20
>bean definition term exactly, but the base class is more generic: So=20
>what about renaming it to "AbstractDynamicTargetSource" or the like,=20
>indicating that it serves as base class for all non-singleton=20
>TargetSources?
>
>Like the AopUtils move, this should be fine in terms of compatibility=20
>level, as the base class is not part of the public API but rather an=20
>internal implementation detail. PrototypeTargetSource and co will =
still=20
>be fully backward compatible after that change, and I doubt that =
anyone=20
>has implemented custom TargetSources yet (and even if, it's trivial to =

>adapt).
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag=20
>von Rod Johnson
>Gesendet: Fr 02.04.2004 16:53
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>I suggest that we sit on this code for at least a week until we =
release=20
>it, so we can catch anything else. How about we target Monday week for =

>release?
>
>A 1.0.1 release should be driven by stability, not date, so we should=20
>see if any more issues come out of the woodwork.
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Friday, April 02, 2004 10:57 AM
>Subject: [Springframework-developer] Preparing for 1.0.1
>
>
>Hi everybody,
>
>From my point of view, the code is ready for release 1.0.1. There were =

>a couple of bug fixes and minor enhancements since 1.0 final. The most =

>important fix is proper Hibernate/JTA resource management when flush=20
>fails. Enhancements include the introduction of the=20
>MessageCodesResolver interface in the validation package, and a more=20
>efficient internal implementation of AbstractMessageSource. See the=20
>changelog for details.
>
>Please give the current CVS snapshot a try. There shouldn't be any=20
>issues, as changes are minor and just affect specific functionality.=20
>I'd like to target mid next week for the release, i.e. two weeks after =

>1.0 final. In the meantime, the only thing I plan to address is the=20
>lack of remoting coverage in the reference docs. If anyone feels the=20
>need to improve other parts of the docs, please do so till mid next=20
>week!
>
>Juergen
> =20
>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.0.1

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

I've been using the CVS version without issues; actually it's even in=20
production...    I have on my todo list to create a test case for=20
testing the new Hibernate JTA stuff with CMT; I've been busy, but will=20
make sure this is done by the weekend...

Regards,
Colin


j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>=20
>As we're about to release Spring 1.0.1 by the beginning of next week, we=
 need to re-test the current CVS contents thoroughly. The most important =
area is Hibernate/JTA integration: Flushing failures should now be handle=
d properly; and ThreadLocal Sessions should work without JtaTransactionMa=
nager too, as long as there's a Hibernate TransactionManagerLookup config=
ured.=20
>=20
>As a side note: Hibernate's TransactionManagerLookup can be configured v=
ia Spring too, passing a javax.transaction.TransactionManager into LocalS=
essionFactoryBean's "jtaTransactionManager" property. Normally, this will=
 be a JndiObjectFactoryBean reference, possibly shared with JtaTransactio=
nManager (i.e. passed into the latter's "transactionManager" property too=
).
>=20
>If anyone finds some further areas in the documentation that need comple=
tion or polishing, please address them this week rather than next one :-)
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n j=FCrgen h=F6ller [werk3AT]
>Gesendet: Fr 09.04.2004 07:57
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, =
as it hits the nail: "prototype-based" is what it is. I've got a new favo=
urite :-)
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n Rod Johnson
>Gesendet: Do 08.04.2004 20:21
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>AbstractDynamicTargetSource is OK by me, although I'm not in love with i=
t.
>Technically of course a dynamic target source need not use the bean fact=
ory
>at all. But AbstractPrototypeBasedTargetSource is a bit wordy...
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Thursday, April 08, 2004 5:27 PM
>Subject: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>Final decision here? I still vote for "AbstractDynamicTargetSource"; at
>least against "AbstractPrototypeTargetSource".
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of j=FCrgen h=F6ller [werk3AT]
>Sent: Monday, April 05, 2004 9:51 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>Actually, I still prefer "AbstractDynamicTargetSource": Target beans bei=
ng
>defined as prototypes is a requirement for any meaningful dynamic target
>source strategy (no matter if one-shot, ThreadLocal or pooled), therefor=
e I
>consider it fine that AbstractDynamicTargetSource implicitly works with
>prototype target beans. But just PrototypeTargetSource delivers actual
>one-instance-per-method-invocation semantics, rather than pooling instan=
ces
>or the like.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n
>j=FCrgen h=F6ller [werk3AT]
>Gesendet: So 04.04.2004 16:25
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>That's what I meant with the different meaning of the term "prototype":
>AbstractPrototypeTargetSource just assumes that the bean that it referen=
ces
>is a prototype, allowing to expose targets with ThreadLocal or pooling
>semantics. On the other hand, PrototypeTargetSource actually exposes a
>"prototype" target, i.e. a new target object on each method invocation
>(analogous to the term "prototype" used in bean definitions).
>
>I agree that the term "prototype" isn't wrong in
>AbstractPrototypeTargetSource, but it's used with somewhat different mea=
ning
>than in PrototypeTargetSource. To avoid confusion for people that dig in=
to
>Spring's javadoc or even implementation, we should use different terms h=
ere,
>i.e. use the term "prototype" for a more specific meaning (preferably th=
e
>one analogous to bean definitions).
>
>I'm open for other suggestions, of course!
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n
>Rod Johnson
>Gesendet: So 04.04.2004 16:08
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>I guess AbstractDynamicTargetSource is an improvement. I agree the namin=
g
>pattern isn't great, but the abstract base class _does_ work with protot=
ype
>definitions, so having Prototype in its name does make sense. It's not a
>generic "Dynamic" TargetSource because it works with bean names and
>getBeans() assuming a prototype.
>
>Any other suggestions? If this is renamed, I'd rather that it was
>undebatably right.
>
>R
>
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Saturday, April 03, 2004 6:46 PM
>Subject: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>A minor naming issue that I've noticed: We have an
>AbstractPrototypeTargetSource, which serves as base class for
>PrototypeTargetSource, ThreadLocalTargetSource and
>AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming
>pattern anywhere else in the framework. (I've actually removed a similar
>naming pattern in the AbstractAutoProxyCreator area before 1.0 final.)
>
>Furthermore, "AbstractPrototypeTargetSource" is actually a bit misleadin=
g,
>as we're using a broader meaning of the word prototype here than found i=
n
>bean definitions. "PrototypeTargetSource" matches the bean definition te=
rm
>exactly, but the base class is more generic: So what about renaming it t=
o
>"AbstractDynamicTargetSource" or the like, indicating that it serves as =
base
>class for all non-singleton TargetSources?
>
>Like the AopUtils move, this should be fine in terms of compatibility le=
vel,
>as the base class is not part of the public API but rather an internal
>implementation detail. PrototypeTargetSource and co will still be fully
>backward compatible after that change, and I doubt that anyone has
>implemented custom TargetSources yet (and even if, it's trivial to adapt=
).
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n
>Rod Johnson
>Gesendet: Fr 02.04.2004 16:53
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>I suggest that we sit on this code for at least a week until we release =
it,
>so we can catch anything else. How about we target Monday week for relea=
se?
>
>A 1.0.1 release should be driven by stability, not date, so we should se=
e if
>any more issues come out of the woodwork.
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Friday, April 02, 2004 10:57 AM
>Subject: [Springframework-developer] Preparing for 1.0.1
>
>
>Hi everybody,
>
>From my point of view, the code is ready for release 1.0.1. There were a
>couple of bug fixes and minor enhancements since 1.0 final. The most
>important fix is proper Hibernate/JTA resource management when flush fai=
ls.
>Enhancements include the introduction of the MessageCodesResolver interf=
ace
>in the validation package, and a more efficient internal implementation =
of
>AbstractMessageSource. See the changelog for details.
>
>Please give the current CVS snapshot a try. There shouldn't be any issue=
s,
>as changes are minor and just affect specific functionality. I'd like to
>target mid next week for the release, i.e. two weeks after 1.0 final. In=
 the
>meantime, the only thing I plan to address is the lack of remoting cover=
age
>in the reference docs. If anyone feels the need to improve other parts o=
f
>the docs, please do so till mid next week!
>
>Juergen
> =20
>

Re: [Springframework-developer] Preparing for 1.0.1

[Thomas R. <tho...@tr...>]

I have added support for translating the SQL state code returned by 
PostgreSQL 7.4.  I added a property 'useSqlStateForTranslation' to 
SqlErrorCodes and the test for this is 
SqlErrorCodeSQLExceptionTranslator.  This is kind of a hack, but it will 
work until Postgres supplies error codes some day in the future (maybe).

Thomas


jürgen höller [werk3AT] wrote:

>Rod,
>
>A code freeze should be feasible from my point of view. As I'm heading to Prague for a 4-day break tomorrow, I certainly won't do any further code changes - just the actual release on Sunday :-)
>
>
>Besides various stability and performance improvements, there are a couple of noteworthy enhancements respectively new features for 1.0.1:
>
>- BeanWrapperImpl allows for registration of custom editors for array/List/Map properties and specific elements of array/List/Map properties
>
>- AbstractXmlApplicationContext (and thus its subclasses like XmlWebApplicationContext) supports file patterns as config location, for example "/WEB-INF/*-context.xml"
>
>- validation framework delegates to a MessageCodesResolver strategy for building error codes for ObjectErrors and FieldErrors, with a more sophisticated default implementation
>
>- transaction-scoped Hibernate Sessions are provided even for plain JTA respectively EJB CMT transactions, without JtaTransactionManager being involved (mainly intended for implementing EJBs)
>
>- sophisticated Struts integration, with support classes for accessing a Spring context, a ContextLoaderPlugIn, and a way to wire Struts Actions as Spring-managed beans
>
>
>I'm not sure if we'll already be able to concentrate on 1.1 next. Neither JMS support nor JMX support nor declarative validation has reached milestone shape yet.
>
>I guess it's pretty safe to assume that 1.1 RC1 is still several months away. I'm almost certain that we'll find enough minor issues to warrant a 1.0.2 release in the meantime.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of rod...@in...
>Sent: Tuesday, April 13, 2004 10:26 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>  
>
>>As we're about to release Spring 1.0.1 by the beginning of 
>>    
>>
>next week, we need to re-test the current CVS contents 
>thoroughly. 
>Yes. I'd like to see a code freeze on the /src tree before 
>the release--say tomorrow?--except for any bug fixes. 
>Juergen, is this feasible?
>
>Stability is paramount with 1.0.1. We have some worthwhile 
>new features, like sophisticated Struts integration, that we 
>should definitely include, but we need to try to bed down 1.0 
>with this release so we can focus on 1.1.
>
>Regards,
>Rod
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

Re[2]: [Springframework-developer] Struts Spring Plugin

[Dirk M. <pos...@gm...>]

SGVsbG8gSvxyZ2VuLA0KDQpJIHRoaW5rIHRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIHlvdXIg
aW1wbGVtZW50YXRpb24uIFN0cnV0cyB3aWxsDQpjcmVhdGUgb25seSBfb25lXyBpbnN0YW5j
ZSBmb3IgdGhlIHNhbWUgQWN0aW9uIGNsYXNzIGluIGEgbW9kdWxlLg0KVGh1cywgaWYgeW91
IGhhdmUgdG8gbWFwcGluZ3Mgd2l0aCB0aGUgc2FtZSBhY3Rpb24gY2xhc3MgdGhleSB3aWxs
DQpwb2ludCB0byB0aGUgc2FtZSBzcHJpbmcgYmVhbi4NCg0KVHVlc2RheSwgQXByaWwgMTMs
IDIwMDQsIDEyOjMxOjE1IFBNLCB5b3Ugd3JvdGU6DQoNCmpodz4gT2YgY291cnNlLCB5b3Un
cmUgcmlnaHQgdGhhdCB0aGUgc3luY2hyb25pemVkIGJsb2NrIHNob3VsZA0Kamh3PiBpbmNs
dWRlIHRoZSByZXR1cm4gc3RhdGVtZW50IC0gdGhhbmtzIGZvciBzcG90dGluZyB0aGlzLiBU
aGUNCmpodz4gc3luY2hyb25pemF0aW9uIHRoZXJlIGlzbid0IHRlcnJpYmx5IGltcG9ydGFu
dCB0aG91Z2gsIGFzIGl0J3MNCmpodz4ganVzdCBhYm91dCB1bm5lY2Vzc2FyaWx5IHJlLWZl
dGNoaW5nIHRoZSBiZWFuIGZyb20gdGhlDQpqaHc+IGFwcGxpY2F0aW9uIGNvbnRleHQuDQoN
Cmpodz4gVGhlIG9ubHkgcmVhc29uIGZvciB0aGUgZGVsZWdhdGVBY3Rpb24gbWVtYmVyIGF0
dHJpYnV0ZSBpcw0Kamh3PiBzcGVlZDogdG8gYXZvaWQgcmVwZWF0ZWQgbG9va3VwcyBvZiB0
aGUgQWN0aW9uIGJlYW4gaW4gdGhlIFNwcmluZw0Kamh3PiBhcHBsaWNhdGlvbiBjb250ZXh0
LiBJdCBtaWdodCBiZSB3b3J0aCBiZW5jaG1hcmtpbmcgd2hldGhlciB0aGUNCmpodz4gc3lu
Y2hyb25pemVkIGJsb2NrIGlzbid0IHRoZSBiaWdnZXIgcGVyZm9ybWFuY2UgdGhyZWF0IGhl
cmUsDQpqaHc+IHRob3VnaCwgYXMgdGhlIGNvbnRleHQuZ2V0QmVhbiBjYWxsIGJvaWxzIGRv
d24gdG8gYSBIYXNoTWFwDQpqaHc+IGxvb2t1cC4NCg0Kamh3PiBJdCdzIGEgcGl0eSB0aGF0
IFN0cnV0cyBkb2Vzbid0IHBhc3MgaW4gdGhlIEFjdGlvbk1hcHBpbmcNCmpodz4gaW4gc29t
ZSBBY3Rpb24gaW5pdGlhbGl6YXRpb24gY2FsbGJhY2suIEFzIGZhciBhcyBJIGNhbiB0ZWxs
LCB0aGUNCmpodz4gbWFwcGluZyBpcyBkZXRlcm1pbmVkIGF0IEFjdGlvbiBpbml0aWFsaXph
dGlvbiB0aW1lLCBzbyB0aGlzDQpqaHc+IHdvdWxkIGhhdmUgYmVlbiBmZWFzaWJsZS4gSWYg
d2UgaGFkIHN1Y2ggYSBjYWxsYmFjaywgd2UgY291bGQNCmpodz4gc2ltcGx5IGZldGNoIHRo
ZSBkZWxlZ2F0ZSBBY3Rpb24gYXQgaW5pdGlhbGl6YXRpb24gdGltZSwNCmpodz4gY29tcGxl
dGVseSBhdm9pZGluZyB0aGUgbmVlZCBmb3Igc3luY2hyb25pemF0aW9uLg0KDQpqaHc+IEp1
ZXJnZW4NCg0KDQpqaHc+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpqaHc+IEZyb206
IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0
DQpqaHc+IFttYWlsdG86c3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blci1hZG1pbkBsaXN0cy5z
b3VyY2Vmb3JnZS5uZXRdT24gQmVoYWxmDQpqaHc+IE9mIERpcmsgTWFya2VydA0Kamh3PiBT
ZW50OiBUdWVzZGF5LCBBcHJpbCAxMywgMjAwNCAxMDo1NCBBTQ0Kamh3PiBUbzogavxyZ2Vu
IGj2bGxlciBbd2VyazNBVF0NCmpodz4gU3ViamVjdDogUmVbMl06IFtTcHJpbmdmcmFtZXdv
cmstZGV2ZWxvcGVyXSBTdHJ1dHMgU3ByaW5nIFBsdWdpbg0KDQoNCmpodz4gSGVsbG8gSvxy
Z2VuLA0KDQpqaHc+IEkganVzdCBoYWQgYSBsb29rIGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBv
ZiBEZWxlZ2F0aW5nQWN0aW9uUHJveHkuIEkNCmpodz4gd29uZGVyIHdoeSB5b3UgYXJlIHVz
aW5nIGEgbWVtYmFyIGF0dHJpYnV0ZSBkZWxlZ2F0ZUFjdGlvbi4gVGhlIGNsYXNzIGhhcyB0
bw0Kamh3PiBiZSB0aHJlYWQgc2FmZSwgYW5kIEkgdGhpbmcgdXNpbmcgdGhpcyBhdHRyaWJ1
dGUgaXQgaXNuJ3QuIEluIGdldERlbGVnYXRlQWN0aW9uDQpqaHc+IHlvdXIgc3luY2hyb25p
emVkIGFjY2VzcyBkb2VzIG5vdCBpbmNsdWRlIHRoZSByZXR1cm4gc3RhdGVtZW50Lg0KDQpq
aHc+IERvIEkgbWlzcyBzb21ldGhpbmc/DQoNCg0Kamh3PiBCZXN0IHJlZ2FyZHMsDQpqaHc+
IERpcmsNCg0KDQoNCmpodz4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0Kamh3PiBUaGlzIFNGLk5ldCBlbWFpbCBpcyBzcG9uc29y
ZWQgYnk6IElCTSBMaW51eCBUdXRvcmlhbHMNCmpodz4gRnJlZSBMaW51eCB0dXRvcmlhbCBw
cmVzZW50ZWQgYnkgRGFuaWVsIFJvYmJpbnMsIFByZXNpZGVudCBhbmQgQ0VPIG9mDQpqaHc+
IEdlblRvbyB0ZWNobm9sb2dpZXMuIExlYXJuIGV2ZXJ5dGhpbmcgZnJvbSBmdW5kYW1lbnRh
bHMgdG8gc3lzdGVtDQpqaHc+IGFkbWluaXN0cmF0aW9uLmh0dHA6Ly9hZHMub3Nkbi5jb20v
P2FkX2lkPTE0NzAmYWxsb2NfaWQ9MzYzOCZvcD1jbGljaw0Kamh3PiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kamh3PiBTcHJpbmdmcmFtZXdv
cmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0Kamh3PiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0Kamh3PiBodHRwczovL2xpc3RzLnNvdXJjZWZv
cmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoNCg0K
amh3PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQpqaHc+IFRoaXMgU0YuTmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogSUJNIExp
bnV4IFR1dG9yaWFscw0Kamh3PiBGcmVlIExpbnV4IHR1dG9yaWFsIHByZXNlbnRlZCBieSBE
YW5pZWwgUm9iYmlucywgUHJlc2lkZW50IGFuZCBDRU8gb2YNCmpodz4gR2VuVG9vIHRlY2hu
b2xvZ2llcy4gTGVhcm4gZXZlcnl0aGluZyBmcm9tIGZ1bmRhbWVudGFscyB0byBzeXN0ZW0N
Cmpodz4gYWRtaW5pc3RyYXRpb24uaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWQUNzAmYWxs
b2NfaWQ2Mzgmb3BsaWNrDQpqaHc+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpqaHc+IFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGlu
ZyBsaXN0DQpqaHc+IFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9y
Z2UubmV0DQpqaHc+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3Rp
bmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINCg0KDQoNCi0tIA0KQmVzdCByZWdhcmRz
LA0KRGlyaw0K

Re: [Springframework-developer] Struts Spring Plugin

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

Of course, you're right that the synchronized block should include the =
return statement - thanks for spotting this. The synchronization there =
isn't terribly important though, as it's just about unnecessarily =
re-fetching the bean from the application context.

The only reason for the delegateAction member attribute is speed: to =
avoid repeated lookups of the Action bean in the Spring application =
context. It might be worth benchmarking whether the synchronized block =
isn't the bigger performance threat here, though, as the context.getBean =
call boils down to a HashMap lookup.

It's a pity that Struts doesn't pass in the ActionMapping in some Action =
initialization callback. As far as I can tell, the mapping is determined =
at Action initialization time, so this would have been feasible. If we =
had such a callback, we could simply fetch the delegate Action at =
initialization time, completely avoiding the need for synchronization.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dirk Markert
Sent: Tuesday, April 13, 2004 10:54 AM
To: j=FCrgen h=F6ller [werk3AT]
Subject: Re[2]: [Springframework-developer] Struts Spring Plugin


Hello J=FCrgen,

I just had a look at the implementation of DelegatingActionProxy. I
wonder why you are using a membar attribute delegateAction. The class =
has to
be thread safe, and I thing using this attribute it isn't. In =
getDelegateAction
your synchronized access does not include the return statement.

Do I miss something?


Best regards,
Dirk



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.0.1

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

Rod,

A code freeze should be feasible from my point of view. As I'm heading =
to Prague for a 4-day break tomorrow, I certainly won't do any further =
code changes - just the actual release on Sunday :-)


Besides various stability and performance improvements, there are a =
couple of noteworthy enhancements respectively new features for 1.0.1:

- BeanWrapperImpl allows for registration of custom editors for =
array/List/Map properties and specific elements of array/List/Map =
properties

- AbstractXmlApplicationContext (and thus its subclasses like =
XmlWebApplicationContext) supports file patterns as config location, for =
example "/WEB-INF/*-context.xml"

- validation framework delegates to a MessageCodesResolver strategy for =
building error codes for ObjectErrors and FieldErrors, with a more =
sophisticated default implementation

- transaction-scoped Hibernate Sessions are provided even for plain JTA =
respectively EJB CMT transactions, without JtaTransactionManager being =
involved (mainly intended for implementing EJBs)

- sophisticated Struts integration, with support classes for accessing a =
Spring context, a ContextLoaderPlugIn, and a way to wire Struts Actions =
as Spring-managed beans


I'm not sure if we'll already be able to concentrate on 1.1 next. =
Neither JMS support nor JMX support nor declarative validation has =
reached milestone shape yet.

I guess it's pretty safe to assume that 1.1 RC1 is still several months =
away. I'm almost certain that we'll find enough minor issues to warrant =
a 1.0.2 release in the meantime.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of rod...@in...
Sent: Tuesday, April 13, 2004 10:26 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.1


>As we're about to release Spring 1.0.1 by the beginning of=20
next week, we need to re-test the current CVS contents=20
thoroughly.=20
Yes. I'd like to see a code freeze on the /src tree before=20
the release--say tomorrow?--except for any bug fixes.=20
Juergen, is this feasible?

Stability is paramount with 1.0.1. We have some worthwhile=20
new features, like sophisticated Struts integration, that we=20
should definitely include, but we need to try to bed down 1.0=20
with this release so we can focus on 1.1.

Regards,
Rod


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer