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.
*
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
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 are
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,
-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
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
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?
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
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 is
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
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
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 into
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
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,
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
16 matches
Mail list logo
