struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Benedict" <pbened...@apache.org>
Subject Re: Should I announce SmartURLs or wait?
Date Thu, 13 Sep 2007 08:57:26 GMT
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 <mrdon@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 <brian@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 <musachy@gmail.com> wrote:
> >
> >
> >  IMO this should be a "core" feature of struts 2.
> >
> > musachy
> >
> > On 9/10/07, Don Brown <mrdon@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 <husted@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 <musachy@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 <brian@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message