Personally, I feel that struts top to bottom should be web centric and
not try to abstract out JEE. This makes life cumbersome and difficult
in many cases. Often this also leads to hacking interfaces or writing
tricky new semantics on top of more general interfaces in order to get
access to the web APIs. I'd vote for dropping it into core and slowly
rewriting it to be 100% web centric. This is also my feeling about
OGNL/MVEL or any expression language. The expression language for
struts should be written to handle all the crazy cases that come up
with the web, specifically type conversions.
-bp
On Aug 10, 2009, at 11:32 AM, Martin Cooper wrote:
If we bring XWork here and it becomes its own subproject, it will
have its
own release cycle. This will allow people to use XWork independently
of
Struts, but it means there is still a separate release cycle,
independent of
the Struts 2 release cycle. Thus we're in pretty much the same
situation as
we are now, except for the location of the code base.
If we bring it here and embed it within the Struts 2 core, then it
will
become part of the Struts 2 release, but will no longer be available
as an
independent entity. This means it probably will not be usable
outside of
Struts 2, will not be identifiable as an independent entity, and
almost
certainly will lose its identity as a separately usable library.
Which are we trying to do? I am hearing advocates of both
approaches, each
with their own pros and cons...
Also, are all of the existing XWork committers already Struts
committers? If
not, what do we plan to do about that?
--
Martin Cooper
On Wed, Aug 5, 2009 at 10:12 PM, Don Brown <donald.br...@gmail.com>
wrote:
XWork was left at OpenSymphony, because at the time, there were a
number of WebWork developers still around and we wanted to continue
to
work together. Today, WebWork activity seems all but dead, leaving
us
with no advantages having the code hosted over there. Furthermore,
having critical code in different packages is really confusing for
developers of the framework and its apps with no apparent benefit.
Ideally, I'd like to bring xwork trunk into the core jar and be done
with the theoretically useful yet practically painful split.
However,
that would break Struts 2 apps without tedious backwards-
compatibility
code, but getting the code bases integrated is the first step. Maybe
at first, we keep two artifacts, but I think we should think about a
serious migration to just one. XWork itself will always be around,
but trying to put a framework at our core that is meant for ambiguous
theoretical users brings unnecessary complexity and problems to all
parties.
Can I start planning the funeral? :)
Don
On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacher<w...@wantii.com>
wrote:
On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote:
[snip]
I was going to ask if anyone was using it outside struts, but that
doesn't prevent us from making it it's own artifact.
[snip]
I don't think this would fix the problem, which is the duplicated
effort on the builds. A good compromise would be to keep it under
its
own artifact under struts, just like core, that way we would need
just
one release and it could still be used independently. I haven't
cared
much before, but if it will make our releases easier/smoother,
then I
am +1 for it.
being its own artifact makes more sense, it would make releasing
the two
much
easier, on second thought I agree with this. My only real concern
is that
I
can get to it w/o struts. The context I am working with now
doesn't fit
well
with struts, and adding struts means I would have to do even more
work
getting
a base configuration so that xwork can run actions. One example that
sticks out
in my mind is that when I run actions, each action execution gets
its own
thread and one of the results I built for this project launches
from 1 to
infinite more actions. Obviously it wouldn't make sense to chain to
multiple
actions in a web-app and since a view is rendered in struts, having
actions
run in a separate thread wouldn't work well in a web-app.
-W
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
