I opened WW-1700 to cover this.
* https://issues.apache.org/struts/browse/WW-1700
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 2/1/07, Ted Husted <[EMAIL PROTECTED]> wrote:
All release *must* include the license.txt ... and ... all source
files *should* include the header. So, assuming there's a difference
between "must" and "should", I would say that we only need to correct
it in future releases.
* http://apache.org
As it turns out, the new API is being used by the StrutsObjectFactory.
I'll put off rolling 2.0.5 until Sunday, in case anyone has a chance
to look at refactoring the new API out of StrutsObjectFactory.
Worse case, Nial has fixed the license headers, so we can roll it
again either way.
If anyon
OK, I'll try to roll 2.0.5 tonight, so that we can vote over the
weekend, and try to get at least another beta out.
-Ted.
On 2/1/07, Bob Lee <[EMAIL PROTECTED]> wrote:
I'm cool with that. I'm not going to finish it by this weekend--I'm working
feverishly toward a Guice release, and I plan on us
I'm cool with that. I'm not going to finish it by this weekend--I'm working
feverishly toward a Guice release, and I plan on using Guice in the API
anyway (we won't need *Aware interfaces).
Bob
On 2/1/07, Ted Husted <[EMAIL PROTECTED]> wrote:
I tend to agree. Unless someone says they are ready
Ted Husted wrote:
I tend to agree. Unless someone says they are ready, willing, and
ablle to resolve the "new API" this weekend, lets just pull it out and
roll 2.0.5 now.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For a
I tend to agree. Unless someone says they are ready, willing, and
ablle to resolve the "new API" this weekend, lets just pull it out and
roll 2.0.5 now.
We can then slate the "new API" for 2.1.x, along with the AJAX/Dojo plugin.
(Which, I believe, would be *plenty* for a 2.1.x, without getting i
Yeah, I think we really need a commitment from Bob or someone else
willing to really finish this effort. If no one signs up, I'm all for
pull it out into the sandbox. Right now, there are too many duplicate
classes and code that is very confusing as a developer. Personally, I
think this shou
Ted and I disagree on this - I don't believe the intention of that
policy is to make headers for source files optional. If you read the
whole policy document rather than focusing on a single word it seems
pretty clear to me that they are required. For example in the FAQ it
states the following abo
All release *must* include the license.txt ... and ... all source
files *should* include the header. So, assuming there's a difference
between "must" and "should", I would say that we only need to correct
it in future releases.
* http://apache.org/legal/src-headers.html
The rationale for "should
One thing I did notice when looking through the api quickly is that
a lot of the api doesn't have license headers. We should probably fix
that ASAP.
https://issues.apache.org/struts/browse/WW-1698
Does this mean we should stop the current release that's about to go out?
David
Rene Gielen wr
If we are going to do that, then perhaps we should send the new API to
the sandbox, until someone is ready to finish it.
On 2/1/07, David H. DeWolf <[EMAIL PROTECTED]> wrote:
Then should we remove the dependency on the api from core to prevent
confusion?
---
Then should we remove the dependency on the api from core to prevent
confusion?
Rainer Hermanns wrote:
-1, IIRC the API is not yet in place, but shall be the foundation for the
upcoming xwork abstraction.
Who can give us an update on the current API status?
Since the API is not yet implemented
-1, IIRC the API is not yet in place, but shall be the foundation for the
upcoming xwork abstraction.
Who can give us an update on the current API status?
Since the API is not yet implemented at all, I think there is currently no
need to remove anything, before the API has been finalized.
-Rainer
Last I knew, the "new" API was incomplete, and I don't know if we want
to start forcing people to use it before it is complete. The plan was
to leave the old API in place until the new one was done, then
depreciate the old. But, again, I believe the new API is still
incomplete.
-Ted.
On 2/1/07,
On 2/1/07, Rene Gielen <[EMAIL PROTECTED]> wrote:
I doubt this is by intention. ServletConfigInterceptor uses the second
variant, which is IMO bad choice and makes it difficult to remove it in
favor for the api variant, as it will most likely break many users code.
On the other hand, since we ar
Working on the ProxyPrincipal problem, I discovered that we have two
different ServletRequestAware interfaces:
- org.apache.struts2.servlet.ServletRequestAware in api
- org.apache.struts2.interceptor.ServletRequestAware in core
I doubt this is by intention. ServletConfigInterceptor uses the second
17 matches
Mail list logo
