Re: [OS-webwork] Enhancements to Jasper Reports
Pardon me for my ignorance... but could you possibly provide a high level detail of what Jasper Reports is, specifically how it integrates in with WW? -Pat - Original Message - From: "Mike Cannon-Brookes" <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Sent: Wednesday, January 08, 2003 11:15 PM Subject: Re: [OS-webwork] Enhancements to Jasper Reports > Not yet - but I'm itching to learn how to do it :) > > Cheers, > Mike > > On 9/1/03 4:48 PM, "Peter Kelley" ([EMAIL PROTECTED]) penned the words: > > > I've postulated a few changes to the Jasper Reports view code at > > > > http://www.opensymphony.com:8668/space/JasperReports+View > > > > In short I want to add some more view types (CSV, XML, XLS) and also > > allow full expression language access for Jasper Report fields. I plan > > to maintain full backward compatibility. > > > > Is anyone other than us using this ? > > > > Anyway if you want to comment please do so either here or in wiki. > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Path for WW1.3 PropertyEditors bug
The issue was already raised as major issue WW-96. I have attached the patch to it in Jira now. Cheers, Dick Zetterberg [EMAIL PROTECTED] - Original Message - From: "Scott Farquhar" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 09, 2003 2:20 AM Subject: Re: [OS-webwork] Path for WW1.3 PropertyEditors bug > Dick, > > Can you raise a JIRA issue online for this, and attach your patch? This > will ensure that it doesn't get lost in the mailing list discussions. > > Thanks for your contribution! > > Cheers, > Scott > > Dick Zetterberg wrote: > > Hi there, > > > > I have made a patch that fixes the problem with the non-threadsafe property editors in the current 1.3 RC1 release. > > It also gives a slight performance increase like 10-20% for pages that uses editors alot (many method calls, lots of data etc). > > The new code should be backwards-compatible so no changes are needed for your code. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] URLTag changes in ww 1.3
Hi all we use the webtable ww tag in our application. After installing 1.3.0 rc1 the sorting in our tables in our application doesn't behave correctly anymore. After some investigating I saw that the URLTag in the way that POST'ed data isn't included anymore when the url tag has no value parameter - cvs comment: "Generated tag no longer includes parameters that were POST'ed if the "page" attribute is not specified" Unfortunatly the table.jsp which is used for the webtable tag does use the url tag in that manner to set up the sorting link. [..] "> [..] now our POSTed data in our forms isn't used anymore when sorting and so nearly all views with forms and tables don't work properly anymore. What's the best way to get our tables working as before? Another thought: couldn't be added a parameter to the URLTag that could decide if the POSTed parameters are included or not (so the distinction if the parameters are added or not is not driven by the value attribute...) Many thanks for your help. Cheers -Paolo --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] URLTag changes in ww 1.3
I suppose no one bothered to include some kind of migration path for this "bugfix" like I said was needed? Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net - Original Message - From: "Vedovato Paolo" <[EMAIL PROTECTED]> To: "Webwork (E-Mail)" <[EMAIL PROTECTED]> Sent: Thursday, January 09, 2003 11:41 Subject: [OS-webwork] URLTag changes in ww 1.3 > Hi all > > we use the webtable ww tag in our application. After installing 1.3.0 rc1 > the sorting in our tables in our application doesn't behave correctly > anymore. > > After some investigating I saw that the URLTag in the way that POST'ed data > isn't included anymore when the url tag has no value parameter - cvs > comment: "Generated tag no longer includes parameters that were POST'ed if > the "page" attribute is not specified" > > Unfortunatly the table.jsp which is used for the webtable tag does use the > url tag in that manner to set up the sorting link. > [..] > value="offset"/> > value="'ASC'"/>"> > > [..] > > now our POSTed data in our forms isn't used anymore when sorting and so > nearly all views with forms and tables don't work properly anymore. > > What's the best way to get our tables working as before? Another thought: > couldn't be added a parameter to the URLTag that could decide if the POSTed > parameters are included or not (so the distinction if the parameters are > added or not is not driven by the value attribute...) > > Many thanks for your help. > > Cheers > -Paolo > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] URLTag changes in ww 1.3
As I recall, Rickard asked the list if anyone was using it; nobody replied positively, so the need for a migration was assumed to be light. Assumptions, as usual... erm... let's go into avoid-stupid-aphorisms mode. This goes back to scope and myopia. That aside, how SHOULD Paolo's problem be solved? On Thu, 9 Jan 2003, boxed wrote: > I suppose no one bothered to include some kind of migration path for this > "bugfix" like I said was needed? > > Anders Hovmöller > [EMAIL PROTECTED] http://boxed.killingar.net > > > > > - Original Message - > From: "Vedovato Paolo" <[EMAIL PROTECTED]> > To: "Webwork (E-Mail)" <[EMAIL PROTECTED]> > Sent: Thursday, January 09, 2003 11:41 > Subject: [OS-webwork] URLTag changes in ww 1.3 > > > > Hi all > > > > we use the webtable ww tag in our application. After installing 1.3.0 rc1 > > the sorting in our tables in our application doesn't behave correctly > > anymore. > > > > After some investigating I saw that the URLTag in the way that POST'ed > data > > isn't included anymore when the url tag has no value parameter - cvs > > comment: "Generated tag no longer includes parameters that were POST'ed if > > the "page" attribute is not specified" > > > > Unfortunatly the table.jsp which is used for the webtable tag does use the > > url tag in that manner to set up the sorting link. > > [..] > > > value="offset"/> > > > value="'ASC'"/>"> > > > > [..] > > > > now our POSTed data in our forms isn't used anymore when sorting and so > > nearly all views with forms and tables don't work properly anymore. > > > > What's the best way to get our tables working as before? Another thought: > > couldn't be added a parameter to the URLTag that could decide if the > POSTed > > parameters are included or not (so the distinction if the parameters are > > added or not is not driven by the value attribute...) > > > > Many thanks for your help. > > > > Cheers > > -Paolo > > > > > > --- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > ___ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Documentation
Whatever happened to Ken's effort at documentation? I haven't seen him on the list lately. Was wondering if he was still working on the docs or if he'd left the list/project. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Documentation
He was probably offended by all the horrible negativity aimed at him on #java. On Thu, 9 Jan 2003, Wayland Chan wrote: > Whatever happened to Ken's effort at documentation? I > haven't seen him on the list lately. Was wondering if > he was still working on the docs or if he'd left the > list/project. > > > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Documentation
Joseph Ottinger wrote: He was probably offended by all the horrible negativity aimed at him on #java. What was said about him on #java? /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Documentation
On Thu, 9 Jan 2003, [ISO-8859-1] Rickard Öberg wrote: > Joseph Ottinger wrote: > > He was probably offended by all the horrible negativity aimed at him on > > #java. > > What was said about him on #java? I dunno, probably something like "Ken is supposed to be doing documentation, which is really cool, esp. since he apparently has experience doing so." --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Documentation
Joseph Ottinger wrote: Joseph Ottinger wrote: He was probably offended by all the horrible negativity aimed at him on #java. What was said about him on #java? I dunno, probably something like "Ken is supposed to be doing documentation, which is really cool, esp. since he apparently has experience doing so." I don't get it. Why would that be "horrible negativity"? And why would he be offended by that? /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Documentation
I believe Joseph was attempting to be humorous. > -Original Message- > From: Rickard Öberg [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 09, 2003 9:54 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Documentation > > > Joseph Ottinger wrote: > >>Joseph Ottinger wrote: > >> > >>>He was probably offended by all the horrible negativity > aimed at him > >>>on #java. > >> > >>What was said about him on #java? > > > > I dunno, probably something like "Ken is supposed to be doing > > documentation, which is really cool, esp. since he apparently has > > experience doing so." > > I don't get it. Why would that be "horrible negativity"? And > why would > he be offended by that? > > /Rickard > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something > 2 See! http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Documentation
> I don't get it. Can't you see the irony? --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Documentation
Aapo Laakkonen wrote: I don't get it. Can't you see the irony? Well, I *could* see it as irony, but since it wasn't even remotely funny it would be more like a sarcastic rant, and since Joe seems to want to avoid things like that (given his recent new years benediction) it didn't make sense. But maybe you're right. I don't know. That's why I asked. /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Documentation
Which once again shows the complete inadequacy of chat and email w/re to irony and subtlety. Now, if we could just get people to stay away from it (irony and subtelty that is -- not mail and chat)... cheers, /Måns > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Jason Carreira > Sent: den 9 januari 2003 15:50 > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Documentation > > > I believe Joseph was attempting to be humorous. > > > -Original Message- > > From: Rickard Öberg [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, January 09, 2003 9:54 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [OS-webwork] Documentation > > > > > > Joseph Ottinger wrote: > > >>Joseph Ottinger wrote: > > >> > > >>>He was probably offended by all the horrible negativity > > aimed at him > > >>>on #java. > > >> > > >>What was said about him on #java? > > > > > > I dunno, probably something like "Ken is supposed to be doing > > > documentation, which is really cool, esp. since he apparently has > > > experience doing so." > > > > I don't get it. Why would that be "horrible negativity"? And > > why would > > he be offended by that? > > > > /Rickard > > > > > > > > --- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something > > 2 See! http://www.vasoftware.com > > ___ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! > http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] XWork Interceptors
So anyway, I'm just going to disregard the "Documentation" thread and start a thread that is actually useful :) (Though, Ken, we're still hoping your willing to do some Doc work!) So besides Action Chaining, Rickard made a good point that interceptors is very important as well. I'd like to talk about the actual implementation now -- using the transaction scenario as an example. How will the interceptor know when to rollback or commit? Of course on an Exception it should, but what about on ERROR or INPUT? What if the action, to signify it's is complete, used COMPLETE instead of SUCCESS? Do you see my point? How can we make interceptors work for all cases? I'm guessing some sort of configuration is needed for each interceptor on each action, so we could do something like: success, complete And then the interceptot could know to rollback if the return value isn't one of those two. Rickard, is this what you had in mind? Also, Interceptors would fit in to the GenericDispatcher area. I think that they would replace ActionFactoryProxies entirely, correct? Also, maybe Rickard you can provide some sample psuedo code for an Interceptor as well as how it would go about being invoked in GenericDispatcher? -Pat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
I have to say, I really do think that adding tx on this level is a bad idea. For one thing, webwork is NOT a tx system, whatever it talks to should provide whatever tx support you require. Reinventing the wheel by handling the tx on this level seemsa waste of effort (vendors have already spent years getting their tx impls to work very nicely). To my mind (I'll admit I didnt read all the previous emails about interceptors in great detail, so I might be repeating old/known/wrong stuff), interceptors are pretty much like filters. An interceptor would choose what to intercept, then have access to context and whatnot to adds its own stuff. It can choose to then keep passing the request, or bail out. Similarly, an interceptor can be applied post-action. Quoting Patrick Lightbody <[EMAIL PROTECTED]>: > So anyway, I'm just going to disregard the "Documentation" thread and start > a thread that is actually useful :) > > (Though, Ken, we're still hoping your willing to do some Doc work!) > > So besides Action Chaining, Rickard made a good point that interceptors is > very important as well. I'd like to talk about the actual implementation > now -- using the transaction scenario as an example. > > How will the interceptor know when to rollback or commit? Of course on an > Exception it should, but what about on ERROR or INPUT? What if the action, > to signify it's is complete, used COMPLETE instead of SUCCESS? Do you see > my > point? How can we make interceptors work for all cases? I'm guessing some > sort of configuration is needed for each interceptor on each action, so we > could do something like: > > > success, complete > > > And then the interceptot could know to rollback if the return value isn't > one of those two. > > Rickard, is this what you had in mind? > > Also, Interceptors would fit in to the GenericDispatcher area. I think that > they would replace ActionFactoryProxies entirely, correct? Also, maybe > Rickard you can provide some sample psuedo code for an Interceptor as well > as how it would go about being invoked in GenericDispatcher? > > -Pat > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] XWork Interceptors
Patrick, as we discussed on IRC, I've been working on this. I've
basically got the Interceptor framework built, I think, although I
haven't tested it :-)
I'm not sure what you were thinking, but mine does not plug in at the
ActionFactoryProxy level. Basically what mine does is to mimic the way
the javax.servlet.Filter works. Basically, you register all of your
interceptors at the top of your xwork.xml like so:
The DefaultConfiguration builds a Map of the names to instances of these
classes (my thought here being that interceptors should be stateless, so
we only need one instance of each and we can just push invocations
through it), then, in your action declaration, like there are result
references, you have something like this:
17
Bar
DefaultConfiguration then builds an InterceptorChain with the list of
Interceptors and the Action. The interceptor chain has a method,
doInterceptor() which does this:
public String doInterceptor() throws Exception {
if (interceptors.hasNext()) {
Interceptor interceptor = (Interceptor) interceptors.next();
result = interceptor.intercept(this);
} else {
result = action.execute();
}
return result;
}
The sub interceptors can choose to pass the call through by using the
InterceptorChain passed in by doing interceptor.doInterceptor() again.
My base Interceptor implementation does this:
public String intercept(InterceptorChain chain) throws Exception {
before(chain);
String result = chain.doInterceptor();
after(chain);
return result;
}
Which allows subclasses to put code before and after the rest of the
processing.
What happens in GenericDispatcher is this (replacing the direct
execute() of the action):
List interceptors = actionConfig.getInterceptors();
InterceptorChain interceptorChain = new InterceptorChain(action,
interceptors);
result = interceptorChain.doInterceptor();
Anyway, that's what I've been working on... Thoughts?
Jason
> -Original Message-
> From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 09, 2003 10:24 AM
> To: os-ww
> Subject: [OS-webwork] XWork Interceptors
>
>
> So anyway, I'm just going to disregard the "Documentation"
> thread and start a thread that is actually useful :)
>
> (Though, Ken, we're still hoping your willing to do some Doc work!)
>
> So besides Action Chaining, Rickard made a good point that
> interceptors is very important as well. I'd like to talk
> about the actual implementation now -- using the transaction
> scenario as an example.
>
> How will the interceptor know when to rollback or commit? Of
> course on an Exception it should, but what about on ERROR or
> INPUT? What if the action, to signify it's is complete, used
> COMPLETE instead of SUCCESS? Do you see my point? How can we
> make interceptors work for all cases? I'm guessing some sort
> of configuration is needed for each interceptor on each
> action, so we could do something like:
>
>
> success, complete
>
>
> And then the interceptot could know to rollback if the return
> value isn't one of those two.
>
> Rickard, is this what you had in mind?
>
> Also, Interceptors would fit in to the GenericDispatcher
> area. I think that they would replace ActionFactoryProxies
> entirely, correct? Also, maybe Rickard you can provide some
> sample psuedo code for an Interceptor as well as how it would
> go about being invoked in GenericDispatcher?
>
> -Pat
>
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something
> 2 See! http://www.vasoftware.com
> ___
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] XWork Interceptors
As for intercepting transactions, I would say have a key that is set in the context which tells the after() part of the Tx interceptor what to do. Kind of like setting rollbackOnly on a UserTransaction. Assume that the transaction should be committed unless an exception is caught or rollbackOnly is set on the ActionContext. > -Original Message- > From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 09, 2003 10:24 AM > To: os-ww > Subject: [OS-webwork] XWork Interceptors > > > So anyway, I'm just going to disregard the "Documentation" > thread and start a thread that is actually useful :) > > (Though, Ken, we're still hoping your willing to do some Doc work!) > > So besides Action Chaining, Rickard made a good point that > interceptors is very important as well. I'd like to talk > about the actual implementation now -- using the transaction > scenario as an example. > > How will the interceptor know when to rollback or commit? Of > course on an Exception it should, but what about on ERROR or > INPUT? What if the action, to signify it's is complete, used > COMPLETE instead of SUCCESS? Do you see my point? How can we > make interceptors work for all cases? I'm guessing some sort > of configuration is needed for each interceptor on each > action, so we could do something like: > > > success, complete > > > And then the interceptot could know to rollback if the return > value isn't one of those two. > > Rickard, is this what you had in mind? > > Also, Interceptors would fit in to the GenericDispatcher > area. I think that they would replace ActionFactoryProxies > entirely, correct? Also, maybe Rickard you can provide some > sample psuedo code for an Interceptor as well as how it would > go about being invoked in GenericDispatcher? > > -Pat > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something > 2 See! http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] XWork Interceptors
Well, for a different example, how about setting up a Hibernate Session and then closing it on the way out? Then Hibernate can manage your transactions. > -Original Message- > From: Hani Suleiman [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 09, 2003 10:35 AM > To: [EMAIL PROTECTED]; Patrick Lightbody > Cc: os-ww > Subject: Re: [OS-webwork] XWork Interceptors > > > I have to say, I really do think that adding tx on this level > is a bad idea. For one thing, webwork is NOT a tx system, > whatever it talks to should provide whatever tx support you > require. Reinventing the wheel by handling the tx on this > level seemsa waste of effort (vendors have already spent > years getting their tx impls to work very nicely). > > To my mind (I'll admit I didnt read all the previous emails > about interceptors in great detail, so I might be repeating > old/known/wrong stuff), interceptors are pretty much like > filters. An interceptor would choose what to intercept, then > have access to context and whatnot to adds its own stuff. It > can choose to then keep passing the request, or bail out. > Similarly, an interceptor can be applied post-action. > > Quoting Patrick Lightbody <[EMAIL PROTECTED]>: > > > So anyway, I'm just going to disregard the "Documentation" > thread and > > start a thread that is actually useful :) > > > > (Though, Ken, we're still hoping your willing to do some Doc work!) > > > > So besides Action Chaining, Rickard made a good point that > > interceptors is very important as well. I'd like to talk about the > > actual implementation now -- using the transaction scenario as an > > example. > > > > How will the interceptor know when to rollback or commit? > Of course on > > an Exception it should, but what about on ERROR or INPUT? > What if the > > action, to signify it's is complete, used COMPLETE instead > of SUCCESS? > > Do you see my point? How can we make interceptors work for > all cases? > > I'm guessing some sort of configuration is needed for each > interceptor > > on each action, so we could do something like: > > > > > > success, complete > > > > > > And then the interceptot could know to rollback if the return value > > isn't one of those two. > > > > Rickard, is this what you had in mind? > > > > Also, Interceptors would fit in to the GenericDispatcher > area. I think > > that they would replace ActionFactoryProxies entirely, > correct? Also, > > maybe Rickard you can provide some sample psuedo code for an > > Interceptor as well as how it would go about being invoked in > > GenericDispatcher? > > > > -Pat > > > > > > > > > > --- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = > Something 2 See! > > http://www.vasoftware.com > > ___ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > > > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something > 2 See! http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
Looks great Jason! Can't wait to see it!
-Pat
- Original Message -
From: "Jason Carreira" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 09, 2003 7:43 AM
Subject: RE: [OS-webwork] XWork Interceptors
> Patrick, as we discussed on IRC, I've been working on this. I've
> basically got the Interceptor framework built, I think, although I
> haven't tested it :-)
>
> I'm not sure what you were thinking, but mine does not plug in at the
> ActionFactoryProxy level. Basically what mine does is to mimic the way
> the javax.servlet.Filter works. Basically, you register all of your
> interceptors at the top of your xwork.xml like so:
>
>
> class="com.opensymphony.xwork.interceptor.TimerInterceptor"/>
> class="com.opensymphony.xwork.interceptor.LoggingInterceptor"/>
>
>
> The DefaultConfiguration builds a Map of the names to instances of these
> classes (my thought here being that interceptors should be stateless, so
> we only need one instance of each and we can just push invocations
> through it), then, in your action declaration, like there are result
> references, you have something like this:
>
> class="com.opensymphony.xwork.action.SimpleAction">
>
>
>
> 17
>
>
>
>
>
>
>
>
>
> Bar
>
>
>
>
>
>
>
>
>
>
>
>
> DefaultConfiguration then builds an InterceptorChain with the list of
> Interceptors and the Action. The interceptor chain has a method,
> doInterceptor() which does this:
>
>public String doInterceptor() throws Exception {
> if (interceptors.hasNext()) {
> Interceptor interceptor = (Interceptor) interceptors.next();
> result = interceptor.intercept(this);
> } else {
> result = action.execute();
> }
>
> return result;
> }
>
> The sub interceptors can choose to pass the call through by using the
> InterceptorChain passed in by doing interceptor.doInterceptor() again.
> My base Interceptor implementation does this:
>
> public String intercept(InterceptorChain chain) throws Exception {
> before(chain);
>
> String result = chain.doInterceptor();
> after(chain);
>
> return result;
> }
>
> Which allows subclasses to put code before and after the rest of the
> processing.
>
> What happens in GenericDispatcher is this (replacing the direct
> execute() of the action):
>
> List interceptors = actionConfig.getInterceptors();
> InterceptorChain interceptorChain = new InterceptorChain(action,
> interceptors);
> result = interceptorChain.doInterceptor();
>
>
> Anyway, that's what I've been working on... Thoughts?
>
> Jason
>
> > -Original Message-
> > From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, January 09, 2003 10:24 AM
> > To: os-ww
> > Subject: [OS-webwork] XWork Interceptors
> >
> >
> > So anyway, I'm just going to disregard the "Documentation"
> > thread and start a thread that is actually useful :)
> >
> > (Though, Ken, we're still hoping your willing to do some Doc work!)
> >
> > So besides Action Chaining, Rickard made a good point that
> > interceptors is very important as well. I'd like to talk
> > about the actual implementation now -- using the transaction
> > scenario as an example.
> >
> > How will the interceptor know when to rollback or commit? Of
> > course on an Exception it should, but what about on ERROR or
> > INPUT? What if the action, to signify it's is complete, used
> > COMPLETE instead of SUCCESS? Do you see my point? How can we
> > make interceptors work for all cases? I'm guessing some sort
> > of configuration is needed for each interceptor on each
> > action, so we could do something like:
> >
> >
> > success, complete
> >
> >
> > And then the interceptot could know to rollback if the return
> > value isn't one of those two.
> >
> > Rickard, is this what you had in mind?
> >
> > Also, Interceptors would fit in to the GenericDispatcher
> > area. I think that they would replace ActionFactoryProxies
> > entirely, correct? Also, maybe Rickard you can provide some
> > sample psuedo code for an Interceptor as well as how it would
> > go about being invoked in GenericDispatcher?
> >
> > -Pat
> >
> >
> >
> >
> > ---
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something
> > 2 See! http://www.vasoftware.com
> > ___
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld
http://www.vasoftware.com
> ___
Re: [OS-webwork] XWork Interceptors
One more thought... maybe the initialization parameters should become a
standard interceptor as well. I believe rickard had suggested this.
-Pat
- Original Message -
From: "Jason Carreira" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 09, 2003 7:43 AM
Subject: RE: [OS-webwork] XWork Interceptors
> Patrick, as we discussed on IRC, I've been working on this. I've
> basically got the Interceptor framework built, I think, although I
> haven't tested it :-)
>
> I'm not sure what you were thinking, but mine does not plug in at the
> ActionFactoryProxy level. Basically what mine does is to mimic the way
> the javax.servlet.Filter works. Basically, you register all of your
> interceptors at the top of your xwork.xml like so:
>
>
> class="com.opensymphony.xwork.interceptor.TimerInterceptor"/>
> class="com.opensymphony.xwork.interceptor.LoggingInterceptor"/>
>
>
> The DefaultConfiguration builds a Map of the names to instances of these
> classes (my thought here being that interceptors should be stateless, so
> we only need one instance of each and we can just push invocations
> through it), then, in your action declaration, like there are result
> references, you have something like this:
>
> class="com.opensymphony.xwork.action.SimpleAction">
>
>
>
> 17
>
>
>
>
>
>
>
>
>
> Bar
>
>
>
>
>
>
>
>
>
>
>
>
> DefaultConfiguration then builds an InterceptorChain with the list of
> Interceptors and the Action. The interceptor chain has a method,
> doInterceptor() which does this:
>
>public String doInterceptor() throws Exception {
> if (interceptors.hasNext()) {
> Interceptor interceptor = (Interceptor) interceptors.next();
> result = interceptor.intercept(this);
> } else {
> result = action.execute();
> }
>
> return result;
> }
>
> The sub interceptors can choose to pass the call through by using the
> InterceptorChain passed in by doing interceptor.doInterceptor() again.
> My base Interceptor implementation does this:
>
> public String intercept(InterceptorChain chain) throws Exception {
> before(chain);
>
> String result = chain.doInterceptor();
> after(chain);
>
> return result;
> }
>
> Which allows subclasses to put code before and after the rest of the
> processing.
>
> What happens in GenericDispatcher is this (replacing the direct
> execute() of the action):
>
> List interceptors = actionConfig.getInterceptors();
> InterceptorChain interceptorChain = new InterceptorChain(action,
> interceptors);
> result = interceptorChain.doInterceptor();
>
>
> Anyway, that's what I've been working on... Thoughts?
>
> Jason
>
> > -Original Message-
> > From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, January 09, 2003 10:24 AM
> > To: os-ww
> > Subject: [OS-webwork] XWork Interceptors
> >
> >
> > So anyway, I'm just going to disregard the "Documentation"
> > thread and start a thread that is actually useful :)
> >
> > (Though, Ken, we're still hoping your willing to do some Doc work!)
> >
> > So besides Action Chaining, Rickard made a good point that
> > interceptors is very important as well. I'd like to talk
> > about the actual implementation now -- using the transaction
> > scenario as an example.
> >
> > How will the interceptor know when to rollback or commit? Of
> > course on an Exception it should, but what about on ERROR or
> > INPUT? What if the action, to signify it's is complete, used
> > COMPLETE instead of SUCCESS? Do you see my point? How can we
> > make interceptors work for all cases? I'm guessing some sort
> > of configuration is needed for each interceptor on each
> > action, so we could do something like:
> >
> >
> > success, complete
> >
> >
> > And then the interceptot could know to rollback if the return
> > value isn't one of those two.
> >
> > Rickard, is this what you had in mind?
> >
> > Also, Interceptors would fit in to the GenericDispatcher
> > area. I think that they would replace ActionFactoryProxies
> > entirely, correct? Also, maybe Rickard you can provide some
> > sample psuedo code for an Interceptor as well as how it would
> > go about being invoked in GenericDispatcher?
> >
> > -Pat
> >
> >
> >
> >
> > ---
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something
> > 2 See! http://www.vasoftware.com
> > ___
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
>
>
> ---
> This SF.NET email is sp
[OS-webwork] Strange classloader lockups
Not sure if this is really a WebWork problem (the stack traces in the file attached all show WW stuff, but they aren't locking there), but I'm getting lockups in Orion. Basically, it appears that the orion classloader is being locked on to and never let go (though I could't figure out why that is). Anyone have any thoughts? :) -Pat Full thread dump Java HotSpot(TM) Server VM (1.4.1_01-b01 mixed mode): "ApplicationServerThread" prio=5 tid=0x2ff518 nid=0x49 waiting for monitor entry [eea8..eea8199c] at java.lang.ClassLoader.loadClass(ClassLoader.java:288) - waiting to lock (a com.evermind._kn) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at webwork.action.factory.JavaActionFactory.getActionImpl(JavaActionFactory.java:53) at webwork.action.factory.ScriptActionFactoryProxy.getActionImpl(ScriptActionFactoryProxy.java:54) at webwork.action.factory.XMLActionFactoryProxy.getActionImpl(XMLActionFactoryProxy.java:56) at webwork.action.factory.PrefixActionFactoryProxy.getActionImpl(PrefixActionFactoryProxy.java:86) at webwork.action.factory.JspActionFactoryProxy.getActionImpl(JspActionFactoryProxy.java:53) at webwork.action.factory.CommandActionFactoryProxy.getActionImpl(CommandActionFactoryProxy.java:62) at webwork.action.factory.AliasingActionFactoryProxy.getActionImpl(AliasingActionFactoryProxy.java:96) at webwork.action.factory.CommandActionFactoryProxy.getActionImpl(CommandActionFactoryProxy.java:62) at webwork.action.factory.ContextActionFactoryProxy.getActionImpl(ContextActionFactoryProxy.java:36) at webwork.action.factory.PrepareActionFactoryProxy.getActionImpl(PrepareActionFactoryProxy.java:37) at webwork.action.factory.ParametersActionFactoryProxy.getActionImpl(ParametersActionFactoryProxy.java:46) at webwork.action.factory.ChainingActionFactoryProxy.getActionImpl(ChainingActionFactoryProxy.java:44) at webwork.action.factory.DefaultActionFactory.getActionImpl(DefaultActionFactory.java:92) at webwork.action.factory.ActionFactory.getAction(ActionFactory.java:62) at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:101) at webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:161) at javax.servlet.http.HttpServlet.service(HttpServlet.java:336) at com.evermind._ie.doFilter(.:59) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(Unknown Source) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(Unknown Source) at com.evermind._ic.doFilter(.:16) at com.cisco.paws.security.LoginFilter.doFilter(LoginFilter.java:120) at com.evermind._deb._lnc(.:376) at com.evermind._deb._wmb(.:170) at com.evermind._co._wbb(.:581) at com.evermind._co._fs(.:189) at com.evermind._bt.run(.:62) - locked (a com.evermind.server.ApplicationServerThread) "ApplicationServerThread" prio=5 tid=0x3d70d8 nid=0x48 waiting for monitor entry [eeb8..eeb8199c] at java.lang.ClassLoader.loadClass(ClassLoader.java:288) - waiting to lock (a com.evermind._kn) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at webwork.action.factory.JavaActionFactory.getActionImpl(JavaActionFactory.java:53) at webwork.action.factory.ScriptActionFactoryProxy.getActionImpl(ScriptActionFactoryProxy.java:54) at webwork.action.factory.XMLActionFactoryProxy.getActionImpl(XMLActionFactoryProxy.java:56) at webwork.action.factory.PrefixActionFactoryProxy.getActionImpl(PrefixActionFactoryProxy.java:86) at webwork.action.factory.JspActionFactoryProxy.getActionImpl(JspActionFactoryProxy.java:53) at webwork.action.factory.CommandActionFactoryProxy.getActionImpl(CommandActionFactoryProxy.java:62) at webwork.action.factory.AliasingActionFactoryProxy.getActionImpl(AliasingActionFactoryProxy.java:96) at webwork.action.factory.CommandActionFactoryProxy.getActionImpl(CommandActionFactoryProxy.java:62) at webwork.action.factory.ContextActionFactoryProxy.getActionImpl(ContextActionFactoryProxy.java:36) at webwork.action.factory.PrepareActionFactoryProxy.getActionImpl(PrepareActionFactoryProxy.java:37) at webwork.action.factory.ParametersActionFactoryProxy.getActionImpl(ParametersActionFactoryProxy.java:46) at webwork.action.factory.ChainingActionFactoryProxy.getActionImpl(ChainingActionFactoryProxy.java:44) at webwork.action.factory.DefaultActionFactory.getActionImpl(DefaultActionFactory.java:92) at webwork.action.factory.ActionFactory.getAction(ActionFactory.java:62) at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:101) at webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:161) at javax.servlet.http.HttpServlet.service(H
Re: [OS-webwork] Enhancements to Jasper Reports
I haven't started using it yet, but I will be soon enough. I can't wait either. Looks cool. Blake > Not yet - but I'm itching to learn how to do it :) > > Cheers, > Mike > > On 9/1/03 4:48 PM, "Peter Kelley" ([EMAIL PROTECTED]) penned the > words: > >> I've postulated a few changes to the Jasper Reports view code at >> >> http://www.opensymphony.com:8668/space/JasperReports+View >> >> In short I want to add some more view types (CSV, XML, XLS) and also >> allow full expression language access for Jasper Report fields. I plan >> to maintain full backward compatibility. >> >> Is anyone other than us using this ? >> >> Anyway if you want to comment please do so either here or in wiki. > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork -- Michael Blake Day Artistry Studios mobile: 770.480.1547 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Inclusion of a webwork call invoked by JSTL
I have a web page coded as a JSP and utilizing JSTL tags. On this page, I have a dynamic report that is generated by a webwork call. I am using the tag to reference the webwork action, and it is mapped to a JSP view for rendering. Time for a visual? index.jsp +--+ | | | | | | | +--+ | | | | | | | |<-- report.action (mapped to a view called report.jsp) | | | | invoked by using JSTL | +--+ | | | | | | | | | +--+ The invokes the webwork action and the view is returned, however the view is returned as a String! It is not parsed by the JSP engine, so the callbacks to the ValueStack never occur. I have also tried the tag, but it does not render the included JSP either. Perhaps there is a webwork tag to handle this? I would prefer a pure JSTL solution, but at this point, I am open. :) What is the best way to handle this simplified problem? --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Inclusion of a webwork call invoked by JSTL
Quick clarification... > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of James Cook > Sent: Thursday, January 09, 2003 9:18 PM > The invokes the webwork action and the view is > returned, however the view is returned as a String! It is not > parsed by the JSP engine, so the callbacks to the ValueStack > never occur. The resulting JSP page _is_ parsed by the JSP engine. It just can't seem to get any information off the ValueStack. Is this a case where the ../ is needed? If so, I guess I can't use the elegant JSTL library then. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Enhancements to Jasper Reports
On Thu, 2003-01-09 at 18:19, Patrick Lightbody wrote: > Pardon me for my ignorance... but could you possibly provide a high level > detail of what Jasper Reports is, specifically how it integrates in with WW? > > -Pat > Jasper Reports is an open source reporting tool that allows the creation of pretty reports from a given data source. The best known commercial product that performs the same function would be Crystal Reports. The way Jasper works is to take a compiled XML report definition and a data source and produce a report in one of a number of formats including PDF, XML, CSV, XLS and HTML. The webwork integration provides a dispatcher servlet that uses the value stack as a Jasper Reports data source to "fill" a Jasper Report with data and produce a PDF which is then sent back in the HTTP response. The Jasper reports code is quite small and, in IMHO, shows off the power of webwork to allow the addition of views so easily. -- Peter Kelley <[EMAIL PROTECTED]> Moveit Pty Ltd --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
