You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2006/06/01 01:48:07 UTC
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Argh... just so no one thinks I forgot about this... I've had to work
from home all this week for various unforeseen reasons, and of course as
a pessimist like myself would expect, the mostly working code got lost
since this weekend. Thought there was a copy on my thumb drive, but of
course not, copy on PC was since squashed, etc. Typical Murphy's Law.
I believe there is an older version sitting on my work PC, so as soon as
I get back there (which doesn't look to be tomorrow either), I can get
it and figure out what I had fixed subsequent to that. Argh I say,
ARGH! That just reminds me to set up SVN on my new home server this
weekend!
And Jason, I get what you wrote here about the Result, I was planning on
refactoring to that before this little setback :) I don't think it
would have been a problem per se to render the response in an
Interceptor, that seemed like it was going to work, but it did present
the problem of mixing and matching XML/JSON as we were discussing, so
for that reason alone it would seem to make sense. Thanks for the info
on that!
Frank
Jason Carreira wrote:
>> Ted and Jason, I did see your messages about
>> AroundInterceptor and
>> Result correspondingly... right now, in the interest
>> of simply getting
>> it working, I'm just doing a simple AroundInterceptor
>> using before() and
>> after(), one interceptor for XML and one for JSON
>> (although as I just
>> wrote that it dawned on me that that probably won't
>> work because mixing
>> XML and JSON probably won't work... might have to
>> combine them and allow
>> configuration... I'll see...)
>>
>> I read up on Restults a bit yesterday, and I can
>> certainly see why you'd
>> say that Jason... this still feels to me like
>> something that should
>> really be just an interceptor though... but, the code
>> is at this point
>> generic enough that moving it or putting it in a
>> different form
>> shouldn't be a big deal, so that can be decided
>> later... lemme just get
>> it all working first :)
>>
>> Frank
>>
>
>
> The problem you're having composing the JSON and XML is because the output should be a result. Interceptors don't produce content, that's orthogonal to their usage. Results are all about generating output. What would happen if I configured an Action with the JSON interceptor to read the incoming request and produce output, but also configured the action to have a JSP page as the Result? They can't BOTH write to the output stream.
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=32216&messageID=63313#63313
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Posted by Ted Husted <te...@gmail.com>.
For patches to existing classes, we do operate on the premise that
there's an implicit grant, but when people start donating entire
classes, we like to have an explicit licensing agreement on file.
-Ted.
On 6/5/06, Alexandru Popescu <th...@gmail.com> wrote:
> This looks weird, because as far as I knew contributions submitted
> through JIRA are already granting the copyright if not otherwise
> expressed.
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
> On 6/5/06, Ted Husted <te...@gmail.com> wrote:
> > Since this donation includes standalone classes, we should ask Frank
> > to file a CLA to cover this donation and any others.
> >
> > * http://www.apache.org/licenses/icla.txt
> >
> > I don't think we need to wait for it to go on file before accepting
> > the donation, but Frank should confirm that he is willing and able to
> > file a ICLA, and then let us know when he has faxed it in.
> >
> > -Ted.
> >
> > On 6/5/06, Ian Roughley <ia...@fdar.com> wrote:
> > > Frank -
> > >
> > > Thanks again for all the work you've done on this front! Email the code
> > > to me at ian@fdar.com. I'll take a look over it and commit it to the
> > > saf project. If there are some interesting classes, you might want to
> > > add them to the JIRA issuse for discussion
> > >
> > > /Ian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Posted by Alexandru Popescu <th...@gmail.com>.
This looks weird, because as far as I knew contributions submitted
through JIRA are already granting the copyright if not otherwise
expressed.
./alex
--
.w( the_mindstorm )p.
On 6/5/06, Ted Husted <te...@gmail.com> wrote:
> Since this donation includes standalone classes, we should ask Frank
> to file a CLA to cover this donation and any others.
>
> * http://www.apache.org/licenses/icla.txt
>
> I don't think we need to wait for it to go on file before accepting
> the donation, but Frank should confirm that he is willing and able to
> file a ICLA, and then let us know when he has faxed it in.
>
> -Ted.
>
> On 6/5/06, Ian Roughley <ia...@fdar.com> wrote:
> > Frank -
> >
> > Thanks again for all the work you've done on this front! Email the code
> > to me at ian@fdar.com. I'll take a look over it and commit it to the
> > saf project. If there are some interesting classes, you might want to
> > add them to the JIRA issuse for discussion
> >
> > /Ian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Thanks Ted, I just faxed it over a minute ago... I just hope whoever looks
at it can read my handwriting, I have *seriously* atrocious penmanship!
It still needs to be sent in, correct?
Frank
On Mon, June 5, 2006 1:20 pm, Ted Husted wrote:
> Since this donation includes standalone classes, we should ask Frank
> to file a CLA to cover this donation and any others.
>
> * http://www.apache.org/licenses/icla.txt
>
> I don't think we need to wait for it to go on file before accepting
> the donation, but Frank should confirm that he is willing and able to
> file a ICLA, and then let us know when he has faxed it in.
>
> -Ted.
>
> On 6/5/06, Ian Roughley <ia...@fdar.com> wrote:
>> Frank -
>>
>> Thanks again for all the work you've done on this front! Email the code
>> to me at ian@fdar.com. I'll take a look over it and commit it to the
>> saf project. If there are some interesting classes, you might want to
>> add them to the JIRA issuse for discussion
>>
>> /Ian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Posted by Ted Husted <te...@gmail.com>.
Since this donation includes standalone classes, we should ask Frank
to file a CLA to cover this donation and any others.
* http://www.apache.org/licenses/icla.txt
I don't think we need to wait for it to go on file before accepting
the donation, but Frank should confirm that he is willing and able to
file a ICLA, and then let us know when he has faxed it in.
-Ted.
On 6/5/06, Ian Roughley <ia...@fdar.com> wrote:
> Frank -
>
> Thanks again for all the work you've done on this front! Email the code
> to me at ian@fdar.com. I'll take a look over it and commit it to the
> saf project. If there are some interesting classes, you might want to
> add them to the JIRA issuse for discussion
>
> /Ian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Hi Ian,
Your very welcome! It was fun working on it, learned quite a bit about WW
in the process... I opened a JIRA ticket that includes everything:
http://issues.apache.org/struts/browse/WW-1330
It has a link to a complete webapp demonstrating it (too big to attach to
the ticket I thought), but the new code to commit *is* included on the
ticket. The comments on the ticket is just a copy of the javadoc overview
by the way (I always try and document my work as best I can) and it pretty
well describes it all.
FYI, I wrote it against WW 2.2.2, and the package structure is based on
that as well. I added a new package, c.o.w.result. I wasn't 100% sure
what the SAF2 package structure was, that's why I went with the existing
WW structure. Feel free to not add that result package if you think there
is an existing package for the results, I just thought it might be a good
idea going forward should there be other new result types to add.
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
On Mon, June 5, 2006 10:01 am, Ian Roughley wrote:
> Frank -
>
> Thanks again for all the work you've done on this front! Email the code
> to me at ian@fdar.com. I'll take a look over it and commit it to the
> saf project. If there are some interesting classes, you might want to
> add them to the JIRA issuse for discussion
>
> /Ian
>
>
> Frank W. Zammetti wrote:
>> FYI, for anyone that's interested and been following this discussion,
>> I finally got this all working, just need a few hours tomorrow night
>> to do some final polishing and documentation (not that it'll be
>> perfect out of the gate anyway, but I'd like to get as close as
>> possible).
>>
>> In short, there is a total of seven new classes, 2 Interceptors
>> (AjaxXMLInterceptor and AjaxJSONInterceptor, implementing Interceptor,
>> not AroundInterceptor as I was originally doing), 2 Results
>> (AjaxXMLResult and AjaxJSONResult), 2 marker interfaces (AjaxXMLAware
>> and AjaxJSONAware) and a helper class that the Interceptors both use
>> (AjaxInterceptorHelper). There is also a new dependency introduced,
>> JSON-RPC-Java (http://oss.metaparadigm.com/jsonrpc/) which is used for
>> serializing an Action to JSON (v1.0, which I used, is licensed under
>> ASF 2.0, so shouldn't be a problem there). Technically there is a
>> dependency on the Java classes from json.org as well, but they are
>> included in the JSON-RPC-Java JAR. The classes are currently in the
>> com.opensymphony.webwork.interceptor and
>> com.opensymphony.webwork.result (new) package, I figured they could be
>> moved to the correct SAF2 packages easy enough.
>>
>> I also have a complete WW 2.2.2 sample app built to test this all.
>> It's a simple demonstration of constructing JSON or XML on the client
>> from form entries, sending it to the server, the Action getting
>> populated from that message, and then a response coming back in JSON
>> or XML constructed from the Action's fields. No mapping files
>> required, no extra code in the Action (other than implementing one, or
>> both, of the new marker interfaces), just a modified Interceptor stack
>> and using the new Results.
>>
>> I presume posting this to JIRA is the appropriate route? But, if I
>> upload everything to it, the sample app and all, it's almost 8 megs...
>> better to just post the new code and link to the sample app on my
>> server I assume?
>>
>> Frank
>>
>> Frank W. Zammetti wrote:
>>> Argh... just so no one thinks I forgot about this... I've had to work
>>> from home all this week for various unforeseen reasons, and of course
>>> as a pessimist like myself would expect, the mostly working code got
>>> lost since this weekend. Thought there was a copy on my thumb drive,
>>> but of course not, copy on PC was since squashed, etc. Typical
>>> Murphy's Law.
>>>
>>> I believe there is an older version sitting on my work PC, so as soon
>>> as I get back there (which doesn't look to be tomorrow either), I can
>>> get it and figure out what I had fixed subsequent to that. Argh I
>>> say, ARGH! That just reminds me to set up SVN on my new home server
>>> this weekend!
>>>
>>> And Jason, I get what you wrote here about the Result, I was planning
>>> on refactoring to that before this little setback :) I don't think
>>> it would have been a problem per se to render the response in an
>>> Interceptor, that seemed like it was going to work, but it did
>>> present the problem of mixing and matching XML/JSON as we were
>>> discussing, so for that reason alone it would seem to make sense.
>>> Thanks for the info on that!
>>>
>>> Frank
>>>
>>> Jason Carreira wrote:
>>>>> Ted and Jason, I did see your messages about
>>>>> AroundInterceptor and Result correspondingly... right now, in the
>>>>> interest
>>>>> of simply getting it working, I'm just doing a simple
>>>>> AroundInterceptor
>>>>> using before() and after(), one interceptor for XML and one for JSON
>>>>> (although as I just wrote that it dawned on me that that probably
>>>>> won't
>>>>> work because mixing XML and JSON probably won't work... might have to
>>>>> combine them and allow configuration... I'll see...)
>>>>>
>>>>> I read up on Restults a bit yesterday, and I can
>>>>> certainly see why you'd say that Jason... this still feels to me like
>>>>> something that should really be just an interceptor though... but,
>>>>> the code
>>>>> is at this point generic enough that moving it or putting it in a
>>>>> different form shouldn't be a big deal, so that can be decided
>>>>> later... lemme just get it all working first :)
>>>>>
>>>>> Frank
>>>>>
>>>>
>>>>
>>>> The problem you're having composing the JSON and XML is because the
>>>> output should be a result. Interceptors don't produce content,
>>>> that's orthogonal to their usage. Results are all about generating
>>>> output. What would happen if I configured an Action with the JSON
>>>> interceptor to read the incoming request and produce output, but
>>>> also configured the action to have a JSP page as the Result? They
>>>> can't BOTH write to the output stream.
>>>> ---------------------------------------------------------------------
>>>> Posted via Jive Forums
>>>> http://forums.opensymphony.com/thread.jspa?threadID=32216&messageID=63313#63313
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Posted by Ian Roughley <ia...@fdar.com>.
Frank -
Thanks again for all the work you've done on this front! Email the code
to me at ian@fdar.com. I'll take a look over it and commit it to the
saf project. If there are some interesting classes, you might want to
add them to the JIRA issuse for discussion
/Ian
Frank W. Zammetti wrote:
> FYI, for anyone that's interested and been following this discussion,
> I finally got this all working, just need a few hours tomorrow night
> to do some final polishing and documentation (not that it'll be
> perfect out of the gate anyway, but I'd like to get as close as
> possible).
>
> In short, there is a total of seven new classes, 2 Interceptors
> (AjaxXMLInterceptor and AjaxJSONInterceptor, implementing Interceptor,
> not AroundInterceptor as I was originally doing), 2 Results
> (AjaxXMLResult and AjaxJSONResult), 2 marker interfaces (AjaxXMLAware
> and AjaxJSONAware) and a helper class that the Interceptors both use
> (AjaxInterceptorHelper). There is also a new dependency introduced,
> JSON-RPC-Java (http://oss.metaparadigm.com/jsonrpc/) which is used for
> serializing an Action to JSON (v1.0, which I used, is licensed under
> ASF 2.0, so shouldn't be a problem there). Technically there is a
> dependency on the Java classes from json.org as well, but they are
> included in the JSON-RPC-Java JAR. The classes are currently in the
> com.opensymphony.webwork.interceptor and
> com.opensymphony.webwork.result (new) package, I figured they could be
> moved to the correct SAF2 packages easy enough.
>
> I also have a complete WW 2.2.2 sample app built to test this all.
> It's a simple demonstration of constructing JSON or XML on the client
> from form entries, sending it to the server, the Action getting
> populated from that message, and then a response coming back in JSON
> or XML constructed from the Action's fields. No mapping files
> required, no extra code in the Action (other than implementing one, or
> both, of the new marker interfaces), just a modified Interceptor stack
> and using the new Results.
>
> I presume posting this to JIRA is the appropriate route? But, if I
> upload everything to it, the sample app and all, it's almost 8 megs...
> better to just post the new code and link to the sample app on my
> server I assume?
>
> Frank
>
> Frank W. Zammetti wrote:
>> Argh... just so no one thinks I forgot about this... I've had to work
>> from home all this week for various unforeseen reasons, and of course
>> as a pessimist like myself would expect, the mostly working code got
>> lost since this weekend. Thought there was a copy on my thumb drive,
>> but of course not, copy on PC was since squashed, etc. Typical
>> Murphy's Law.
>>
>> I believe there is an older version sitting on my work PC, so as soon
>> as I get back there (which doesn't look to be tomorrow either), I can
>> get it and figure out what I had fixed subsequent to that. Argh I
>> say, ARGH! That just reminds me to set up SVN on my new home server
>> this weekend!
>>
>> And Jason, I get what you wrote here about the Result, I was planning
>> on refactoring to that before this little setback :) I don't think
>> it would have been a problem per se to render the response in an
>> Interceptor, that seemed like it was going to work, but it did
>> present the problem of mixing and matching XML/JSON as we were
>> discussing, so for that reason alone it would seem to make sense.
>> Thanks for the info on that!
>>
>> Frank
>>
>> Jason Carreira wrote:
>>>> Ted and Jason, I did see your messages about
>>>> AroundInterceptor and Result correspondingly... right now, in the
>>>> interest
>>>> of simply getting it working, I'm just doing a simple
>>>> AroundInterceptor
>>>> using before() and after(), one interceptor for XML and one for JSON
>>>> (although as I just wrote that it dawned on me that that probably
>>>> won't
>>>> work because mixing XML and JSON probably won't work... might have to
>>>> combine them and allow configuration... I'll see...)
>>>>
>>>> I read up on Restults a bit yesterday, and I can
>>>> certainly see why you'd say that Jason... this still feels to me like
>>>> something that should really be just an interceptor though... but,
>>>> the code
>>>> is at this point generic enough that moving it or putting it in a
>>>> different form shouldn't be a big deal, so that can be decided
>>>> later... lemme just get it all working first :)
>>>>
>>>> Frank
>>>>
>>>
>>>
>>> The problem you're having composing the JSON and XML is because the
>>> output should be a result. Interceptors don't produce content,
>>> that's orthogonal to their usage. Results are all about generating
>>> output. What would happen if I configured an Action with the JSON
>>> interceptor to read the incoming request and produce output, but
>>> also configured the action to have a JSP page as the Result? They
>>> can't BOTH write to the output stream.
>>> ---------------------------------------------------------------------
>>> Posted via Jive Forums
>>> http://forums.opensymphony.com/thread.jspa?threadID=32216&messageID=63313#63313
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
FYI, for anyone that's interested and been following this discussion, I
finally got this all working, just need a few hours tomorrow night to do
some final polishing and documentation (not that it'll be perfect out of
the gate anyway, but I'd like to get as close as possible).
In short, there is a total of seven new classes, 2 Interceptors
(AjaxXMLInterceptor and AjaxJSONInterceptor, implementing Interceptor,
not AroundInterceptor as I was originally doing), 2 Results
(AjaxXMLResult and AjaxJSONResult), 2 marker interfaces (AjaxXMLAware
and AjaxJSONAware) and a helper class that the Interceptors both use
(AjaxInterceptorHelper). There is also a new dependency introduced,
JSON-RPC-Java (http://oss.metaparadigm.com/jsonrpc/) which is used for
serializing an Action to JSON (v1.0, which I used, is licensed under ASF
2.0, so shouldn't be a problem there). Technically there is a
dependency on the Java classes from json.org as well, but they are
included in the JSON-RPC-Java JAR. The classes are currently in the
com.opensymphony.webwork.interceptor and com.opensymphony.webwork.result
(new) package, I figured they could be moved to the correct SAF2
packages easy enough.
I also have a complete WW 2.2.2 sample app built to test this all. It's
a simple demonstration of constructing JSON or XML on the client from
form entries, sending it to the server, the Action getting populated
from that message, and then a response coming back in JSON or XML
constructed from the Action's fields. No mapping files required, no
extra code in the Action (other than implementing one, or both, of the
new marker interfaces), just a modified Interceptor stack and using the
new Results.
I presume posting this to JIRA is the appropriate route? But, if I
upload everything to it, the sample app and all, it's almost 8 megs...
better to just post the new code and link to the sample app on my server
I assume?
Frank
Frank W. Zammetti wrote:
> Argh... just so no one thinks I forgot about this... I've had to work
> from home all this week for various unforeseen reasons, and of course as
> a pessimist like myself would expect, the mostly working code got lost
> since this weekend. Thought there was a copy on my thumb drive, but of
> course not, copy on PC was since squashed, etc. Typical Murphy's Law.
>
> I believe there is an older version sitting on my work PC, so as soon as
> I get back there (which doesn't look to be tomorrow either), I can get
> it and figure out what I had fixed subsequent to that. Argh I say,
> ARGH! That just reminds me to set up SVN on my new home server this
> weekend!
>
> And Jason, I get what you wrote here about the Result, I was planning on
> refactoring to that before this little setback :) I don't think it
> would have been a problem per se to render the response in an
> Interceptor, that seemed like it was going to work, but it did present
> the problem of mixing and matching XML/JSON as we were discussing, so
> for that reason alone it would seem to make sense. Thanks for the info
> on that!
>
> Frank
>
> Jason Carreira wrote:
>>> Ted and Jason, I did see your messages about
>>> AroundInterceptor and Result correspondingly... right now, in the
>>> interest
>>> of simply getting it working, I'm just doing a simple AroundInterceptor
>>> using before() and after(), one interceptor for XML and one for JSON
>>> (although as I just wrote that it dawned on me that that probably won't
>>> work because mixing XML and JSON probably won't work... might have to
>>> combine them and allow configuration... I'll see...)
>>>
>>> I read up on Restults a bit yesterday, and I can
>>> certainly see why you'd say that Jason... this still feels to me like
>>> something that should really be just an interceptor though... but,
>>> the code
>>> is at this point generic enough that moving it or putting it in a
>>> different form shouldn't be a big deal, so that can be decided
>>> later... lemme just get it all working first :)
>>>
>>> Frank
>>>
>>
>>
>> The problem you're having composing the JSON and XML is because the
>> output should be a result. Interceptors don't produce content, that's
>> orthogonal to their usage. Results are all about generating output.
>> What would happen if I configured an Action with the JSON interceptor
>> to read the incoming request and produce output, but also configured
>> the action to have a JSP page as the Result? They can't BOTH write to
>> the output stream.
>> ---------------------------------------------------------------------
>> Posted via Jive Forums
>> http://forums.opensymphony.com/thread.jspa?threadID=32216&messageID=63313#63313
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org