RE: struts-workflow (Re: OT: Struts JSR?)

[shirishchandra.sakhare]

>>1:There is no overlap as there does not seem to be any development 
>>going on about WorkFlow area in struts.

>I think you are correct; people seem to be gravitating to struts-workflow.

This makes my life easier now that I know there is no overlap.

>I'm not sure which of the above you'd like to resolve to make more 
>planning.  I think (1) is a non-issue; (2) should be deferred until 
>someone has a use-case for it, and (3) -- well, we're going to work 
>on moving the commons-chain based request processor into the Struts 
>core shortly after we deal with migrating Struts to a TLP.  But it 
>works enough right now that you could probably begin exploring using 
>it for Struts-Workflow.


My main confusion was about planning for next major release as it has to be inline 
with Struts API.
So it looks like commons-chain based request processor is the way to go.

I will start work on it as soon as I am finished with migration of the 
workflow-extension to source forge.

>I'm interested in both chain and workflow, 
>so you might be able to con me into helping out a little bit 8^)

Joe, if you are interested you are more than welcome to join.Any helping hands are 
more than welcome, especially since I have been tied with my current project for last 
couple of months and have not been able to move forward the way I would have liked to.

I am in the process of deciding the roadmap/any missing features/enhancements.
One of the ideas I have picked up recently on this list was  from Craig's mail (about 
continuation)

The most important feature that [workflow] includes, but is not present in
[chain], is the idea that is formally known as a "continuation" -- you can
describe a single flow of commands that (if you're building a webapp) requires
more than one HTTP interaction with the client. 


So if we can extend the workflow extension to provide support to really define 
reusable workflows(or continuations) which can be used like actionForwards 
from struts actions, that will make the package really complete.

Shirish.

-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 3:41 PM
To: Struts Developers List
Subject: struts-workflow (Re: OT: Struts JSR?)


>1:There is no overlap as there does not seem to be any development 
>going on about WorkFlow area in struts.

I think you are correct; people seem to be gravitating to struts-workflow.

>2:While brousing through struts-dev archive, I came aross many 
>threads where the topic of a workflow like concept was discussed.But 
>nobody seems to have taken this up any further,apart from a mail 
>where in craig has mentioned that he would like to implement a 
>workflow engine where the scriptign languages may be used to define 
>the workflow.he has also mentioned using jelly for the same.
>
>But for me, the struts-workflow is more like a wizard 
>implementation,not a real workflow processing engine.SO I am still 
>not clear where jelly like packages may help.But may be I am just 
>being naive.

I think it's true that in a wizard scenario, scripting is less likely 
to be needed.  Insofar as one would want to use scripting, I'd 
probably advocate for a BSF implementation rather than Jelly, so that 
people can script in any language they want.  (Well, actually, I 
don't think there's a Jelly BSF engine, but I don't think that many 
people want to script in Jelly either.)

>3:The mention of the commons chainning for integrating expernal 
>packages like workflow so that the processing can be intercepted at 
>perticular points and customised.This soundds very interesting 
>concept and very suitable for the workflow requirement.I have not 
>invested much time into this perticular aspect but plan to do so.And 
>I also have a feeling that the future direction for the workflow 
>extension shuld be to move towards the usage of the commons 
>chainning package.

I haven't come up to speed on struts-workflow, although I've been 
wanting to for a while.  I remember that Matthias was one of the 
people who really wanted to see a composable request processing 
chain, since right now Struts-Workflow has to extend 
RequestProcessor.  It seems likely that the fit will be pretty 
natural.

>So this leaves me where I started.Very unclear about the direction 
>the struts is going to take in this regard.And very unclear about 
>how to plan the next major enhancement for the extension.

I'm not sure which of the above you'd like to resolve to make more 
planning.  I think (1) is a non-issue; (2) should be deferred until 
someone has a use-case for it, and (3) -- well, we're going to work 
on moving the commons-chain based request processor into the Struts 
core shortly after we deal with migrating Struts to a TLP.  But it 
works enough right now

RE: OT: Struts JSR?

[Paananen, Tero]

> > First let's be very clear. 
> > 
> > It's *not* about "market share". 
> 
> I have to disagree with you on this one. Struts is
> the defacto standard because of its market share.

Why does Struts need to be defacto standard?
Struts in itself has no value, IMHO.

Obviously Struts developers have an emotional
investment on Struts, but application developers,
such as myself, don't care which framework we
use as long as it works. If something better than
Struts comes along, I'll switch regardless of
market share or standards.

You guys do not need to worry about market share,
just about making Struts the best framework
available. If you build it, they will come.

-TPP

-
This email may contain confidential and privileged material for the sole use of the 
intended recipient(s). Any review, use, retention, distribution or disclosure by 
others is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete all 
copies of this message.  Also, email is susceptible to data corruption, interception, 
tampering, unauthorized amendment and viruses. We only send and receive emails on the 
basis that we are not liable for any such corruption, interception, tampering, 
amendment or viruses or any consequence thereof.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

struts-workflow (Re: OT: Struts JSR?)

[Joe Germuska]

1:There is no overlap as there does not seem to be any development 
going on about WorkFlow area in struts.
I think you are correct; people seem to be gravitating to struts-workflow.

2:While brousing through struts-dev archive, I came aross many 
threads where the topic of a workflow like concept was discussed.But 
nobody seems to have taken this up any further,apart from a mail 
where in craig has mentioned that he would like to implement a 
workflow engine where the scriptign languages may be used to define 
the workflow.he has also mentioned using jelly for the same.

But for me, the struts-workflow is more like a wizard 
implementation,not a real workflow processing engine.SO I am still 
not clear where jelly like packages may help.But may be I am just 
being naive.
I think it's true that in a wizard scenario, scripting is less likely 
to be needed.  Insofar as one would want to use scripting, I'd 
probably advocate for a BSF implementation rather than Jelly, so that 
people can script in any language they want.  (Well, actually, I 
don't think there's a Jelly BSF engine, but I don't think that many 
people want to script in Jelly either.)

3:The mention of the commons chainning for integrating expernal 
packages like workflow so that the processing can be intercepted at 
perticular points and customised.This soundds very interesting 
concept and very suitable for the workflow requirement.I have not 
invested much time into this perticular aspect but plan to do so.And 
I also have a feeling that the future direction for the workflow 
extension shuld be to move towards the usage of the commons 
chainning package.
I haven't come up to speed on struts-workflow, although I've been 
wanting to for a while.  I remember that Matthias was one of the 
people who really wanted to see a composable request processing 
chain, since right now Struts-Workflow has to extend 
RequestProcessor.  It seems likely that the fit will be pretty 
natural.

So this leaves me where I started.Very unclear about the direction 
the struts is going to take in this regard.And very unclear about 
how to plan the next major enhancement for the extension.
I'm not sure which of the above you'd like to resolve to make more 
planning.  I think (1) is a non-issue; (2) should be deferred until 
someone has a use-case for it, and (3) -- well, we're going to work 
on moving the commons-chain based request processor into the Struts 
core shortly after we deal with migrating Struts to a TLP.  But it 
works enough right now that you could probably begin exploring using 
it for Struts-Workflow.  I'm interested in both chain and workflow, 
so you might be able to con me into helping out a little bit 8^)

Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
  "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
-- Jef Raskin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?(struts-workflow)

[shirishchandra.sakhare]

Hello Ted,

I am working with the struts workflow for sometime now and have taken up the 
responsibility of porting it to sourceforge as the lead commiter(Matthias bauer)has 
moved on to some other area of development.

So this makes me perticularly interested in this topic.

Like you said,"The thing about open source is this: You don't have to wish -- *you* 
can make it so. "

That is one of major reasons why I took up this responsibility.The Workflow extension 
does a very good job of filling in the void in struts in this perticular area.But also 
we found out that it did not satisfy some requirements,sepecially the APIs leave much 
desired in terms of extendibility.

The issue that has been bogging me down for sometime now is what should be the future 
course of action if the extension has to continue to evolve, just like struts.The 
first task that I have planned is to keep the current framework the same but just 
provide more extension points in the API.

But that is very short term view.The next task can easily be to add some of the 
missing features.

But before going ahead in this direction,I also want to be sure that any direction I 
take is in line with struts APIs and also there is no overlap.And I have come to 
following conclusions.

1:There is no overlap as there does not seem to be any development going on about 
WorkFlow area in struts.The only reference I could find was to 

workflow-mapping.xml in sandbox area.

2:While brousing through struts-dev archive, I came aross many threads where the topic 
of a workflow like concept was discussed.But nobody seems to have taken this up any 
further,apart from a mail where in craig has mentioned that he would like to implement 
a workflow engine where the scriptign languages may be used to define the workflow.he 
has also mentioned using jelly for the same.

But for me, the struts-workflow is more like a wizard implementation,not a real 
workflow processing engine.SO I am still not clear where jelly like packages may 
help.But may be I am just being naive.

3:The mention of the commons chainning for integrating expernal packages like workflow 
so that the processing can be intercepted at perticular points and customised.This 
soundds very interesting concept and very suitable for the workflow requirement.I have 
not invested much time into this perticular aspect but plan to do so.And I also have a 
feeling that the future direction for the workflow extension shuld be to move towards 
the usage of the commons chainning package.

So this leaves me where I started.Very unclear about the direction the struts is going 
to take in this regard.And very unclear about how to plan the next major enhancement 
for the extension.

Any clues will be highly appreciated.

Regards,

Shirish.

 

 

 

 



So apart from making current Workflow Extension available on Sourceforge and do any 
bugfixes, 



 

 

 

-Original Message-

From: Ted Husted [mailto:[EMAIL PROTECTED]

Sent: Sunday, March 21, 2004 2:06 PM

To: Struts Developers List

Subject: Re: OT: Struts JSR?

 

I think all of these things are already on the Struts Jericho list. The exception 
being workflow integration. The Struts Workflow is OK, but I personally don't like to 
use multiple action paths for workflows. Of course, the really cool thing about the 
Struts Chain is that it makes it very easy to "integrate" packages like this into 
Struts. Struts becomes less of a framework and more a framework for writing 
frameworks. 

The other minor exception would be "Chained actions" . I doubt that any of us will 
ever recommend forwarding from one action to another to form a chain of 
responsibility. But, again, that's something that the Commons Chain can do much better 
than conventional Struts Actions ever could.

Here's my question to you: If you were a member of a development team, and someone 
handed you a list like this, what would you do first?

And, having answered the question, go ahead and do it, and post it here.

The thing about open source is this: You don't have to wish -- *you* can make it so. 

-Ted.

On Sun, 21 Mar 2004 00:22:25 -0800, Nadeem Bitar wrote:

>>

>> Such as? What kinds of innovations are you looking for, and

>> specifically what kinds of things are you seeing other frameworks

>> use that Struts could benefit from?

>>

>

> I posted this before but here is my struts 2.0 wish list again:

>

>

> * Leverage JSF and JSTL remove struts tags that have similar

> functionality. * Support for IoC. * Cleaner interfaces. * Workflow

> integration. * Chained actions * Support for portlet(JSR-168)

>

>

> nadeem bitar

>

>

> 

> - To unsubscribe, e-mail: [EMAIL PROTECTED]

> For additional commands, e-mail: [EMAIL PROTECTED]

 

 

 

---

Re: OT: Struts JSR?

[Ted Husted]

I think all of these things are already on the Struts Jericho list. The exception 
being workflow integration. The Struts Workflow is OK, but I personally don't like to 
use multiple action paths for workflows. Of course, the really cool thing about the 
Struts Chain is that it makes it very easy to "integrate" packages like this into 
Struts. Struts becomes less of a framework and more a framework for writing frameworks.

The other minor exception would be "Chained actions" . I doubt that any of us will 
ever recommend forwarding from one action to another to form a chain of 
responsibility. But, again, that's something that the Commons Chain can do much better 
than conventional Struts Actions ever could.

Here's my question to you: If you were a member of a development team, and someone 
handed you a list like this, what would you do first?

And, having answered the question, go ahead and do it, and post it here.

The thing about open source is this: You don't have to wish -- *you* can make it so.

-Ted.

On Sun, 21 Mar 2004 00:22:25 -0800, Nadeem Bitar wrote:
>>
>> Such as? What kinds of innovations are you looking for, and
>> specifically what kinds of things are you seeing other frameworks
>> use that Struts could benefit from?
>>
>
> I posted this before but here is my struts 2.0 wish list again:
>
>
> * Leverage JSF and JSTL remove struts tags that have similar
> functionality. * Support for IoC. * Cleaner interfaces. * Workflow
> integration. * Chained actions * Support for portlet(JSR-168)
>
>
> nadeem bitar
>
>
> 
> - To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?

[Nadeem Bitar]

> 
> Such as? What kinds of innovations are you looking for, and specifically
> what kinds of things are you seeing other frameworks use that Struts could
> benefit from?
> 

I posted this before but here is my struts 2.0 wish list again:

* Leverage JSF and JSTL remove struts tags that have similar
functionality. 
* Support for IoC.
* Cleaner interfaces.
* Workflow integration.
* Chained actions 
* Support for portlet(JSR-168)



nadeem bitar


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?

[Martin Cooper]

On Sat, 20 Mar 2004, Nadeem Bitar wrote:

> On Sat, 2004-03-20 at 20:41 -0800, Craig R. McClanahan wrote:
>
> > Quoting Thomas L Roche <[EMAIL PROTECTED]>:
> >
> > > David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of
> > > his remarks include
> > >
> > > - Is JSF a replacement for Struts? Yes!
> > >
> > > - JSF is a standard. Struts will never be a standard.
> > >
> > > which I believe to be pretty-nearly-direct quotes. I'm assuming he
> > > really meant
> > >
> > > + JSF 1.0 can do pretty much everything Struts 1.1 can.
> > >
> >
> > There is definitely substantial overlap, especially in the HTML tags area, as
> > well as things like outcome-based navigation handling and creating form beans.
> > The design of JavaServer Faces benefited tremendously from the experience we've
> > had with Struts, and the design in these areas exceeds the current
> > functionality of Struts in many respects.
> >
> > Two particular features of Struts that are not present in JavaServer Faces 1.0
> > -- Tiles for layout management, and the Validator Framework for creating client
> > side JavaScript to enforce the rules (in addition to enforcing them at the
> > server).  Fortunately, however, you can use these Struts features in
> > conjunction with JavaServer Faces by using the Struts-Faces integration
> > library.
> >
>
> With JSP2.0 attributes and fragments you can do advanced layout and
> templates without tiles. I am sure the validation would also be
> addressed with time.
>
>
> > There is a huge amount of momentum around Struts, and it's not going to go away
> > any time soon.  That being said, however, it's time for Struts to start doing
> > some more innovation instead of incremental improvements, in order to remain as
> > popular for new development.
> >
>
> That is my point exactly and I am hoping that struts would innovate and
> implement some of the things other frameworks use.

Such as? What kinds of innovations are you looking for, and specifically
what kinds of things are you seeing other frameworks use that Struts could
benefit from?

--
Martin Cooper


> > > + JSF is a JSR, and Struts will never be a JSR.
> > >
> > > but I'm wondering about that last statement. What prevents Struts
> > > from undergoing the JCP? Are there circumstances under which you
> > > might consider this?
> > >
> >
> > For those not familiar with it, some brief background on the JCP would be
> > useful
> > here.  More details are at the JCP web site .
> >
> > Anyone who is a JCP member can propose a JSR.  To be accepted, it would to be
> > accepted by the 16 members of the Executive Committee for the J2SE/J2EE
> > platform (note that Sun has one of these 16 votes -- people who believe that
> > Sun could "veto" a JSR proposal for something like this, even if Sun wanted to,
> > are misinformed; that veto ability only applies to language changes or "uber"
> > JSRs like the ones for the entire J2SE and J2EE platforms).  The person(s) or
> > organization(s) proposing the JSR would need to plan on (if it's accepted)
> > providing a specification documenting the Java API or technology to be
> > standardized, a Technology Compatibility Kit (TCK) against which other
> > company's implementations of the technology can be tested, and a Reference
> > Implementation (RI) -- which must pass the TCK -- proving that the technology
> > can actually be implemented.
> >
> > If by the "you" in your question you are referring to the Struts committers, we
> > could indeed propose such a JSR (Apache is a JCP member, and is currently also
> > a voting member of the Executive Committee).  But it wouldn't really be a JSR
> > to "standardize Struts" ... at most it could be a JSR to "standardize the APIs
> > supported by Struts."  After all, the JCP is really a standards organization
> > that creates specifications to be implemented by others.  Struts (and many
> > other open source projects) are often not implementations of some standard --
> > they can be seen as sort of a combination of spec and implementation rolled
> > into one.  If the long term goal is that everyone continues to use the "one and
> > only" implementation, then the JCP is not really the right development approach.
> >
> >
> > Beyond that, the Executive Committee members will tend to not desire multiple
> > JSRs with large amounts of functional overlap -- which would definitely be the
> > case if someone tried to propose the Struts APIs.  After all, these are
> > companies that would need to fund the development of their own versions of the
> > hypothetical "standard Struts", and the cost of integrating it into their own
> > products.  It is much more cost effective (as well as less confusing and costly
> > for users) to support a single standard in each technology area, and add
> > functionality in future versions as it makes sense to standardize.
> >
> > As such, it seems much more likely that the Executive Committee would accept a
> > JSR for some future version of

Re: OT: Struts JSR?

[Nadeem Bitar]

On Sat, 2004-03-20 at 20:41 -0800, Craig R. McClanahan wrote:

> Quoting Thomas L Roche <[EMAIL PROTECTED]>:
> 
> > David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of 
> > his remarks include
> > 
> > - Is JSF a replacement for Struts? Yes!
> > 
> > - JSF is a standard. Struts will never be a standard.
> > 
> > which I believe to be pretty-nearly-direct quotes. I'm assuming he
> > really meant
> > 
> > + JSF 1.0 can do pretty much everything Struts 1.1 can.
> > 
> 
> There is definitely substantial overlap, especially in the HTML tags area, as
> well as things like outcome-based navigation handling and creating form beans.
> The design of JavaServer Faces benefited tremendously from the experience we've
> had with Struts, and the design in these areas exceeds the current
> functionality of Struts in many respects.
> 
> Two particular features of Struts that are not present in JavaServer Faces 1.0
> -- Tiles for layout management, and the Validator Framework for creating client
> side JavaScript to enforce the rules (in addition to enforcing them at the
> server).  Fortunately, however, you can use these Struts features in
> conjunction with JavaServer Faces by using the Struts-Faces integration
> library.
> 

With JSP2.0 attributes and fragments you can do advanced layout and
templates without tiles. I am sure the validation would also be
addressed with time. 


> There is a huge amount of momentum around Struts, and it's not going to go away
> any time soon.  That being said, however, it's time for Struts to start doing
> some more innovation instead of incremental improvements, in order to remain as
> popular for new development.
> 

That is my point exactly and I am hoping that struts would innovate and
implement some of the things other frameworks use. 



> > + JSF is a JSR, and Struts will never be a JSR.
> > 
> > but I'm wondering about that last statement. What prevents Struts
> > from undergoing the JCP? Are there circumstances under which you
> > might consider this?
> > 
> 
> For those not familiar with it, some brief background on the JCP would be
> useful
> here.  More details are at the JCP web site .
> 
> Anyone who is a JCP member can propose a JSR.  To be accepted, it would to be 
> accepted by the 16 members of the Executive Committee for the J2SE/J2EE
> platform (note that Sun has one of these 16 votes -- people who believe that
> Sun could "veto" a JSR proposal for something like this, even if Sun wanted to,
> are misinformed; that veto ability only applies to language changes or "uber"
> JSRs like the ones for the entire J2SE and J2EE platforms).  The person(s) or
> organization(s) proposing the JSR would need to plan on (if it's accepted)
> providing a specification documenting the Java API or technology to be
> standardized, a Technology Compatibility Kit (TCK) against which other
> company's implementations of the technology can be tested, and a Reference
> Implementation (RI) -- which must pass the TCK -- proving that the technology
> can actually be implemented.
> 
> If by the "you" in your question you are referring to the Struts committers, we
> could indeed propose such a JSR (Apache is a JCP member, and is currently also
> a voting member of the Executive Committee).  But it wouldn't really be a JSR
> to "standardize Struts" ... at most it could be a JSR to "standardize the APIs
> supported by Struts."  After all, the JCP is really a standards organization
> that creates specifications to be implemented by others.  Struts (and many
> other open source projects) are often not implementations of some standard --
> they can be seen as sort of a combination of spec and implementation rolled
> into one.  If the long term goal is that everyone continues to use the "one and
> only" implementation, then the JCP is not really the right development approach.
>  
> 
> Beyond that, the Executive Committee members will tend to not desire multiple
> JSRs with large amounts of functional overlap -- which would definitely be the
> case if someone tried to propose the Struts APIs.  After all, these are
> companies that would need to fund the development of their own versions of the
> hypothetical "standard Struts", and the cost of integrating it into their own
> products.  It is much more cost effective (as well as less confusing and costly
> for users) to support a single standard in each technology area, and add
> functionality in future versions as it makes sense to standardize.
> 
> As such, it seems much more likely that the Executive Committee would accept a
> JSR for some future version of JavaServer Faces that built on top of of the 1.0
> version than a JSR for a different way to solve many of the same problems.  The
> planning for the next steps in this direction, in fact, is already in
> progress.
> 
> We as Struts developers, then, should focus on adding additional functionality
> to our "platform", to maintain and enhance its usefulness.  Not being
> co

Re: OT: Struts JSR?

[Craig R. McClanahan]

Quoting Thomas L Roche <[EMAIL PROTECTED]>:

> David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of 
> his remarks include
> 
> - Is JSF a replacement for Struts? Yes!
> 
> - JSF is a standard. Struts will never be a standard.
> 
> which I believe to be pretty-nearly-direct quotes. I'm assuming he
> really meant
> 
> + JSF 1.0 can do pretty much everything Struts 1.1 can.
> 

There is definitely substantial overlap, especially in the HTML tags area, as
well as things like outcome-based navigation handling and creating form beans.
The design of JavaServer Faces benefited tremendously from the experience we've
had with Struts, and the design in these areas exceeds the current
functionality of Struts in many respects.

Two particular features of Struts that are not present in JavaServer Faces 1.0
-- Tiles for layout management, and the Validator Framework for creating client
side JavaScript to enforce the rules (in addition to enforcing them at the
server).  Fortunately, however, you can use these Struts features in
conjunction with JavaServer Faces by using the Struts-Faces integration
library.

There is a huge amount of momentum around Struts, and it's not going to go away
any time soon.  That being said, however, it's time for Struts to start doing
some more innovation instead of incremental improvements, in order to remain as
popular for new development.

> + JSF is a JSR, and Struts will never be a JSR.
> 
> but I'm wondering about that last statement. What prevents Struts
> from undergoing the JCP? Are there circumstances under which you
> might consider this?
> 

For those not familiar with it, some brief background on the JCP would be
useful
here.  More details are at the JCP web site .

Anyone who is a JCP member can propose a JSR.  To be accepted, it would to be 
accepted by the 16 members of the Executive Committee for the J2SE/J2EE
platform (note that Sun has one of these 16 votes -- people who believe that
Sun could "veto" a JSR proposal for something like this, even if Sun wanted to,
are misinformed; that veto ability only applies to language changes or "uber"
JSRs like the ones for the entire J2SE and J2EE platforms).  The person(s) or
organization(s) proposing the JSR would need to plan on (if it's accepted)
providing a specification documenting the Java API or technology to be
standardized, a Technology Compatibility Kit (TCK) against which other
company's implementations of the technology can be tested, and a Reference
Implementation (RI) -- which must pass the TCK -- proving that the technology
can actually be implemented.

If by the "you" in your question you are referring to the Struts committers, we
could indeed propose such a JSR (Apache is a JCP member, and is currently also
a voting member of the Executive Committee).  But it wouldn't really be a JSR
to "standardize Struts" ... at most it could be a JSR to "standardize the APIs
supported by Struts."  After all, the JCP is really a standards organization
that creates specifications to be implemented by others.  Struts (and many
other open source projects) are often not implementations of some standard --
they can be seen as sort of a combination of spec and implementation rolled
into one.  If the long term goal is that everyone continues to use the "one and
only" implementation, then the JCP is not really the right development approach.
 

Beyond that, the Executive Committee members will tend to not desire multiple
JSRs with large amounts of functional overlap -- which would definitely be the
case if someone tried to propose the Struts APIs.  After all, these are
companies that would need to fund the development of their own versions of the
hypothetical "standard Struts", and the cost of integrating it into their own
products.  It is much more cost effective (as well as less confusing and costly
for users) to support a single standard in each technology area, and add
functionality in future versions as it makes sense to standardize.

As such, it seems much more likely that the Executive Committee would accept a
JSR for some future version of JavaServer Faces that built on top of of the 1.0
version than a JSR for a different way to solve many of the same problems.  The
planning for the next steps in this direction, in fact, is already in
progress.

We as Struts developers, then, should focus on adding additional functionality
to our "platform", to maintain and enhance its usefulness.  Not being
constrained by a standards process, we can proceed at a pace solely limited by
our capabilities to imagine the new things and then implement and test them.

Craig McClanahan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?

[BaTien Duong]

Martin Cooper wrote:

On Sat, 20 Mar 2004, Nadeem Bitar wrote:

 

On Sat, 2004-03-20 at 17:47 -0500, Ted Husted wrote:

   

On Fri, 19 Mar 2004 18:53:58 -0800, Nadeem Bitar wrote:
 

If for example JSF 2.0 is available, and Spring Framework is well
integrated with JSF before Struts 2.0 is available, I strongly
believe that struts won't have a place and would lose market shares.
   

First let's be very clear.

It's *not* about "market share".

 

I have to disagree with you on this one. Struts is the defacto standard
because of its market share. It is well documented, it has a healthy
community, and struts talent is available easily, because of its market
share.
   

I think what Ted is trying to say is that the Struts developers do not
work on Struts to increase its market share, but because Struts works for
us, and we care to put in the time and effort to maintain and further
develop it. The fact that it has become sufficiently popular to turn into
a de facto standard is nice, but that's secondary to (most of) us, and not
why we're here.
--
Martin Cooper
 

Yes. This has been true right from the beginning.

   

Struts does not need market-share to survive. All we need is a community of developers who use the product and want to help support it.
 

A community of developers would support a product only if they believe
in it. Many hard core struts users and developers are migrating to other
frameworks and this is a loss for the whole community. Struts 2.0 would
have a chance to bridge the gap between struts and other frameworks.
Since Struts 2.0 is still on the drawing board I am only advocating to
do it right even if that means breaking backward compatibility and
making major architecture changes.
   

You are right on the target. With the current thinking of either Struts 
1.3 or Struts 2.0, i think Struts will be a de-facto standard of web 
controller for other frameworks and contaiers.

BaTien
DBGROUPS
   

How many downloads we realize isn't important. Whether 90% or whether 10% of shipping applications use Struts isn't important. What's important is that Struts works well for the people who do want to use it, and that those people want to do the work to make it better.

Of course, if we all find that JSF does most of what we all need, and we want to use it in our own applications, then Struts will quickly become whatever other JSF components we need to ship our own applications. But so long as products like JSF leave out components that real-life applications need, there will always be a Struts. From the beginning, it's always been about providing axles between the wheels that Java already has.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.

 

Re: OT: Struts JSR?

[Michael McGrady]

This is well said, Ted.  Hopefully this resonates with the community.

At 02:47 PM 3/20/2004, you wrote:
On Fri, 19 Mar 2004 18:53:58 -0800, Nadeem Bitar wrote:
> If for example JSF 2.0 is available, and Spring Framework is well
> integrated with JSF before Struts 2.0 is available, I strongly
> believe that struts won't have a place and would lose market shares.
First let's be very clear.

It's *not* about "market share".

Struts does not need market-share to survive. All we need is a community 
of developers who use the product and want to help support it. How many 
downloads we realize isn't important. Whether 90% or whether 10% of 
shipping applications use Struts isn't important. What's important is that 
Struts works well for the people who do want to use it, and that those 
people want to do the work to make it better.

Of course, if we all find that JSF does most of what we all need, and we 
want to use it in our own applications, then Struts will quickly become 
whatever other JSF components we need to ship our own applications. But so 
long as products like JSF leave out components that real-life applications 
need, there will always be a Struts. From the beginning, it's always been 
about providing axles between the wheels that Java already has.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?

[Martin Cooper]

On Sat, 20 Mar 2004, Nadeem Bitar wrote:

> On Sat, 2004-03-20 at 17:47 -0500, Ted Husted wrote:
>
> > On Fri, 19 Mar 2004 18:53:58 -0800, Nadeem Bitar wrote:
> > > If for example JSF 2.0 is available, and Spring Framework is well
> > > integrated with JSF before Struts 2.0 is available, I strongly
> > > believe that struts won't have a place and would lose market shares.
> >
> > First let's be very clear.
> >
> > It's *not* about "market share".
> >
>
>
> I have to disagree with you on this one. Struts is the defacto standard
> because of its market share. It is well documented, it has a healthy
> community, and struts talent is available easily, because of its market
> share.

I think what Ted is trying to say is that the Struts developers do not
work on Struts to increase its market share, but because Struts works for
us, and we care to put in the time and effort to maintain and further
develop it. The fact that it has become sufficiently popular to turn into
a de facto standard is nice, but that's secondary to (most of) us, and not
why we're here.

--
Martin Cooper


>
>
> > Struts does not need market-share to survive. All we need is a community of 
> > developers who use the product and want to help support it.
>
> A community of developers would support a product only if they believe
> in it. Many hard core struts users and developers are migrating to other
> frameworks and this is a loss for the whole community. Struts 2.0 would
> have a chance to bridge the gap between struts and other frameworks.
> Since Struts 2.0 is still on the drawing board I am only advocating to
> do it right even if that means breaking backward compatibility and
> making major architecture changes.
>
>
>
>
> >  How many downloads we realize isn't important. Whether 90% or whether 10% of 
> > shipping applications use Struts isn't important. What's important is that Struts 
> > works well for the people who do want to use it, and that those people want to do 
> > the work to make it better.
> >
> > Of course, if we all find that JSF does most of what we all need, and we want to 
> > use it in our own applications, then Struts will quickly become whatever other JSF 
> > components we need to ship our own applications. But so long as products like JSF 
> > leave out components that real-life applications need, there will always be a 
> > Struts. From the beginning, it's always been about providing axles between the 
> > wheels that Java already has.
> >
> > -Ted.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?

[Nadeem Bitar]

On Sat, 2004-03-20 at 17:47 -0500, Ted Husted wrote:

> On Fri, 19 Mar 2004 18:53:58 -0800, Nadeem Bitar wrote:
> > If for example JSF 2.0 is available, and Spring Framework is well
> > integrated with JSF before Struts 2.0 is available, I strongly
> > believe that struts won't have a place and would lose market shares.
> 
> First let's be very clear. 
> 
> It's *not* about "market share". 
> 


I have to disagree with you on this one. Struts is the defacto standard
because of its market share. It is well documented, it has a healthy
community, and struts talent is available easily, because of its market
share. 


> Struts does not need market-share to survive. All we need is a community of 
> developers who use the product and want to help support it.

A community of developers would support a product only if they believe
in it. Many hard core struts users and developers are migrating to other
frameworks and this is a loss for the whole community. Struts 2.0 would
have a chance to bridge the gap between struts and other frameworks.
Since Struts 2.0 is still on the drawing board I am only advocating to
do it right even if that means breaking backward compatibility and
making major architecture changes. 




>  How many downloads we realize isn't important. Whether 90% or whether 10% of 
> shipping applications use Struts isn't important. What's important is that Struts 
> works well for the people who do want to use it, and that those people want to do 
> the work to make it better. 
> 
> Of course, if we all find that JSF does most of what we all need, and we want to use 
> it in our own applications, then Struts will quickly become whatever other JSF 
> components we need to ship our own applications. But so long as products like JSF 
> leave out components that real-life applications need, there will always be a 
> Struts. From the beginning, it's always been about providing axles between the 
> wheels that Java already has.
> 
> -Ted.
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?

[Ted Husted]

On Fri, 19 Mar 2004 18:53:58 -0800, Nadeem Bitar wrote:
> If for example JSF 2.0 is available, and Spring Framework is well
> integrated with JSF before Struts 2.0 is available, I strongly
> believe that struts won't have a place and would lose market shares.

First let's be very clear.

It's *not* about "market share".

Struts does not need market-share to survive. All we need is a community of developers 
who use the product and want to help support it. How many downloads we realize isn't 
important. Whether 90% or whether 10% of shipping applications use Struts isn't 
important. What's important is that Struts works well for the people who do want to 
use it, and that those people want to do the work to make it better.

Of course, if we all find that JSF does most of what we all need, and we want to use 
it in our own applications, then Struts will quickly become whatever other JSF 
components we need to ship our own applications. But so long as products like JSF 
leave out components that real-life applications need, there will always be a Struts. 
From the beginning, it's always been about providing axles between the wheels that 
Java already has.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?

[Vic Cekvenich]

Lets take the leads of Sun, JCP and Jakarta  at their word, for a 
second and then add my .02: If JSF is positioned as better than 
Struts (or Spring or WebWork etc.) then I personally would rather use 
other platforms entirely and I am on my way moving in that direction 
for a few months now, porting bP, etc.

.V

Nadeem Bitar wrote:
Since there is an overlap between struts and jsf, I highly doubt that
Struts would be accepted as a JSR. 

I already expressed similar concerns regarding struts being replaced by
JSF. I believe the open source community works faster than JCP and if
struts want to be remain competitive and still be considered the defacto
java web application framework, the struts developers need to address
the concerns raised with the current struts architecture and deliver the
next generation application framework that would silence struts
critiques and improve productivity of struts developers.
Struts 2.0 roadmap already have very good points but the timeframe of
the availability would be critical for the future of struts.
If for example JSF 2.0 is available, and Spring Framework is well
integrated with JSF before Struts 2.0 is available, I strongly believe
that struts won't have a place and would lose market shares. 

Spring 1.1 would offer amazing enhancement (JMX managed beans. JMS
support, Command framework, Swing support for rich clients..) and an
excellent architecture to build complex applications, combining that
with JSF component model would offer a very strong framework that's hard
to match. 

On Fri, 2004-03-19 at 21:14 -0500, Thomas L Roche wrote:


David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of 
his remarks include

- Is JSF a replacement for Struts? Yes!

- JSF is a standard. Struts will never be a standard.

which I believe to be pretty-nearly-direct quotes. I'm assuming he
really meant
+ JSF 1.0 can do pretty much everything Struts 1.1 can.

+ JSF is a JSR, and Struts will never be a JSR.

but I'm wondering about that last statement. What prevents Struts
from undergoing the JCP? Are there circumstances under which you
might consider this?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?

[Joe Germuska]

At 9:14 PM -0500 3/19/04, Thomas L Roche wrote:
but I'm wondering about that last statement. What prevents Struts
from undergoing the JCP? Are there circumstances under which you
might consider this?
There's a pretty good thread going on at [EMAIL PROTECTED] about 
whether Jakarta should use procedures more like the JCP.

http://article.gmane.org/gmane.comp.jakarta.general/6019

My conclusion is that in general, it would be extra overhead for 
little gain.  I think it's great when Apache can host reference 
implementations of JSRs, but I don't think every Apache project would 
benefit from being run like a JSR.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
  "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
-- Jef Raskin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: Struts JSR?

[Nadeem Bitar]

Since there is an overlap between struts and jsf, I highly doubt that
Struts would be accepted as a JSR. 

I already expressed similar concerns regarding struts being replaced by
JSF. I believe the open source community works faster than JCP and if
struts want to be remain competitive and still be considered the defacto
java web application framework, the struts developers need to address
the concerns raised with the current struts architecture and deliver the
next generation application framework that would silence struts
critiques and improve productivity of struts developers.

Struts 2.0 roadmap already have very good points but the timeframe of
the availability would be critical for the future of struts.

If for example JSF 2.0 is available, and Spring Framework is well
integrated with JSF before Struts 2.0 is available, I strongly believe
that struts won't have a place and would lose market shares. 

Spring 1.1 would offer amazing enhancement (JMX managed beans. JMS
support, Command framework, Swing support for rich clients..) and an
excellent architecture to build complex applications, combining that
with JSF component model would offer a very strong framework that's hard
to match. 


On Fri, 2004-03-19 at 21:14 -0500, Thomas L Roche wrote:

> David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of 
> his remarks include
> 
> - Is JSF a replacement for Struts? Yes!
> 
> - JSF is a standard. Struts will never be a standard.
> 
> which I believe to be pretty-nearly-direct quotes. I'm assuming he
> really meant
> 
> + JSF 1.0 can do pretty much everything Struts 1.1 can.
> 
> + JSF is a JSR, and Struts will never be a JSR.
> 
> but I'm wondering about that last statement. What prevents Struts
> from undergoing the JCP? Are there circumstances under which you
> might consider this?
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

OT: Struts JSR?

[Thomas L Roche]

David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of 
his remarks include

- Is JSF a replacement for Struts? Yes!

- JSF is a standard. Struts will never be a standard.

which I believe to be pretty-nearly-direct quotes. I'm assuming he
really meant

+ JSF 1.0 can do pretty much everything Struts 1.1 can.

+ JSF is a JSR, and Struts will never be a JSR.

but I'm wondering about that last statement. What prevents Struts
from undergoing the JCP? Are there circumstances under which you
might consider this?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]