You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Brian Pontarelli <br...@pontarelli.com> on 2007/09/10 21:45:47 UTC
Should I announce SmartURLs or wait?
I was planning on release 1.0 of SmartURLs in the near future and doing
some announcements to the user lists and some other locations. However,
should I wait on that if favor of rolling this back into core, or should
I go ahead?
Thoughts?
-bp
Re: Should I announce SmartURLs or wait?
Posted by Brian Pontarelli <br...@pontarelli.com>.
Okay, created the tickets.
*ConfigurationProvider loading mechanism*
https://issues.apache.org/struts/browse/WW-2192
*Extensionless URLs*
Don, it looks like you covered most of this. Did you add support for
"index actions"? Smart URLs handles these like this:
URL = http://www.example.com/foo
1. First check for action named foo in namespace /
2. Send redirect to http://www.example.com/foo/
URL = http://www.example.com/foo/
1. Check for action named index in namespace /foo
This is pretty standard handling by most J2EE and HTTP containers and
that's why I did it like that. The Smart URLs configuration provider
sets all of this up ahead of time based on what actions it finds in the
classpath.
*Pluggable FilterDispatcher*
https://issues.apache.org/struts/browse/WW-2193
-bp
Don Brown wrote:
> Could you translate these ideas into JIRA tickets and mark them
> against 2.1? After I finish with the XWork refactoring, I'd like to
> work on making the configuration providers pluggable, because as you
> said, it really opens up some interesting possibilities. It is kinda
> tricky as you have a chicken-egg situation with providers that create
> plugins which create providers, so patches would be very welcome :)
>
> Don
>
> On 9/12/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
>> Well, the configuration provider is kinda a pain right now. I started a
>> thread a while back about making configuration providers pluggable via the
>> struts-plugin.xml file. I think it sorta died because you can use init
>> parameters to setup providers in web.xml.
>>
>> In addition, if you want to use the extensionless support as well as all
>> the index support of the plugin it requires a completely different filter,
>> but it would be much nicer to have everything just plug-in and run with as
>> little configuration as possible.
>>
>> If we keep it a plugin then I would suggest removing zero-config from core
>> so that they don't conflict. I'd probably also want to rework the
>> DispatcherFilter to make it more pluggable so that the majority of the work
>> is from injections and then it can be changed without modifying the web.xml.
>> Lastly, the configuration providers need to be easier to setup. This would
>> probably require a more robust configuration mechanism that would pre-inject
>> configuration providers and then inject the rest of the container.
>>
>> However, all that said, I think this should be in core. The beauty of
>> frameworks like Rails and Grails is that they give all the conventions right
>> out of the box. I feel like Struts should try to strive to match the ease of
>> these other frameworks. Otherwise, it requires the users to actually know
>> that the plugin exists, go find it, install it and then learn it all.
>>
>> -bp
>>
>>
>>
>> Don Brown wrote:
>> The reason the zero config stuff is in core is mainly because it
>> requires a configuration provider, which cannot be plugged in via a
>> struts plugin. Is there any other technical reason that this should
>> be in core?
>>
>> Don
>>
>> On 9/11/07, Musachy Barroso <mu...@gmail.com> wrote:
>>
>>
>> IMO this should be a "core" feature of struts 2.
>>
>> musachy
>>
>> On 9/10/07, Don Brown <mr...@twdata.org> wrote:
>>
>>
>> Hmm...along those lines, could SmartURL be Codebehind 2.0?
>>
>> As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
>> other things, make OGNL pluggable and fully migrate the code to
>> container injection (no statics!). I should be done sometime this
>> week.
>>
>> Don
>>
>> On 9/11/07, Ted Husted <hu...@apache.org> wrote:
>>
>>
>> Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
>> could be out next week, or next month, or next year. There's really no
>> telling.
>>
>> I'm not sure what "rolling it into the core" means. If it means
>> putting the source into the Struts-Core JAR, then I'd probably be
>> opposed. Personally, I'd like to keep rolling things out of the core
>> and distribute as much as possible in the form of plugins. Ultimately,
>> there should be nothing in the core that doesn't *need* to be in the
>> core. My thought would be to include SmartURLs in Struts 2.1.x as the
>> successor to the CodeBehind plugin.
>>
>> -Ted.
>>
>> On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
>>
>>
>> +1 for waiting and rolling it into core, it could be available for 2.1
>>
>> musachy
>>
>> On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>>
>>
>> I was planning on release 1.0 of SmartURLs in the near future and doing
>> some announcements to the user lists and some other locations. However,
>> should I wait on that if favor of rolling this back into core, or should
>> I go ahead?
>>
>> Thoughts?
>>
>> -bp
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> 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: Should I announce SmartURLs or wait?
Posted by Brian Pontarelli <br...@pontarelli.com>.
Luckily Smart URLs is A2 ;)
I agree that providing a zip is probably better. I think ensuring that
out of the box things can be configured for maximum simplicity and make
it easy for developers to get up and running should be the goal. This
mostly comes down to documentation and not necessarily with bundling.
Writing up a good document that says, "grab these 5 JARs and put them in
WEB-INF/lib" seems to be a minimal amount of overhead. The key is to
provide clear information about the standard plugins and how to get up
and running using them.
-bp
Ted Husted wrote:
> In our case, we might want to think about a struts-standard.zip or
> struts-bundle.zip that contained the recommended plugins -and- their
> dependencies. So, if we are including the Spring plugin, we would
> include the spring.jar too. This could just be yet another artifact
> that we post, like the struts-lib.zip. We might also setup a Maven
> prototype that did the same thing, or just offer the prototype, a la
> AppFuse.
>
> Of course, this presumes that all of the plugin dependencies that we
> bundle can be distributed under the Apache license.
>
> -Ted.
>
> On 9/13/07, Paul Benedict <pb...@apache.org> wrote:
>
>> My only caution with a struts2-standard.jar is that the analogy to Spring
>> isn't accurate. Spring doesn't have a plug-in architecture (yet) and
>> including more classes doesn't affecting the running of the libraries. On
>> the contrary, Struts plug-ins are loaded automatically and hook themselves
>> into the framework. So I am -1 on providing a struts with statically-bound
>> bundled plug-ins. A zip file distribution would be preferred.
>>
>> Paul
>>
>> On 9/11/07, Don Brown <mr...@twdata.org> wrote:
>>
>>> Could you translate these ideas into JIRA tickets and mark them
>>> against 2.1? After I finish with the XWork refactoring, I'd like to
>>> work on making the configuration providers pluggable, because as you
>>> said, it really opens up some interesting possibilities. It is kinda
>>> tricky as you have a chicken-egg situation with providers that create
>>> plugins which create providers, so patches would be very welcome :)
>>>
>>> Don
>>>
>>> On 9/12/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>>>
>>>> Well, the configuration provider is kinda a pain right now. I started a
>>>> thread a while back about making configuration providers pluggable via
>>>>
>>> the
>>>
>>>> struts-plugin.xml file. I think it sorta died because you can use init
>>>> parameters to setup providers in web.xml.
>>>>
>>>> In addition, if you want to use the extensionless support as well as
>>>>
>>> all
>>>
>>>> the index support of the plugin it requires a completely different
>>>>
>>> filter,
>>>
>>>> but it would be much nicer to have everything just plug-in and run with
>>>>
>>> as
>>>
>>>> little configuration as possible.
>>>>
>>>> If we keep it a plugin then I would suggest removing zero-config from
>>>>
>>> core
>>>
>>>> so that they don't conflict. I'd probably also want to rework the
>>>> DispatcherFilter to make it more pluggable so that the majority of the
>>>>
>>> work
>>>
>>>> is from injections and then it can be changed without modifying the
>>>>
>>> web.xml.
>>>
>>>> Lastly, the configuration providers need to be easier to setup. This
>>>>
>>> would
>>>
>>>> probably require a more robust configuration mechanism that would
>>>>
>>> pre-inject
>>>
>>>> configuration providers and then inject the rest of the container.
>>>>
>>>> However, all that said, I think this should be in core. The beauty of
>>>> frameworks like Rails and Grails is that they give all the conventions
>>>>
>>> right
>>>
>>>> out of the box. I feel like Struts should try to strive to match the
>>>>
>>> ease of
>>>
>>>> these other frameworks. Otherwise, it requires the users to actually
>>>>
>>> know
>>>
>>>> that the plugin exists, go find it, install it and then learn it all.
>>>>
>>>> -bp
>>>>
>>>>
>>>>
>>>> Don Brown wrote:
>>>> The reason the zero config stuff is in core is mainly because it
>>>> requires a configuration provider, which cannot be plugged in via a
>>>> struts plugin. Is there any other technical reason that this should
>>>> be in core?
>>>>
>>>> Don
>>>>
>>>> On 9/11/07, Musachy Barroso <mu...@gmail.com> wrote:
>>>>
>>>>
>>>> IMO this should be a "core" feature of struts 2.
>>>>
>>>> musachy
>>>>
>>>> On 9/10/07, Don Brown <mr...@twdata.org> wrote:
>>>>
>>>>
>>>> Hmm...along those lines, could SmartURL be Codebehind 2.0?
>>>>
>>>> As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
>>>> other things, make OGNL pluggable and fully migrate the code to
>>>> container injection (no statics!). I should be done sometime this
>>>> week.
>>>>
>>>> Don
>>>>
>>>> On 9/11/07, Ted Husted <hu...@apache.org> wrote:
>>>>
>>>>
>>>> Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
>>>> could be out next week, or next month, or next year. There's really no
>>>> telling.
>>>>
>>>> I'm not sure what "rolling it into the core" means. If it means
>>>> putting the source into the Struts-Core JAR, then I'd probably be
>>>> opposed. Personally, I'd like to keep rolling things out of the core
>>>> and distribute as much as possible in the form of plugins. Ultimately,
>>>> there should be nothing in the core that doesn't *need* to be in the
>>>> core. My thought would be to include SmartURLs in Struts 2.1.x as the
>>>> successor to the CodeBehind plugin.
>>>>
>>>> -Ted.
>>>>
>>>> On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
>>>>
>>>>
>>>> +1 for waiting and rolling it into core, it could be available for 2.1
>>>>
>>>> musachy
>>>>
>>>> On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>>>>
>>>>
>>>> I was planning on release 1.0 of SmartURLs in the near future and doing
>>>> some announcements to the user lists and some other locations. However,
>>>> should I wait on that if favor of rolling this back into core, or should
>>>> I go ahead?
>>>>
>>>> Thoughts?
>>>>
>>>> -bp
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: [OT] Re: Should I announce SmartURLs or wait?
Posted by Ian Roughley <ia...@fdar.com>.
Don Brown wrote:
> The generally accepted terminology for release numbering is
> MAJOR.MINOR.PATCH. Yes, Struts does things strangely, but that
> doesn't change how users expect things to work. Throwing in big
> features, and yes, I consider new annotations big features as they
> worm their way into user code, is not something I feel comfortable
> doing in a "third-level" release, or whatever we call it.
>
> In this case, the annotations will be likely redone for 2.1 anyways.
> A lot of it is my fault - they have been kinda thrown in there without
> systematic thought, and I had hoped we could fix that for 2.1. I'd
> hate to introduce new annotations only to deprecate them weeks later.
>
My preference would be to wait as well. If for nothing else, to see how
JSR-311 (RESTful web services) flushes out and whether we should adopt
some of the structure of the annotations in Struts2. Has anyone looked
into this JSR? I saw a presentation at Sun Tech Days the other day. I
just need to find some time to see if it could be adopted to the
annotations in s2 now :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [OT] Re: Should I announce SmartURLs or wait?
Posted by Don Brown <do...@gmail.com>.
The generally accepted terminology for release numbering is
MAJOR.MINOR.PATCH. Yes, Struts does things strangely, but that
doesn't change how users expect things to work. Throwing in big
features, and yes, I consider new annotations big features as they
worm their way into user code, is not something I feel comfortable
doing in a "third-level" release, or whatever we call it.
In this case, the annotations will be likely redone for 2.1 anyways.
A lot of it is my fault - they have been kinda thrown in there without
systematic thought, and I had hoped we could fix that for 2.1. I'd
hate to introduce new annotations only to deprecate them weeks later.
Don
On 9/21/07, Ted Husted <hu...@apache.org> wrote:
> As I understand it, 2.0.x is not a "patch release". It's part of the
> 2.0.x minor release series. By our reckoning, 2.0.10.1 would be a
> "patch" release, and in that case, I would agree.
>
> AFAIK, we have always agreed that minor releases are *not*
> feature-locked. If we start feature-locking minor-releases, IMHO, we
> will *never* get a timely GA vote on a minor release, because everyone
> will say "wait, wait, one more thing". (Been there, did that, burned
> the T-shirt!)
>
> We do have annotations in the 2.0.x series, but we are missing
> ActionName/ActionNames annotations. We would simply be finishing what
> we already started. No one is suggesting that we change any existing
> behavior, but that we simply add in the ActionName.ActionNames
> annotations in the same way that we have ResultName and ResultNames
> annotations.
>
> -Ted.
>
> On 9/20/07, Don Brown <mr...@twdata.org> wrote:
> > I'd prefer we give this more thought and keep it in the 2.1.x branch.
> > I view patch releases as those that only provide bug fixes or minor
> > stability features. Something like annotations, which will be used in
> > client code, is really a public API feature and should be reserved for
> > minor, at the least, feature releases.
> >
> > Don
> >
> > On 9/18/07, Ted Husted <hu...@apache.org> wrote:
> > > I was just wondering if it would make any sense to at least add
> > > SmartURL-type ActionName and ActionNames annotations to the 2.0.x
> > > core, so as to finish what we started with the validation and result
> > > annotations. We probably don't need to get into exception and
> > > interceptor annotations for 2.0, but ActionNames would be nice.
> > >
> > > -Ted.
>
> ---------------------------------------------------------------------
> 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: [OT] Re: Should I announce SmartURLs or wait?
Posted by Ted Husted <hu...@apache.org>.
As I understand it, 2.0.x is not a "patch release". It's part of the
2.0.x minor release series. By our reckoning, 2.0.10.1 would be a
"patch" release, and in that case, I would agree.
AFAIK, we have always agreed that minor releases are *not*
feature-locked. If we start feature-locking minor-releases, IMHO, we
will *never* get a timely GA vote on a minor release, because everyone
will say "wait, wait, one more thing". (Been there, did that, burned
the T-shirt!)
We do have annotations in the 2.0.x series, but we are missing
ActionName/ActionNames annotations. We would simply be finishing what
we already started. No one is suggesting that we change any existing
behavior, but that we simply add in the ActionName.ActionNames
annotations in the same way that we have ResultName and ResultNames
annotations.
-Ted.
On 9/20/07, Don Brown <mr...@twdata.org> wrote:
> I'd prefer we give this more thought and keep it in the 2.1.x branch.
> I view patch releases as those that only provide bug fixes or minor
> stability features. Something like annotations, which will be used in
> client code, is really a public API feature and should be reserved for
> minor, at the least, feature releases.
>
> Don
>
> On 9/18/07, Ted Husted <hu...@apache.org> wrote:
> > I was just wondering if it would make any sense to at least add
> > SmartURL-type ActionName and ActionNames annotations to the 2.0.x
> > core, so as to finish what we started with the validation and result
> > annotations. We probably don't need to get into exception and
> > interceptor annotations for 2.0, but ActionNames would be nice.
> >
> > -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [OT] Re: Should I announce SmartURLs or wait?
Posted by Brian Pontarelli <br...@pontarelli.com>.
I'd like to solidify a package names. One of the headaches we
experienced was the conversion between the two versions of
zero-conf/code-behind because of the package names. I'm fine with moving
my packages around into the struts namespace, but if you guys decide to
add these annotations for 2.0.x I think they should be put into their
final package so to speak and fix everything to use those package names.
-bp
Ted Husted wrote:
> I was just wondering if it would make any sense to at least add
> SmartURL-type ActionName and ActionNames annotations to the 2.0.x
> core, so as to finish what we started with the validation and result
> annotations. We probably don't need to get into exception and
> interceptor annotations for 2.0, but ActionNames would be nice.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [OT] Re: Should I announce SmartURLs or wait?
Posted by Don Brown <mr...@twdata.org>.
I'd prefer we give this more thought and keep it in the 2.1.x branch.
I view patch releases as those that only provide bug fixes or minor
stability features. Something like annotations, which will be used in
client code, is really a public API feature and should be reserved for
minor, at the least, feature releases.
Don
On 9/18/07, Ted Husted <hu...@apache.org> wrote:
> I was just wondering if it would make any sense to at least add
> SmartURL-type ActionName and ActionNames annotations to the 2.0.x
> core, so as to finish what we started with the validation and result
> annotations. We probably don't need to get into exception and
> interceptor annotations for 2.0, but ActionNames would be nice.
>
> -Ted.
>
> ---------------------------------------------------------------------
> 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: [OT] Re: Should I announce SmartURLs or wait?
Posted by Ted Husted <hu...@apache.org>.
I was just wondering if it would make any sense to at least add
SmartURL-type ActionName and ActionNames annotations to the 2.0.x
core, so as to finish what we started with the validation and result
annotations. We probably don't need to get into exception and
interceptor annotations for 2.0, but ActionNames would be nice.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
[OT] Re: Should I announce SmartURLs or wait?
Posted by Antonio Petrelli <an...@gmail.com>.
2007/9/13, Ted Husted <hu...@apache.org>:
>
> Of course, sadly, Hibernate is under the LGPL, which the FSF insists
> is not compatible with the Apache License <deep-melancholy-sigh/> :(
You can use Apache Cayenne then :-)
Antonio
Re: Should I announce SmartURLs or wait?
Posted by Ted Husted <hu...@apache.org>.
On 9/13/07, Jim Cushing <ji...@mac.com> wrote:
> A Maven archetype should get you around any license/distribution
> issues,
Yes and no. We have to be careful to make it *very* clear to the
general public that by utilizing such a prototype they will be
creating an application that is not under the Apache License, and any
application that the create may be covered by another license.
The guiding point is that the general public has an expectation that
any software obtained from an ASF project is not encumbered by any
license more restrictive than the Apache License.
So, yes, we can distribute such a prototype, but we need to warn
people about the licensing encumbrance if they use that prototype. A
prototype that includes a dependency with a more restrictive license
might be fine for an alternative setup, but it wouldt be problematic
for anything we were going to call the "standard" setup.
Of course, sadly, Hibernate is under the LGPL, which the FSF insists
is not compatible with the Apache License <deep-melancholy-sigh/> :(
See also: http://people.apache.org/~cliffs/3party.html
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Should I announce SmartURLs or wait?
Posted by Jim Cushing <ji...@mac.com>.
A Maven archetype should get you around any license/distribution
issues, provided the dependencies are in a public Maven repository.
Then, Maven will download the dependencies, such that they don't need
to be bundled. It's nice, but not necessary, that the plugins have
Maven POMs (for the sake of transitive dependencies), and that
doesn't necessarily mean the plugin must be built using Maven 2.
On Sep 13, 2007, at 10:56 AM, Ted Husted wrote:
> In our case, we might want to think about a struts-standard.zip or
> struts-bundle.zip that contained the recommended plugins -and- their
> dependencies. So, if we are including the Spring plugin, we would
> include the spring.jar too. This could just be yet another artifact
> that we post, like the struts-lib.zip. We might also setup a Maven
> prototype that did the same thing, or just offer the prototype, a la
> AppFuse.
>
> Of course, this presumes that all of the plugin dependencies that we
> bundle can be distributed under the Apache license.
>
> -Ted.
>
> On 9/13/07, Paul Benedict <pb...@apache.org> wrote:
>> My only caution with a struts2-standard.jar is that the analogy to
>> Spring
>> isn't accurate. Spring doesn't have a plug-in architecture (yet) and
>> including more classes doesn't affecting the running of the
>> libraries. On
>> the contrary, Struts plug-ins are loaded automatically and hook
>> themselves
>> into the framework. So I am -1 on providing a struts with
>> statically-bound
>> bundled plug-ins. A zip file distribution would be preferred.
>>
>> Paul
>>
>> On 9/11/07, Don Brown <mr...@twdata.org> wrote:
>>>
>>> Could you translate these ideas into JIRA tickets and mark them
>>> against 2.1? After I finish with the XWork refactoring, I'd like to
>>> work on making the configuration providers pluggable, because as you
>>> said, it really opens up some interesting possibilities. It is
>>> kinda
>>> tricky as you have a chicken-egg situation with providers that
>>> create
>>> plugins which create providers, so patches would be very welcome :)
>>>
>>> Don
>>>
>>> On 9/12/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>>>>
>>>> Well, the configuration provider is kinda a pain right now. I
>>>> started a
>>>> thread a while back about making configuration providers
>>>> pluggable via
>>> the
>>>> struts-plugin.xml file. I think it sorta died because you can
>>>> use init
>>>> parameters to setup providers in web.xml.
>>>>
>>>> In addition, if you want to use the extensionless support as
>>>> well as
>>> all
>>>> the index support of the plugin it requires a completely different
>>> filter,
>>>> but it would be much nicer to have everything just plug-in and
>>>> run with
>>> as
>>>> little configuration as possible.
>>>>
>>>> If we keep it a plugin then I would suggest removing zero-
>>>> config from
>>> core
>>>> so that they don't conflict. I'd probably also want to rework the
>>>> DispatcherFilter to make it more pluggable so that the majority
>>>> of the
>>> work
>>>> is from injections and then it can be changed without modifying the
>>> web.xml.
>>>> Lastly, the configuration providers need to be easier to setup.
>>>> This
>>> would
>>>> probably require a more robust configuration mechanism that would
>>> pre-inject
>>>> configuration providers and then inject the rest of the container.
>>>>
>>>> However, all that said, I think this should be in core. The
>>>> beauty of
>>>> frameworks like Rails and Grails is that they give all the
>>>> conventions
>>> right
>>>> out of the box. I feel like Struts should try to strive to match
>>>> the
>>> ease of
>>>> these other frameworks. Otherwise, it requires the users to
>>>> actually
>>> know
>>>> that the plugin exists, go find it, install it and then learn it
>>>> all.
>>>>
>>>> -bp
>>>>
>>>>
>>>>
>>>> Don Brown wrote:
>>>> The reason the zero config stuff is in core is mainly because it
>>>> requires a configuration provider, which cannot be plugged in via a
>>>> struts plugin. Is there any other technical reason that this should
>>>> be in core?
>>>>
>>>> Don
>>>>
>>>> On 9/11/07, Musachy Barroso <mu...@gmail.com> wrote:
>>>>
>>>>
>>>> IMO this should be a "core" feature of struts 2.
>>>>
>>>> musachy
>>>>
>>>> On 9/10/07, Don Brown <mr...@twdata.org> wrote:
>>>>
>>>>
>>>> Hmm...along those lines, could SmartURL be Codebehind 2.0?
>>>>
>>>> As for 2.1, I'm working on a huge patch to xwork 2.1 that will,
>>>> among
>>>> other things, make OGNL pluggable and fully migrate the code to
>>>> container injection (no statics!). I should be done sometime this
>>>> week.
>>>>
>>>> Don
>>>>
>>>> On 9/11/07, Ted Husted <hu...@apache.org> wrote:
>>>>
>>>>
>>>> Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
>>>> could be out next week, or next month, or next year. There's
>>>> really no
>>>> telling.
>>>>
>>>> I'm not sure what "rolling it into the core" means. If it means
>>>> putting the source into the Struts-Core JAR, then I'd probably be
>>>> opposed. Personally, I'd like to keep rolling things out of the
>>>> core
>>>> and distribute as much as possible in the form of plugins.
>>>> Ultimately,
>>>> there should be nothing in the core that doesn't *need* to be in
>>>> the
>>>> core. My thought would be to include SmartURLs in Struts 2.1.x
>>>> as the
>>>> successor to the CodeBehind plugin.
>>>>
>>>> -Ted.
>>>>
>>>> On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
>>>>
>>>>
>>>> +1 for waiting and rolling it into core, it could be available
>>>> for 2.1
>>>>
>>>> musachy
>>>>
>>>> On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>>>>
>>>>
>>>> I was planning on release 1.0 of SmartURLs in the near future
>>>> and doing
>>>> some announcements to the user lists and some other locations.
>>>> However,
>>>> should I wait on that if favor of rolling this back into core,
>>>> or should
>>>> I go ahead?
>>>>
>>>> Thoughts?
>>>>
>>>> -bp
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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
>>>
>>>
>>
>
>
> --
> HTH, Ted <http://www.husted.com/ted/blog/>
>
> ---------------------------------------------------------------------
> 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: Should I announce SmartURLs or wait?
Posted by Ted Husted <hu...@apache.org>.
In our case, we might want to think about a struts-standard.zip or
struts-bundle.zip that contained the recommended plugins -and- their
dependencies. So, if we are including the Spring plugin, we would
include the spring.jar too. This could just be yet another artifact
that we post, like the struts-lib.zip. We might also setup a Maven
prototype that did the same thing, or just offer the prototype, a la
AppFuse.
Of course, this presumes that all of the plugin dependencies that we
bundle can be distributed under the Apache license.
-Ted.
On 9/13/07, Paul Benedict <pb...@apache.org> wrote:
> My only caution with a struts2-standard.jar is that the analogy to Spring
> isn't accurate. Spring doesn't have a plug-in architecture (yet) and
> including more classes doesn't affecting the running of the libraries. On
> the contrary, Struts plug-ins are loaded automatically and hook themselves
> into the framework. So I am -1 on providing a struts with statically-bound
> bundled plug-ins. A zip file distribution would be preferred.
>
> Paul
>
> On 9/11/07, Don Brown <mr...@twdata.org> wrote:
> >
> > Could you translate these ideas into JIRA tickets and mark them
> > against 2.1? After I finish with the XWork refactoring, I'd like to
> > work on making the configuration providers pluggable, because as you
> > said, it really opens up some interesting possibilities. It is kinda
> > tricky as you have a chicken-egg situation with providers that create
> > plugins which create providers, so patches would be very welcome :)
> >
> > Don
> >
> > On 9/12/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> > >
> > > Well, the configuration provider is kinda a pain right now. I started a
> > > thread a while back about making configuration providers pluggable via
> > the
> > > struts-plugin.xml file. I think it sorta died because you can use init
> > > parameters to setup providers in web.xml.
> > >
> > > In addition, if you want to use the extensionless support as well as
> > all
> > > the index support of the plugin it requires a completely different
> > filter,
> > > but it would be much nicer to have everything just plug-in and run with
> > as
> > > little configuration as possible.
> > >
> > > If we keep it a plugin then I would suggest removing zero-config from
> > core
> > > so that they don't conflict. I'd probably also want to rework the
> > > DispatcherFilter to make it more pluggable so that the majority of the
> > work
> > > is from injections and then it can be changed without modifying the
> > web.xml.
> > > Lastly, the configuration providers need to be easier to setup. This
> > would
> > > probably require a more robust configuration mechanism that would
> > pre-inject
> > > configuration providers and then inject the rest of the container.
> > >
> > > However, all that said, I think this should be in core. The beauty of
> > > frameworks like Rails and Grails is that they give all the conventions
> > right
> > > out of the box. I feel like Struts should try to strive to match the
> > ease of
> > > these other frameworks. Otherwise, it requires the users to actually
> > know
> > > that the plugin exists, go find it, install it and then learn it all.
> > >
> > > -bp
> > >
> > >
> > >
> > > Don Brown wrote:
> > > The reason the zero config stuff is in core is mainly because it
> > > requires a configuration provider, which cannot be plugged in via a
> > > struts plugin. Is there any other technical reason that this should
> > > be in core?
> > >
> > > Don
> > >
> > > On 9/11/07, Musachy Barroso <mu...@gmail.com> wrote:
> > >
> > >
> > > IMO this should be a "core" feature of struts 2.
> > >
> > > musachy
> > >
> > > On 9/10/07, Don Brown <mr...@twdata.org> wrote:
> > >
> > >
> > > Hmm...along those lines, could SmartURL be Codebehind 2.0?
> > >
> > > As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
> > > other things, make OGNL pluggable and fully migrate the code to
> > > container injection (no statics!). I should be done sometime this
> > > week.
> > >
> > > Don
> > >
> > > On 9/11/07, Ted Husted <hu...@apache.org> wrote:
> > >
> > >
> > > Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
> > > could be out next week, or next month, or next year. There's really no
> > > telling.
> > >
> > > I'm not sure what "rolling it into the core" means. If it means
> > > putting the source into the Struts-Core JAR, then I'd probably be
> > > opposed. Personally, I'd like to keep rolling things out of the core
> > > and distribute as much as possible in the form of plugins. Ultimately,
> > > there should be nothing in the core that doesn't *need* to be in the
> > > core. My thought would be to include SmartURLs in Struts 2.1.x as the
> > > successor to the CodeBehind plugin.
> > >
> > > -Ted.
> > >
> > > On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
> > >
> > >
> > > +1 for waiting and rolling it into core, it could be available for 2.1
> > >
> > > musachy
> > >
> > > On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> > >
> > >
> > > I was planning on release 1.0 of SmartURLs in the near future and doing
> > > some announcements to the user lists and some other locations. However,
> > > should I wait on that if favor of rolling this back into core, or should
> > > I go ahead?
> > >
> > > Thoughts?
> > >
> > > -bp
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > >
> > >
> > >
> > > --
> > > "Hey you! Would you help me to carry the stone?" Pink Floyd
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Should I announce SmartURLs or wait?
Posted by Paul Benedict <pb...@apache.org>.
My only caution with a struts2-standard.jar is that the analogy to Spring
isn't accurate. Spring doesn't have a plug-in architecture (yet) and
including more classes doesn't affecting the running of the libraries. On
the contrary, Struts plug-ins are loaded automatically and hook themselves
into the framework. So I am -1 on providing a struts with statically-bound
bundled plug-ins. A zip file distribution would be preferred.
Paul
On 9/11/07, Don Brown <mr...@twdata.org> wrote:
>
> Could you translate these ideas into JIRA tickets and mark them
> against 2.1? After I finish with the XWork refactoring, I'd like to
> work on making the configuration providers pluggable, because as you
> said, it really opens up some interesting possibilities. It is kinda
> tricky as you have a chicken-egg situation with providers that create
> plugins which create providers, so patches would be very welcome :)
>
> Don
>
> On 9/12/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> >
> > Well, the configuration provider is kinda a pain right now. I started a
> > thread a while back about making configuration providers pluggable via
> the
> > struts-plugin.xml file. I think it sorta died because you can use init
> > parameters to setup providers in web.xml.
> >
> > In addition, if you want to use the extensionless support as well as
> all
> > the index support of the plugin it requires a completely different
> filter,
> > but it would be much nicer to have everything just plug-in and run with
> as
> > little configuration as possible.
> >
> > If we keep it a plugin then I would suggest removing zero-config from
> core
> > so that they don't conflict. I'd probably also want to rework the
> > DispatcherFilter to make it more pluggable so that the majority of the
> work
> > is from injections and then it can be changed without modifying the
> web.xml.
> > Lastly, the configuration providers need to be easier to setup. This
> would
> > probably require a more robust configuration mechanism that would
> pre-inject
> > configuration providers and then inject the rest of the container.
> >
> > However, all that said, I think this should be in core. The beauty of
> > frameworks like Rails and Grails is that they give all the conventions
> right
> > out of the box. I feel like Struts should try to strive to match the
> ease of
> > these other frameworks. Otherwise, it requires the users to actually
> know
> > that the plugin exists, go find it, install it and then learn it all.
> >
> > -bp
> >
> >
> >
> > Don Brown wrote:
> > The reason the zero config stuff is in core is mainly because it
> > requires a configuration provider, which cannot be plugged in via a
> > struts plugin. Is there any other technical reason that this should
> > be in core?
> >
> > Don
> >
> > On 9/11/07, Musachy Barroso <mu...@gmail.com> wrote:
> >
> >
> > IMO this should be a "core" feature of struts 2.
> >
> > musachy
> >
> > On 9/10/07, Don Brown <mr...@twdata.org> wrote:
> >
> >
> > Hmm...along those lines, could SmartURL be Codebehind 2.0?
> >
> > As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
> > other things, make OGNL pluggable and fully migrate the code to
> > container injection (no statics!). I should be done sometime this
> > week.
> >
> > Don
> >
> > On 9/11/07, Ted Husted <hu...@apache.org> wrote:
> >
> >
> > Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
> > could be out next week, or next month, or next year. There's really no
> > telling.
> >
> > I'm not sure what "rolling it into the core" means. If it means
> > putting the source into the Struts-Core JAR, then I'd probably be
> > opposed. Personally, I'd like to keep rolling things out of the core
> > and distribute as much as possible in the form of plugins. Ultimately,
> > there should be nothing in the core that doesn't *need* to be in the
> > core. My thought would be to include SmartURLs in Struts 2.1.x as the
> > successor to the CodeBehind plugin.
> >
> > -Ted.
> >
> > On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
> >
> >
> > +1 for waiting and rolling it into core, it could be available for 2.1
> >
> > musachy
> >
> > On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> >
> >
> > I was planning on release 1.0 of SmartURLs in the near future and doing
> > some announcements to the user lists and some other locations. However,
> > should I wait on that if favor of rolling this back into core, or should
> > I go ahead?
> >
> > Thoughts?
> >
> > -bp
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
> >
> > --
> > "Hey you! Would you help me to carry the stone?" Pink Floyd
> >
> > ---------------------------------------------------------------------
> > 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: Should I announce SmartURLs or wait?
Posted by Don Brown <mr...@twdata.org>.
Could you translate these ideas into JIRA tickets and mark them
against 2.1? After I finish with the XWork refactoring, I'd like to
work on making the configuration providers pluggable, because as you
said, it really opens up some interesting possibilities. It is kinda
tricky as you have a chicken-egg situation with providers that create
plugins which create providers, so patches would be very welcome :)
Don
On 9/12/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
> Well, the configuration provider is kinda a pain right now. I started a
> thread a while back about making configuration providers pluggable via the
> struts-plugin.xml file. I think it sorta died because you can use init
> parameters to setup providers in web.xml.
>
> In addition, if you want to use the extensionless support as well as all
> the index support of the plugin it requires a completely different filter,
> but it would be much nicer to have everything just plug-in and run with as
> little configuration as possible.
>
> If we keep it a plugin then I would suggest removing zero-config from core
> so that they don't conflict. I'd probably also want to rework the
> DispatcherFilter to make it more pluggable so that the majority of the work
> is from injections and then it can be changed without modifying the web.xml.
> Lastly, the configuration providers need to be easier to setup. This would
> probably require a more robust configuration mechanism that would pre-inject
> configuration providers and then inject the rest of the container.
>
> However, all that said, I think this should be in core. The beauty of
> frameworks like Rails and Grails is that they give all the conventions right
> out of the box. I feel like Struts should try to strive to match the ease of
> these other frameworks. Otherwise, it requires the users to actually know
> that the plugin exists, go find it, install it and then learn it all.
>
> -bp
>
>
>
> Don Brown wrote:
> The reason the zero config stuff is in core is mainly because it
> requires a configuration provider, which cannot be plugged in via a
> struts plugin. Is there any other technical reason that this should
> be in core?
>
> Don
>
> On 9/11/07, Musachy Barroso <mu...@gmail.com> wrote:
>
>
> IMO this should be a "core" feature of struts 2.
>
> musachy
>
> On 9/10/07, Don Brown <mr...@twdata.org> wrote:
>
>
> Hmm...along those lines, could SmartURL be Codebehind 2.0?
>
> As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
> other things, make OGNL pluggable and fully migrate the code to
> container injection (no statics!). I should be done sometime this
> week.
>
> Don
>
> On 9/11/07, Ted Husted <hu...@apache.org> wrote:
>
>
> Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
> could be out next week, or next month, or next year. There's really no
> telling.
>
> I'm not sure what "rolling it into the core" means. If it means
> putting the source into the Struts-Core JAR, then I'd probably be
> opposed. Personally, I'd like to keep rolling things out of the core
> and distribute as much as possible in the form of plugins. Ultimately,
> there should be nothing in the core that doesn't *need* to be in the
> core. My thought would be to include SmartURLs in Struts 2.1.x as the
> successor to the CodeBehind plugin.
>
> -Ted.
>
> On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
>
>
> +1 for waiting and rolling it into core, it could be available for 2.1
>
> musachy
>
> On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
>
> I was planning on release 1.0 of SmartURLs in the near future and doing
> some announcements to the user lists and some other locations. However,
> should I wait on that if favor of rolling this back into core, or should
> I go ahead?
>
> Thoughts?
>
> -bp
>
> ---------------------------------------------------------------------
> 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
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> 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: Should I announce SmartURLs or wait?
Posted by Don Brown <mr...@twdata.org>.
It shouldn't be too hard to create a struts2-standard.jar, which
contains the contents of struts2-core plus several choice plugins.
Spring puts out a spring.jar, which contains their trusted modules,
and I don't see why we couldn't do anything similar. Of course, we'd
have to choose plugins that don't conflict and we'd have to write a
tool that would combine their struts-plugin.xml into one file, but
both should be trivial.
Don
On 9/12/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
> Ted Husted wrote:
> On 9/11/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
>
> If we keep it a plugin then I would suggest removing zero-config from core
> so that they don't conflict. I'd probably also want to rework the
> DispatcherFilter to make it more pluggable so that the majority of the work
> is from injections and then it can be changed without modifying the web.xml.
> Lastly, the configuration providers need to be easier to setup. This would
> probably require a more robust configuration mechanism that would pre-inject
> configuration providers and then inject the rest of the container.
>
> I think this is the strongest argument for plugging in as much as
> possible ourselves. If we can do it, then someone else can do it too!
>
> Don put in the plugin architecture less than a year ago, and our first
> stable release was only four months ago. Already, we have a couple of
> dozen plugins, including SmartURLs, and we're learning how to extract
> other functionality like Ajax and Portlets into plugins too.
>
> I'd say we should continue to exploit the plugin architecture, so that
> Struts becomes a lightweight core adorned with plugins. We should
> encourage people to think of Struts plugins they way we think about
> Eclipse or Maven plugins.
>
> I do think this sounds pretty good. I like the plugin architecture, but it
> needs more functionality and extensibility to make it a complete solution.
> Right now not enough of the core infrastructure is exposed to plugins and it
> is difficult to make things just drop in and work.
>
> I think it can be done, it just needs some good discussion and some changes
> to core.
>
>
>
> However, all that said, I think this should be in core. The beauty of
> frameworks like Rails and Grails is that they give all the conventions right
> out of the box. I feel like Struts should try to strive to match the ease of
> these other frameworks. Otherwise, it requires the users to actually know
> that the plugin exists, go find it, install it and then learn it all.
>
> I'd say it's way too early to say we've hit the best and brightest way
> to do this. (Or that Rails or Grails has either!)
>
> If we starting rolling things like this into the core, then as you
> pointed out, we start to foreclose possibilities for alternate
> plugins, or at least make it harder for other people to innovate.
>
> There is a lot more to Rails or Grails type functionality than zero
> configuration and code behinds. To really do "Struts on Rails", we'd
> need to encourage people to use Maven prototypes to create starter
> applications, which could easily include items like the CodeBehind 2
> plugin, along with starter actions and pages, test cases, and so
> forth. We also need to think about items like Hibernate or iBATIS
> plugins.
>
> I'll definitely agree on that point. In fact I've already started work on a
> system just like the one you describe. However, I selected the frameworks
> and unlike systems like AppFuse, I decided to not give choices for
> frameworks, but give more functionality. It's called Vertigo and it contains
> an entire build system with project creation (based on Ant and Savant for
> dependencies), database migrations, emailing via FreeMarker and concurrency
> utils, environment aware configuration with a hierarchy, injection via
> guice, JPA support, security (via ACEGI, which does require Spring, but that
> will soon be refactored), common actions like country drop downs, ECommerce
> transactions (currently only via authorize.net), a good set of domain
> classes and base classes, and more is being added all the time.
>
> Take a look if you guys get a chance:
>
> http://code.google.com/p/vertigo-java
>
>
> One compromise would be to keep CodeBehind/ZeroConfig as a plugin, in
> its own JAR, but to ship it in the struts-lib distribution, and make
> it a standard part of any applications or prototypes we offer. People
> won't have to go and get it, because it will already be there. But, if
> someone wants to try something different, they can pluck it out.
>
> I like this the best. I think Struts should have a standard convention
> based system that comes with the distribution and is part of the core
> documentation. Folks that don't want it, just yank the JAR out of
> WEB-INF/lib. Those that want it, have it. I think the key is to have it as
> part of the core documentation so that folks know about it up front.
>
> -bp
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Should I announce SmartURLs or wait?
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On 9/11/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
>> If we keep it a plugin then I would suggest removing zero-config from core
>> so that they don't conflict. I'd probably also want to rework the
>> DispatcherFilter to make it more pluggable so that the majority of the work
>> is from injections and then it can be changed without modifying the web.xml.
>> Lastly, the configuration providers need to be easier to setup. This would
>> probably require a more robust configuration mechanism that would pre-inject
>> configuration providers and then inject the rest of the container.
>>
>
> I think this is the strongest argument for plugging in as much as
> possible ourselves. If we can do it, then someone else can do it too!
>
> Don put in the plugin architecture less than a year ago, and our first
> stable release was only four months ago. Already, we have a couple of
> dozen plugins, including SmartURLs, and we're learning how to extract
> other functionality like Ajax and Portlets into plugins too.
>
> I'd say we should continue to exploit the plugin architecture, so that
> Struts becomes a lightweight core adorned with plugins. We should
> encourage people to think of Struts plugins they way we think about
> Eclipse or Maven plugins.
>
I do think this sounds pretty good. I like the plugin architecture, but
it needs more functionality and extensibility to make it a complete
solution. Right now not enough of the core infrastructure is exposed to
plugins and it is difficult to make things just drop in and work.
I think it can be done, it just needs some good discussion and some
changes to core.
>> However, all that said, I think this should be in core. The beauty of
>> frameworks like Rails and Grails is that they give all the conventions right
>> out of the box. I feel like Struts should try to strive to match the ease of
>> these other frameworks. Otherwise, it requires the users to actually know
>> that the plugin exists, go find it, install it and then learn it all.
>>
>
> I'd say it's way too early to say we've hit the best and brightest way
> to do this. (Or that Rails or Grails has either!)
>
> If we starting rolling things like this into the core, then as you
> pointed out, we start to foreclose possibilities for alternate
> plugins, or at least make it harder for other people to innovate.
>
> There is a lot more to Rails or Grails type functionality than zero
> configuration and code behinds. To really do "Struts on Rails", we'd
> need to encourage people to use Maven prototypes to create starter
> applications, which could easily include items like the CodeBehind 2
> plugin, along with starter actions and pages, test cases, and so
> forth. We also need to think about items like Hibernate or iBATIS
> plugins.
>
I'll definitely agree on that point. In fact I've already started work
on a system just like the one you describe. However, I selected the
frameworks and unlike systems like AppFuse, I decided to not give
choices for frameworks, but give more functionality. It's called Vertigo
and it contains an entire build system with project creation (based on
Ant and Savant for dependencies), database migrations, emailing via
FreeMarker and concurrency utils, environment aware configuration with a
hierarchy, injection via guice, JPA support, security (via ACEGI, which
does require Spring, but that will soon be refactored), common actions
like country drop downs, ECommerce transactions (currently only via
authorize.net), a good set of domain classes and base classes, and more
is being added all the time.
Take a look if you guys get a chance:
http://code.google.com/p/vertigo-java
> One compromise would be to keep CodeBehind/ZeroConfig as a plugin, in
> its own JAR, but to ship it in the struts-lib distribution, and make
> it a standard part of any applications or prototypes we offer. People
> won't have to go and get it, because it will already be there. But, if
> someone wants to try something different, they can pluck it out.
>
I like this the best. I think Struts should have a standard convention
based system that comes with the distribution and is part of the core
documentation. Folks that don't want it, just yank the JAR out of
WEB-INF/lib. Those that want it, have it. I think the key is to have it
as part of the core documentation so that folks know about it up front.
-bp
Re: Should I announce SmartURLs or wait?
Posted by Ted Husted <hu...@apache.org>.
On 9/11/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> If we keep it a plugin then I would suggest removing zero-config from core
> so that they don't conflict. I'd probably also want to rework the
> DispatcherFilter to make it more pluggable so that the majority of the work
> is from injections and then it can be changed without modifying the web.xml.
> Lastly, the configuration providers need to be easier to setup. This would
> probably require a more robust configuration mechanism that would pre-inject
> configuration providers and then inject the rest of the container.
I think this is the strongest argument for plugging in as much as
possible ourselves. If we can do it, then someone else can do it too!
Don put in the plugin architecture less than a year ago, and our first
stable release was only four months ago. Already, we have a couple of
dozen plugins, including SmartURLs, and we're learning how to extract
other functionality like Ajax and Portlets into plugins too.
I'd say we should continue to exploit the plugin architecture, so that
Struts becomes a lightweight core adorned with plugins. We should
encourage people to think of Struts plugins they way we think about
Eclipse or Maven plugins.
> However, all that said, I think this should be in core. The beauty of
> frameworks like Rails and Grails is that they give all the conventions right
> out of the box. I feel like Struts should try to strive to match the ease of
> these other frameworks. Otherwise, it requires the users to actually know
> that the plugin exists, go find it, install it and then learn it all.
I'd say it's way too early to say we've hit the best and brightest way
to do this. (Or that Rails or Grails has either!)
If we starting rolling things like this into the core, then as you
pointed out, we start to foreclose possibilities for alternate
plugins, or at least make it harder for other people to innovate.
There is a lot more to Rails or Grails type functionality than zero
configuration and code behinds. To really do "Struts on Rails", we'd
need to encourage people to use Maven prototypes to create starter
applications, which could easily include items like the CodeBehind 2
plugin, along with starter actions and pages, test cases, and so
forth. We also need to think about items like Hibernate or iBATIS
plugins.
One compromise would be to keep CodeBehind/ZeroConfig as a plugin, in
its own JAR, but to ship it in the struts-lib distribution, and make
it a standard part of any applications or prototypes we offer. People
won't have to go and get it, because it will already be there. But, if
someone wants to try something different, they can pluck it out.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Should I announce SmartURLs or wait?
Posted by Brian Pontarelli <br...@pontarelli.com>.
Well, the configuration provider is kinda a pain right now. I started a
thread a while back about making configuration providers pluggable via
the struts-plugin.xml file. I think it sorta died because you can use
init parameters to setup providers in web.xml.
In addition, if you want to use the extensionless support as well as all
the index support of the plugin it requires a completely different
filter, but it would be much nicer to have everything just plug-in and
run with as little configuration as possible.
If we keep it a plugin then I would suggest removing zero-config from
core so that they don't conflict. I'd probably also want to rework the
DispatcherFilter to make it more pluggable so that the majority of the
work is from injections and then it can be changed without modifying the
web.xml. Lastly, the configuration providers need to be easier to setup.
This would probably require a more robust configuration mechanism that
would pre-inject configuration providers and then inject the rest of the
container.
However, all that said, I think this should be in core. The beauty of
frameworks like Rails and Grails is that they give all the conventions
right out of the box. I feel like Struts should try to strive to match
the ease of these other frameworks. Otherwise, it requires the users to
actually know that the plugin exists, go find it, install it and then
learn it all.
-bp
Don Brown wrote:
> The reason the zero config stuff is in core is mainly because it
> requires a configuration provider, which cannot be plugged in via a
> struts plugin. Is there any other technical reason that this should
> be in core?
>
> Don
>
> On 9/11/07, Musachy Barroso <mu...@gmail.com> wrote:
>
>> IMO this should be a "core" feature of struts 2.
>>
>> musachy
>>
>> On 9/10/07, Don Brown <mr...@twdata.org> wrote:
>>
>>> Hmm...along those lines, could SmartURL be Codebehind 2.0?
>>>
>>> As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
>>> other things, make OGNL pluggable and fully migrate the code to
>>> container injection (no statics!). I should be done sometime this
>>> week.
>>>
>>> Don
>>>
>>> On 9/11/07, Ted Husted <hu...@apache.org> wrote:
>>>
>>>> Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
>>>> could be out next week, or next month, or next year. There's really no
>>>> telling.
>>>>
>>>> I'm not sure what "rolling it into the core" means. If it means
>>>> putting the source into the Struts-Core JAR, then I'd probably be
>>>> opposed. Personally, I'd like to keep rolling things out of the core
>>>> and distribute as much as possible in the form of plugins. Ultimately,
>>>> there should be nothing in the core that doesn't *need* to be in the
>>>> core. My thought would be to include SmartURLs in Struts 2.1.x as the
>>>> successor to the CodeBehind plugin.
>>>>
>>>> -Ted.
>>>>
>>>> On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
>>>>
>>>>> +1 for waiting and rolling it into core, it could be available for 2.1
>>>>>
>>>>> musachy
>>>>>
>>>>> On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>>>>>
>>>>>> I was planning on release 1.0 of SmartURLs in the near future and doing
>>>>>> some announcements to the user lists and some other locations. However,
>>>>>> should I wait on that if favor of rolling this back into core, or should
>>>>>> I go ahead?
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> -bp
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> 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: Should I announce SmartURLs or wait?
Posted by Don Brown <mr...@twdata.org>.
The reason the zero config stuff is in core is mainly because it
requires a configuration provider, which cannot be plugged in via a
struts plugin. Is there any other technical reason that this should
be in core?
Don
On 9/11/07, Musachy Barroso <mu...@gmail.com> wrote:
> IMO this should be a "core" feature of struts 2.
>
> musachy
>
> On 9/10/07, Don Brown <mr...@twdata.org> wrote:
> > Hmm...along those lines, could SmartURL be Codebehind 2.0?
> >
> > As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
> > other things, make OGNL pluggable and fully migrate the code to
> > container injection (no statics!). I should be done sometime this
> > week.
> >
> > Don
> >
> > On 9/11/07, Ted Husted <hu...@apache.org> wrote:
> > > Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
> > > could be out next week, or next month, or next year. There's really no
> > > telling.
> > >
> > > I'm not sure what "rolling it into the core" means. If it means
> > > putting the source into the Struts-Core JAR, then I'd probably be
> > > opposed. Personally, I'd like to keep rolling things out of the core
> > > and distribute as much as possible in the form of plugins. Ultimately,
> > > there should be nothing in the core that doesn't *need* to be in the
> > > core. My thought would be to include SmartURLs in Struts 2.1.x as the
> > > successor to the CodeBehind plugin.
> > >
> > > -Ted.
> > >
> > > On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
> > > > +1 for waiting and rolling it into core, it could be available for 2.1
> > > >
> > > > musachy
> > > >
> > > > On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> > > > >
> > > > > I was planning on release 1.0 of SmartURLs in the near future and doing
> > > > > some announcements to the user lists and some other locations. However,
> > > > > should I wait on that if favor of rolling this back into core, or should
> > > > > I go ahead?
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > -bp
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> 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: Should I announce SmartURLs or wait?
Posted by Musachy Barroso <mu...@gmail.com>.
IMO this should be a "core" feature of struts 2.
musachy
On 9/10/07, Don Brown <mr...@twdata.org> wrote:
> Hmm...along those lines, could SmartURL be Codebehind 2.0?
>
> As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
> other things, make OGNL pluggable and fully migrate the code to
> container injection (no statics!). I should be done sometime this
> week.
>
> Don
>
> On 9/11/07, Ted Husted <hu...@apache.org> wrote:
> > Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
> > could be out next week, or next month, or next year. There's really no
> > telling.
> >
> > I'm not sure what "rolling it into the core" means. If it means
> > putting the source into the Struts-Core JAR, then I'd probably be
> > opposed. Personally, I'd like to keep rolling things out of the core
> > and distribute as much as possible in the form of plugins. Ultimately,
> > there should be nothing in the core that doesn't *need* to be in the
> > core. My thought would be to include SmartURLs in Struts 2.1.x as the
> > successor to the CodeBehind plugin.
> >
> > -Ted.
> >
> > On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
> > > +1 for waiting and rolling it into core, it could be available for 2.1
> > >
> > > musachy
> > >
> > > On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> > > >
> > > > I was planning on release 1.0 of SmartURLs in the near future and doing
> > > > some announcements to the user lists and some other locations. However,
> > > > should I wait on that if favor of rolling this back into core, or should
> > > > I go ahead?
> > > >
> > > > Thoughts?
> > > >
> > > > -bp
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Should I announce SmartURLs or wait?
Posted by Don Brown <mr...@twdata.org>.
Hmm...along those lines, could SmartURL be Codebehind 2.0?
As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
other things, make OGNL pluggable and fully migrate the code to
container injection (no statics!). I should be done sometime this
week.
Don
On 9/11/07, Ted Husted <hu...@apache.org> wrote:
> Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
> could be out next week, or next month, or next year. There's really no
> telling.
>
> I'm not sure what "rolling it into the core" means. If it means
> putting the source into the Struts-Core JAR, then I'd probably be
> opposed. Personally, I'd like to keep rolling things out of the core
> and distribute as much as possible in the form of plugins. Ultimately,
> there should be nothing in the core that doesn't *need* to be in the
> core. My thought would be to include SmartURLs in Struts 2.1.x as the
> successor to the CodeBehind plugin.
>
> -Ted.
>
> On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
> > +1 for waiting and rolling it into core, it could be available for 2.1
> >
> > musachy
> >
> > On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> > >
> > > I was planning on release 1.0 of SmartURLs in the near future and doing
> > > some announcements to the user lists and some other locations. However,
> > > should I wait on that if favor of rolling this back into core, or should
> > > I go ahead?
> > >
> > > Thoughts?
> > >
> > > -bp
>
> ---------------------------------------------------------------------
> 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: Should I announce SmartURLs or wait?
Posted by Ted Husted <hu...@apache.org>.
Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
could be out next week, or next month, or next year. There's really no
telling.
I'm not sure what "rolling it into the core" means. If it means
putting the source into the Struts-Core JAR, then I'd probably be
opposed. Personally, I'd like to keep rolling things out of the core
and distribute as much as possible in the form of plugins. Ultimately,
there should be nothing in the core that doesn't *need* to be in the
core. My thought would be to include SmartURLs in Struts 2.1.x as the
successor to the CodeBehind plugin.
-Ted.
On 9/10/07, Musachy Barroso <mu...@gmail.com> wrote:
> +1 for waiting and rolling it into core, it could be available for 2.1
>
> musachy
>
> On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> >
> > I was planning on release 1.0 of SmartURLs in the near future and doing
> > some announcements to the user lists and some other locations. However,
> > should I wait on that if favor of rolling this back into core, or should
> > I go ahead?
> >
> > Thoughts?
> >
> > -bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Should I announce SmartURLs or wait?
Posted by Musachy Barroso <mu...@gmail.com>.
+1 for waiting and rolling it into core, it could be available for 2.1
musachy
On 9/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
> I was planning on release 1.0 of SmartURLs in the near future and doing
> some announcements to the user lists and some other locations. However,
> should I wait on that if favor of rolling this back into core, or should
> I go ahead?
>
> Thoughts?
>
> -bp
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org