You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rick Reumann <st...@reumann.net> on 2005/08/08 22:06:10 UTC
A handle to Sessions in ServletContext?
I need to create a link to a servlet, that will invalidate all Sessions.
I'm assuming there is some sort of Collection or Array of Sessions that
is stored in the ServletContext?
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] JSP Clutter
Posted by Christopher Marsh-Bourdon <li...@marsh-bourdon.com>.
Sorry, the point was not to compare .net/JSF/Tapestry against Struts,
but to highlight that a bit fore thought into developing a good CSS
at the start of the project would have reduced the amount of markup
we have had to write in the last six months. It certainly makes our
life easier to maintain the code.
Cheers
Christopher Marsh-Bourdon
www.marsh-bourdon.com
AIM: marshbourdon
On 8 Aug 2005, at 22:22, Michael Jouravlev wrote:
> On 8/8/05, Christopher Marsh-Bourdon <li...@marsh-bourdon.com> wrote:
>
>> Over the past
>> six months we have been migrating our front-ends from .net to Java
>> based technologies, and Struts in the main. Now a new manager has
>> come on board and he wishes us to revisit the reasons why we choose
>> Struts. Now I was the main instigator as I have been using Struts
>> for the past 3 years and I had previously been using an in-house MVC
>> (urrgh!). I like MVCs and especially Struts, mainly because it fits
>> my mindset of seperation. The main critisism (and the point of this
>> missive) is that the argument I keep on facing is:
>>
>> "JSP/HTML/XHTML is a messy mark-up. It is cumbersome to refactor and
>> a bugger to work out. We could use Tapestry or JSF and forget about
>> HTML."
>>
>
> I would have thought that the main criticism would have been "Struts
> is a simple controller framework and does not have cool drop-in web
> controls or built-in DAO components, or out-of-the-box viewstate
> management, or simple view/business component integration, etc. Struts
> is a strange choice of yours, considering that you moved from asp.net.
>
>
>> I have still to convince this new manager that
>> Struts is the way, but I've removed one of the major arguments to
>> going down the Tapestry/JSF route for now (not that they don't use
>> CSSes)!
>>
>
> At least this is the area where asp.net is suckier than Struts: many
> asp.net controls have built-in font sizes or colors or table styles,
> so they cannot be controlled by CSS. On the other hand, Struts does
> not have the notion of web controls at all. You have to build all
> pages yourself and manually wire them to action form properties or to
> other beans' properties.
>
> Struts offers more freedom; maybe too much than an average web
> developer would wish for.
>
> Michael.
>
> ---
> Struts Dialogs
> http://struts.sourceforge.net/strutsdialogs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
Re: [OT] JSP Clutter
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/8/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 8/8/05, Christopher Marsh-Bourdon <li...@marsh-bourdon.com> wrote:
> > Over the past
> > six months we have been migrating our front-ends from .net to Java
> > based technologies, and Struts in the main. Now a new manager has
> > come on board and he wishes us to revisit the reasons why we choose
> > Struts. Now I was the main instigator as I have been using Struts
> > for the past 3 years and I had previously been using an in-house MVC
> > (urrgh!). I like MVCs and especially Struts, mainly because it fits
> > my mindset of seperation. The main critisism (and the point of this
> > missive) is that the argument I keep on facing is:
> >
> > "JSP/HTML/XHTML is a messy mark-up. It is cumbersome to refactor and
> > a bugger to work out. We could use Tapestry or JSF and forget about
> > HTML."
>
> I would have thought that the main criticism would have been "Struts
> is a simple controller framework and does not have cool drop-in web
> controls or built-in DAO components, or out-of-the-box viewstate
> management, or simple view/business component integration, etc.
This seems like the gist of the issue. A component framework like JSF
lets you encapsulate complex layout things like a data table into a
single component, or a small set of nested components (one per column,
then however many you need inside each column), with the component
managing the iteration -- and perhaps other details like sortable
columns and filters on the rows -- versus hand-rolling the iteration
with <c:forEach>, and hand coding all the <tr> and <td> elements, and
tediously coding all the advanced behavior yourself, on every such
table in your app.
The benefits of a component approach (abstract away the nitty gritty
details) are balanced by the restrictions (you can do what the
component can do). For most people, that's a pretty big win for
components -- but the key is that there be enough components around to
meet the majority of needs (and/or it needs to be easy enough to build
components that you can roll your own). JSF seems like it's on the
right trajectory in this regard, given widespread adoption from tool
vendors plus a growing number of component libraries.
> Struts
> is a strange choice of yours, considering that you moved from asp.net.
>
Keep in mind the timing of this decision ... three years ago, this was
a "well, duh".
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] JSP Clutter
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/8/05, Christopher Marsh-Bourdon <li...@marsh-bourdon.com> wrote:
> Over the past
> six months we have been migrating our front-ends from .net to Java
> based technologies, and Struts in the main. Now a new manager has
> come on board and he wishes us to revisit the reasons why we choose
> Struts. Now I was the main instigator as I have been using Struts
> for the past 3 years and I had previously been using an in-house MVC
> (urrgh!). I like MVCs and especially Struts, mainly because it fits
> my mindset of seperation. The main critisism (and the point of this
> missive) is that the argument I keep on facing is:
>
> "JSP/HTML/XHTML is a messy mark-up. It is cumbersome to refactor and
> a bugger to work out. We could use Tapestry or JSF and forget about
> HTML."
I would have thought that the main criticism would have been "Struts
is a simple controller framework and does not have cool drop-in web
controls or built-in DAO components, or out-of-the-box viewstate
management, or simple view/business component integration, etc. Struts
is a strange choice of yours, considering that you moved from asp.net.
> I have still to convince this new manager that
> Struts is the way, but I've removed one of the major arguments to
> going down the Tapestry/JSF route for now (not that they don't use
> CSSes)!
At least this is the area where asp.net is suckier than Struts: many
asp.net controls have built-in font sizes or colors or table styles,
so they cannot be controlled by CSS. On the other hand, Struts does
not have the notion of web controls at all. You have to build all
pages yourself and manually wire them to action form properties or to
other beans' properties.
Struts offers more freedom; maybe too much than an average web
developer would wish for.
Michael.
---
Struts Dialogs
http://struts.sourceforge.net/strutsdialogs
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] JSP Clutter
Posted by Dave Newton <ne...@pingsite.com>.
Christopher Marsh-Bourdon wrote:
> The anti-Struts/MVC argument, and it isn't mine, is that whereas
> Tapestry and JSF will generate the HTML/JSP, with Struts it has to be
> written and maintained. Now I haven't spent that much time with
> either Tapestry or JSF, but from what little I have read; it would
> appear that they can generate the HTML/JSP it without the need for it
> to be directly written (in HTML etc).
Don't know JSF, but you still write HTML with Tapestry, or at least when
I used it you did. You can wrap up HTML in components, but that's sort
of the same thing you do with Tiles, custom tags, etc.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] JSP Clutter
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Michael Jouravlev" <jm...@gmail.com>
> With Tapestry you create HTML template for each page, then stick data
> into it, using jwcid attribute. Your webdesigner is happy.
> With JSF you compose page using JSF tags either manually or using
> visual IDE, and then JSP/JSF engine will generate HTML in the runtime
> (I don't know how HTML is generated if you do not wrap JSF markup with
> JSP). Your webdesigner is not too happy, he needs to learn new IDE and
> the final page design may be not too... er... artistic, as with plain
> HTML/Tapestry.
Or... with JSF + Shale, you create an HTML template for each page, then
stick data into it, using the 'jsfid' attribute. Your webdesigner is happy
again. ;)
Here's an example using Shale's Tapestry-like views from the Rolodex in the
'use cases' webapp:
http://svn.apache.org/viewcvs.cgi/struts/shale/trunk/use-cases/src/web/rolodex/address.html?rev=209993&view=markup
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] JSP Clutter
Posted by Michael Jouravlev <jm...@gmail.com>.
With Tapestry you create HTML template for each page, then stick data
into it, using jwcid attribute. Your webdesigner is happy.
With JSF you compose page using JSF tags either manually or using
visual IDE, and then JSP/JSF engine will generate HTML in the runtime
(I don't know how HTML is generated if you do not wrap JSF markup with
JSP). Your webdesigner is not too happy, he needs to learn new IDE and
the final page design may be not too... er... artistic, as with plain
HTML/Tapestry.
If you think of Tapestry, look at Wicket. A great new framework and it
is being developed very fast.
On 8/8/05, Christopher Marsh-Bourdon <li...@marsh-bourdon.com> wrote:
> No, I'm not saying that JSF or Tapestry will be able to mind read,
> but I am under the impression (probably very wrong by the way this is
> going) that they are able to generate content based on XML or Java
> markup. As I say I haven't had the time to look further into JSF/
> Tapestry bar a few articles and a demonstration.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] JSP Clutter
Posted by Christopher Marsh-Bourdon <li...@marsh-bourdon.com>.
No, I'm not saying that JSF or Tapestry will be able to mind read,
but I am under the impression (probably very wrong by the way this is
going) that they are able to generate content based on XML or Java
markup. As I say I haven't had the time to look further into JSF/
Tapestry bar a few articles and a demonstration.
Yours in ignorance!
Cheers
Christopher Marsh-Bourdon
www.marsh-bourdon.com
AIM: marshbourdon
On 8 Aug 2005, at 22:14, Leon Rosenberg wrote:
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Christopher Marsh-Bourdon [mailto:lists@marsh-bourdon.com]
>> Gesendet: Montag, 8. August 2005 23:05
>> An: Struts Users Mailing List
>> Betreff: Re: [OT] JSP Clutter
>>
>> The anti-Struts/MVC argument, and it isn't mine, is that
>> whereas Tapestry and JSF will generate the HTML/JSP, with
>> Struts it has to be written and maintained. Now I haven't
>> spent that much time with either Tapestry or JSF, but from
>> what little I have read; it would appear that they can
>> generate the HTML/JSP it without the need for it to be
>> directly written (in HTML etc). That seems to be the gist of it.
>>
>
> It's funny :-)
> So you think you take Tapestry or Shale, and your site comes out by
> magic?
> I am sorry, but even, if Graig himself would come to your office
> and snip
> with his fingers, it wouldn't be enough to YOUR HTML of YOUR SITE
> appear by
> magic.
>
> Whichever framework you choose, none of them will know, that your
> site is in
> red on black background with blue drop down lists in Verdana 8px.
> If you
> find one, tell me, it would probably save me 30-50% of project
> time, and
> make about 10.000 html producers world wide unemployed :-)
>
> Regards
> Leon
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
Re: [OT] JSP Clutter
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Christopher Marsh-Bourdon [mailto:lists@marsh-bourdon.com]
> Gesendet: Montag, 8. August 2005 23:05
> An: Struts Users Mailing List
> Betreff: Re: [OT] JSP Clutter
>
> The anti-Struts/MVC argument, and it isn't mine, is that
> whereas Tapestry and JSF will generate the HTML/JSP, with
> Struts it has to be written and maintained. Now I haven't
> spent that much time with either Tapestry or JSF, but from
> what little I have read; it would appear that they can
> generate the HTML/JSP it without the need for it to be
> directly written (in HTML etc). That seems to be the gist of it.
It's funny :-)
So you think you take Tapestry or Shale, and your site comes out by magic?
I am sorry, but even, if Graig himself would come to your office and snip
with his fingers, it wouldn't be enough to YOUR HTML of YOUR SITE appear by
magic.
Whichever framework you choose, none of them will know, that your site is in
red on black background with blue drop down lists in Verdana 8px. If you
find one, tell me, it would probably save me 30-50% of project time, and
make about 10.000 html producers world wide unemployed :-)
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] JSP Clutter
Posted by Christopher Marsh-Bourdon <li...@marsh-bourdon.com>.
The anti-Struts/MVC argument, and it isn't mine, is that whereas
Tapestry and JSF will generate the HTML/JSP, with Struts it has to be
written and maintained. Now I haven't spent that much time with
either Tapestry or JSF, but from what little I have read; it would
appear that they can generate the HTML/JSP it without the need for it
to be directly written (in HTML etc). That seems to be the gist of it.
Cheers
Christopher Marsh-Bourdon
www.marsh-bourdon.com
AIM: marshbourdon
On 8 Aug 2005, at 21:58, Leon Rosenberg wrote:
>
>
>
>>
>> "JSP/HTML/XHTML is a messy mark-up. It is cumbersome to
>> refactor and a bugger to work out. We could use Tapestry or
>> JSF and forget about HTML."
>>
>
> That's right, but as long as you deliver html to the customer, you
> have to
> deal with it, regardless of your technology.
> At the end of the day, someone has to produce the html. It can be a
> view
> component as in JSF, a tile as in Struts, or whatever, but it has
> to be
> done, and the HTML code is ABSOLUTELY IDENTICAL in all cases :-)
> So sorry, but this is no argument pro or contra struts.
>
>
>>
>> So, I've gone back and revisited our JSPs to see if this
>> criticism is correct; and to be honest it is. I am a fairly
>> careful coder and I adhere to the XHTML standards as
>> diligently as possible, but it still looks pretty confusing.
>> Now the main issue is that we really (a team of three) never
>> had the time to get the basics right prior to launching into
>> the migration from .net to Struts. By the basics, I mean
>> working out an encompassing* CSS.
>>
>
> Good decision :-)
>
>
>> So, I've gone back and re-
>> factored the JSP to use an encompassing* CSS document, and lo
>> and behold the code (JSP) is cleaner and so much better to work with.
>>
>> Now maybe everyone but me and my team uses an encompassing*
>> CSS throughout their JSP as standard and never deviates from
>> that path, but if you don't; take a little while to research
>> what it can do for your development. I have still to
>> convince this new manager that Struts is the way, but I've
>> removed one of the major arguments to going down the
>> Tapestry/JSF route for now (not that they don't use CSSes)!
>>
>> * By "encompassing', I mean no formatting is used directly in
>> the JSP where it can be deferred to a style.
>>
>
>
> Again, what exactly is the difference in framework you use, as long
> as the
> resulting HTML page looks the same?
>
> Don't misunderstand me, I congratulate you to better code and
> encourage you
> to use css, but I don't see how the usage of css can influence a
> pro- or
> contra-struts solution?
>
> Regards
> Leon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
Re: [OT] JSP Clutter
Posted by Leon Rosenberg <st...@anotheria.net>.
>
> "JSP/HTML/XHTML is a messy mark-up. It is cumbersome to
> refactor and a bugger to work out. We could use Tapestry or
> JSF and forget about HTML."
That's right, but as long as you deliver html to the customer, you have to
deal with it, regardless of your technology.
At the end of the day, someone has to produce the html. It can be a view
component as in JSF, a tile as in Struts, or whatever, but it has to be
done, and the HTML code is ABSOLUTELY IDENTICAL in all cases :-)
So sorry, but this is no argument pro or contra struts.
>
> So, I've gone back and revisited our JSPs to see if this
> criticism is correct; and to be honest it is. I am a fairly
> careful coder and I adhere to the XHTML standards as
> diligently as possible, but it still looks pretty confusing.
> Now the main issue is that we really (a team of three) never
> had the time to get the basics right prior to launching into
> the migration from .net to Struts. By the basics, I mean
> working out an encompassing* CSS.
Good decision :-)
> So, I've gone back and re-
> factored the JSP to use an encompassing* CSS document, and lo
> and behold the code (JSP) is cleaner and so much better to work with.
>
> Now maybe everyone but me and my team uses an encompassing*
> CSS throughout their JSP as standard and never deviates from
> that path, but if you don't; take a little while to research
> what it can do for your development. I have still to
> convince this new manager that Struts is the way, but I've
> removed one of the major arguments to going down the
> Tapestry/JSF route for now (not that they don't use CSSes)!
>
> * By "encompassing', I mean no formatting is used directly in
> the JSP where it can be deferred to a style.
Again, what exactly is the difference in framework you use, as long as the
resulting HTML page looks the same?
Don't misunderstand me, I congratulate you to better code and encourage you
to use css, but I don't see how the usage of css can influence a pro- or
contra-struts solution?
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[OT] JSP Clutter
Posted by Christopher Marsh-Bourdon <li...@marsh-bourdon.com>.
Apologies if this it _too_ off-topic, but I think it might be worth
mentioning. In the same vein as my "web framework is better than
yours" we, in the office, have been having a fairly heated
discussion about which way we go technology wise next. Over the past
six months we have been migrating our front-ends from .net to Java
based technologies, and Struts in the main. Now a new manager has
come on board and he wishes us to revisit the reasons why we choose
Struts. Now I was the main instigator as I have been using Struts
for the past 3 years and I had previously been using an in-house MVC
(urrgh!). I like MVCs and especially Struts, mainly because it fits
my mindset of seperation. The main critisism (and the point of this
missive) is that the argument I keep on facing is:
"JSP/HTML/XHTML is a messy mark-up. It is cumbersome to refactor and
a bugger to work out. We could use Tapestry or JSF and forget about
HTML."
So, I've gone back and revisited our JSPs to see if this criticism is
correct; and to be honest it is. I am a fairly careful coder and I
adhere to the XHTML standards as diligently as possible, but it still
looks pretty confusing. Now the main issue is that we really (a team
of three) never had the time to get the basics right prior to
launching into the migration from .net to Struts. By the basics, I
mean working out an encompassing* CSS. So, I've gone back and re-
factored the JSP to use an encompassing* CSS document, and lo and
behold the code (JSP) is cleaner and so much better to work with.
Now maybe everyone but me and my team uses an encompassing* CSS
throughout their JSP as standard and never deviates from that path,
but if you don't; take a little while to research what it can do for
your development. I have still to convince this new manager that
Struts is the way, but I've removed one of the major arguments to
going down the Tapestry/JSF route for now (not that they don't use
CSSes)!
* By "encompassing', I mean no formatting is used directly in the JSP
where it can be deferred to a style.
Cheers
Christopher Marsh-Bourdon
www.marsh-bourdon.com
AIM: marshbourdon
Re: A handle to Sessions in ServletContext?
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote the following on 8/8/2005 4:27 PM:
> Dave is right ... you would need to maintain your own list of
> currently active sessions (by writing an HttpSessionListener). To be
> thorough, you'd also want to make your listener implement
> HttpSessionActivationListener so it could deal with session migration
> in a distributed environment.
Ok thanks Craig and Dave.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: A handle to Sessions in ServletContext?
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/8/05, Dave Newton <ne...@pingsite.com> wrote:
> Rick Reumann wrote:
>
> > I need to create a link to a servlet, that will invalidate all
> > Sessions. I'm assuming there is some sort of Collection or Array of
> > Sessions that is stored in the ServletContext?
>
> Hmm, I'm not sure that there is--I think I remember having to keep a
> context-scoped list of sessions via some sort of listener and running
> through it myself, but that was awhile ago.
>
Dave is right ... you would need to maintain your own list of
currently active sessions (by writing an HttpSessionListener). To be
thorough, you'd also want to make your listener implement
HttpSessionActivationListener so it could deal with session migration
in a distributed environment.
For those not familiar with the latter interface, it includes two methods:
* public void sessionWilPassivate(HttpSession) -- the specified
session is about to be removed from the active memory of this
server instance, either to be migrated or to be swapped out due to
lack of activity.
* public void sessionDidActivate(HttpSession) -- the specified
session that used to be passivated has been activated in the
current server instance.
> Dave
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: A handle to Sessions in ServletContext?
Posted by Dave Newton <ne...@pingsite.com>.
Rick Reumann wrote:
> I need to create a link to a servlet, that will invalidate all
> Sessions. I'm assuming there is some sort of Collection or Array of
> Sessions that is stored in the ServletContext?
Hmm, I'm not sure that there is--I think I remember having to keep a
context-scoped list of sessions via some sort of listener and running
through it myself, but that was awhile ago.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org