Re: Struts Validation DTD
Excuse my dropping in the matter... I am not so experienced on the versions of the various jars, but I have got the same problem with struts custom validator, tiles ecc... my question is: is it possible to raise the commons validator version to solve this problem and not to raise also the struts version ? without impacts ? is there a sort of compatibility matrix for the various jars? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] TilesContextFactory refactor
Hmm, I forgot something until I went to implement this approach. . .
It will be nearly impossible to avoid accessing the
TilesApplicationContext in order to create the TilesRequestContext
unless we change a couple of things. The reason is that we currently
provide access to factories through the TilesUtil - which in turn looks
them up in the TilesApplicationContext (previously TilesContext).
This allows the factory instantiation and configuration to be hidden
from the client (external application and/or tag) and done only once for
the life of the application.
In other words, if you'd like to create the TilesRequestContext from the
factory directly, you'll have to do this:
TilesApplicationContext ctx = . . .
TilesRequestContext requestCtx = TilesUtil.createRequestContext(ctx,
req, res);
or this:
TilesApplicationContext ctx = . . .
TilesContextFactory factory = TilesUtil.getContextFactory(ctx);
TilesRequestContext requestCtx = factory.createRequestContext(ctx, req,
res);
One way around this is to cache the TilesApplicationContext within the
TilesUtilImpl. This would allow must simpler invocations such as:
TilesRequestContext context = TilesUtil.createRequestContext(req, res)
The one negative to this approach is that it will eliminate the ability
to support multiple contexts (when tiles is packaged in a common
classloader). The TilesUtil currently appears to be implemented in a
way which suggests that the original intent was to support multiple
contexts. That said, the support is already only partial since Tiles
utilizes several static accessors and instances such as TilesUtilImpl
will be shared across applications.
The second approach that would solve this issue would be to refactor the
codebase to eliminate the prevalent use of static methods. Instead, all
tiles functionality could be configured and encapsulated into a self
contained container which would be cached and retrieved when needed.
In this scenario, the configuration servlet, filter, or listener, would
create the container and provide access to it from a publicly available
place (perhaps the underlying context). Whenever tiles were needed, the
client would retrieve the container and invoke it. Services like the
TilesUtil would be provided by the container, not statically accessed.
I think this latter approach provides the best of both worlds and IMHO
will make things a little simpler. I think it will also give us a
little more flexibility down the road as well.
Interested in your thoughts . . .perhaps there's something here that I'm
missing!
David
David H. DeWolf wrote:
Greg Reddin wrote:
On Oct 18, 2006, at 6:52 AM, David H. DeWolf wrote:
1) TilesContext is refactored into two different contexts -
TilesContext and TilesRequestContext. Only one instance of the
TilesContext should exist within the application and it will be used
to provide application scoped functions (e.g. getResource() or
getInitParameters()) . The TilesRequestContext will provide
request/response specific operations (e.g. include() or
getParameters()).
At first I didn't like the separation, but now I do after looking at
your patch. It makes sense that you would put request-based stuff
into a separate class from application-scoped stuff. I have two small
concerns:
1) The name TilesContext: Perhaps we should change it to
TilesApplicationContext.
Makes sense to me. I'll rename it.
2) How will Tiles be used from other frameworks? Here's an example
from Shale. Shale provides a TilesViewHandler with the following code
(the code is similar to what is used in other frameworks like
Struts2's TilesResult class):
ExternalContext externalContext = FacesContext.getCurrentInstance()
.getExternalContext();
Object request = externalContext.getRequest();
Object context = externalContext.getContext();
ComponentDefinition tile = null;
try {
TilesContext tilesContext =
TilesContextFactory.getInstance(context, request);
tile = TilesUtil.getDefinition(name, tilesContext);
} catch (NoSuchDefinitionException nsex) {
log.error(Couldn't find Tiles definition., nsex);
} catch (DefinitionsFactoryException dex) {
log.error(Tiles error, dex);
}
return tile;
After your refactoring the code above will look like this:
ExternalContext externalContext = FacesContext.getCurrentInstance()
.getExternalContext();
Object request = externalContext.getRequest();
Object context = externalContext.getContext();
ComponentDefinition tile = null;
try {
TilesContextFactory contextFactory = new
BasicTilesContextFactory();
TilesContext tilesContext =
contextFactory.getInstance(context);
TilesRequestContext tilesRequestContext =
Re: [VOTE] Struts 2.0.1 Quality
+1 for beta - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=46988messageID=95481#95481 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax tags
Would something like this include all the current functionality in
BindDiv? (events for stop/start timer, refresh, start after a delay,
advisor via dojo's handler property). This way BindDiv will be easier
to maintain (dojo's ContentPane + timer) and the Tab widget can be
deleted (doesn't add anything to this one). By the way this doesn't work
on AMD 64/firefox/linux due to a dojo's bug.
dojo.provide(struts.widgets.BindDiv);
dojo.require(dojo.widget.*);
dojo.require(dojo.io.*);
dojo.require(dojo.widget.Container);
dojo.require(dojo.widget.ContentPane);
dojo.require(dojo.animation.Timer);
struts.widgets.BindDiv = function() {
dojo.widget.html.ContentPane.call(this);
var self = this;
this.widgetType = BindDiv;
this.href = ;
this.extractContent = false;
this.parseContent = false;
this.cacheContent = false;
this.frequency = 0;
this.delay = 0;
this.startTimer = false;
this.timer = null;
//pub/sub events
this.refreshListenTopics = ;
this.stopTimerListenTopics = ;
this.startTimerListenTopics = ;
this.postCreate = function() {
if(self.frequency 0) {
self.timer = new dojo.animation.Timer(self.frequency);
self.timer.onTick = self.reloadContents;
//start the timer
if(self.startTimer) {
//start after delay
dojo.debug(starting timer after + self.delay);
dojo.lang.setTimeout(self.delay, self.startTimer);
}
}
//attach listeners
if(!dojo.string.isBlank(self.refreshListenTopics)) {
dojo.debug(Listening to + self.refreshListenTopics);
dojo.event.topic.subscribe(self.refreshListenTopics, self,
reloadContents);
}
if(!dojo.string.isBlank(self.stopTimerListenTopics)) {
dojo.debug(Listening to + self.stopTimerListenTopics);
dojo.event.topic.subscribe(self.stopTimerListenTopics, self,
stopTimer);
}
if(!dojo.string.isBlank(self.startTimerListenTopics)) {
dojo.debug(Listening to + self.startTimerListenTopics);
dojo.event.topic.subscribe(self.startTimerListenTopics, self,
startTimer);
}
};
this.reloadContents = function() {
//refresh is not visible in ContentPane
self.isLoaded = false;
self.loadContents();
};
this.stopTimer = function() {
dojo.debug(stopping timer);
self.timer.stop();
};
this.startTimer = function() {
dojo.debug(starting timer with frequency + self.frequency);
self.timer.start();
};
};
dojo.inherits(struts.widgets.BindDiv, dojo.widget.html.ContentPane);
dojo.widget.tags.addParseTreeHandler(dojo:BindDiv);
Musachy Barroso wrote:
I was looking at the Div/Panel classes and I think we need to do some
changes, right now Panel extends Div and PanelTag exteds DivTag. The
problem is that the new PanelTag wraps dojo's ContentPane, while
DivTag wraps HTMLBindDiv(from struts), and they are quite different. I
think we should replace HTMLBindDiv with an implementation that
extends dojo's ContentPane and add a timer to it for the auto refresh.
what do you guys think?
musachy
Ian Roughley wrote:
Yes - this was the direction that we wanted to go in. Try to do as
much as possible in dojo and provide light wrappers in Struts. When
we first implemented the tabs, there was no such dojo
implementation. The one feature that we had that you should check
that has been implemented in dojo is the pub/sub events - so there
should be events that each tabs listens to to refresh itself.
I think as Don pointed out, we want to keep a very lightweight
wrapper in struts and have all the work being done in dojo.
The other big thing that would be a great help is converting the code
from dojo 0.2 to 0.3 :)
Ian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
Excellent, with my +1 beta, that makes three binding and two supporting votes. Unless there is a rash of -1s over the next day, I'll make the user list announcement on Monday. Meanwhile, are we close to a stable XWork 2 release? I believe a stable XWork 2 is the only thing keeping us form a a GA Struts 2 release. Hey, are plugins a S2 thing, or does XWork 2 support plugins too? -Ted. On 10/21/06, Rainer Hermanns [EMAIL PROTECTED] wrote: [ X ] +1 Beta grade for 2.0.1 all - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
apache.org being down prevents me from using Struts 2
Is it possible to change the Struts 2.0.1 pom so it loads xwork from repo1.maven.org instead of people? I just started getting the following error from CruiseControl today. I'm guessing this is caused by the Struts pom, but I could be wrong. [INFO] Installing /opt/openlogic/blueglue/cruisecontrol-bin-2.5/projects/appfuse-2.x/web/spring/target/appfuse-spring-2.0-SNAPSHOT.war to /home/mraible/.m2/repository/org/appfuse/appfuse-spring/2.0-SNAPSHOT/appfuse-spring-2.0-SNAPSHOT.war [INFO] [INFO] Building AppFuse Struts 2 Module [INFO] task-segment: [install] [INFO] Downloading: http://people.apache.org/maven-snapshot-repository/opensymphony/xwork/2.0-beta-1/xwork-2.0-beta-1.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: opensymphony:xwork Reason: Error getting POM for 'opensymphony:xwork' from the repository: Error transferring file opensymphony:xwork:pom:2.0-beta-1 from the specified remote repositories: central (http://repo1.maven.org/maven2), maven-snapshots (http://people.apache.org/maven-snapshot-repository), appfuse (http://static.appfuse.org/repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 6 minutes 56 seconds [INFO] Finished at: Sat Oct 21 15:48:14 MDT 2006 [INFO] Final Memory: 52M/94M [INFO] Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Duplicate Aware Interfaces
Both the API and the Core modules have defined the Aware interfaces (RequestAware, ResponseAware, and ParamaterAware). Only the versions in the core module are actually used by the interceptor. I would suggest that we do one of three things: 1) Remove the interfaces defined in org.apache.struts2.servlet (in the api module) to avoid confusion 2) Refactor the ServletConfigInterceptor to use the org.apache.struts2.servlet interfaces defined in the api module and remove the org.apache.struts2.interpceptor interfaces (in the core module). 3) Use reflection to determine whether or not to set the request. In this case I would suggest removing the core interfaces and leaving the api interfaces for convenience (just as we have an Action interface for convenience). Am I right that this duplication is simply oversight? Anyone have any preference as to which option I use to rectify it? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplicate Aware Interfaces
Talk to Bob Lee. He is in the middle of creating a new API that would replace how Struts 2 apps currently interact with the framework. In that work, he is creating new Struts interfaces, many of which simply wrap xwork ones so that a Struts 2 application wouldn't be tied to or even know about xwork. The interfaces you bring up are part of that conversion, already in progess. Don On 10/23/06, David H. DeWolf [EMAIL PROTECTED] wrote: Both the API and the Core modules have defined the Aware interfaces (RequestAware, ResponseAware, and ParamaterAware). Only the versions in the core module are actually used by the interceptor. I would suggest that we do one of three things: 1) Remove the interfaces defined in org.apache.struts2.servlet (in the api module) to avoid confusion 2) Refactor the ServletConfigInterceptor to use the org.apache.struts2.servlet interfaces defined in the api module and remove the org.apache.struts2.interpceptor interfaces (in the core module). 3) Use reflection to determine whether or not to set the request. In this case I would suggest removing the core interfaces and leaving the api interfaces for convenience (just as we have an Action interface for convenience). Am I right that this duplication is simply oversight? Anyone have any preference as to which option I use to rectify it? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax tags
Have you tried this with the Dojo 0.4 release? Any reason we shouldn't
upgrade to it?
Don
Musachy Barroso wrote:
Would something like this include all the current functionality in
BindDiv? (events for stop/start timer, refresh, start after a delay,
advisor via dojo's handler property). This way BindDiv will be
easier to maintain (dojo's ContentPane + timer) and the Tab widget can
be deleted (doesn't add anything to this one). By the way this doesn't
work on AMD 64/firefox/linux due to a dojo's bug.
dojo.provide(struts.widgets.BindDiv);
dojo.require(dojo.widget.*);
dojo.require(dojo.io.*);
dojo.require(dojo.widget.Container);
dojo.require(dojo.widget.ContentPane);
dojo.require(dojo.animation.Timer);
struts.widgets.BindDiv = function() {
dojo.widget.html.ContentPane.call(this);
var self = this;
this.widgetType = BindDiv;
this.href = ;
this.extractContent = false;
this.parseContent = false;
this.cacheContent = false;
this.frequency = 0;
this.delay = 0;
this.startTimer = false;
this.timer = null;
//pub/sub events
this.refreshListenTopics = ;
this.stopTimerListenTopics = ;
this.startTimerListenTopics = ;
this.postCreate = function() {
if(self.frequency 0) {
self.timer = new dojo.animation.Timer(self.frequency);
self.timer.onTick = self.reloadContents;
//start the timer
if(self.startTimer) {
//start after delay
dojo.debug(starting timer after + self.delay);
dojo.lang.setTimeout(self.delay, self.startTimer);
}
}
//attach listeners
if(!dojo.string.isBlank(self.refreshListenTopics)) {
dojo.debug(Listening to + self.refreshListenTopics);
dojo.event.topic.subscribe(self.refreshListenTopics, self,
reloadContents);
}
if(!dojo.string.isBlank(self.stopTimerListenTopics)) {
dojo.debug(Listening to + self.stopTimerListenTopics);
dojo.event.topic.subscribe(self.stopTimerListenTopics, self,
stopTimer);
}
if(!dojo.string.isBlank(self.startTimerListenTopics)) {
dojo.debug(Listening to + self.startTimerListenTopics);
dojo.event.topic.subscribe(self.startTimerListenTopics, self,
startTimer);
}
};
this.reloadContents = function() {
//refresh is not visible in ContentPane
self.isLoaded = false;
self.loadContents();
};
this.stopTimer = function() {
dojo.debug(stopping timer);
self.timer.stop();
};
this.startTimer = function() {
dojo.debug(starting timer with frequency + self.frequency);
self.timer.start();
};
};
dojo.inherits(struts.widgets.BindDiv, dojo.widget.html.ContentPane);
dojo.widget.tags.addParseTreeHandler(dojo:BindDiv);
Musachy Barroso wrote:
I was looking at the Div/Panel classes and I think we need to do some
changes, right now Panel extends Div and PanelTag exteds DivTag. The
problem is that the new PanelTag wraps dojo's ContentPane, while
DivTag wraps HTMLBindDiv(from struts), and they are quite different.
I think we should replace HTMLBindDiv with an implementation that
extends dojo's ContentPane and add a timer to it for the auto refresh.
what do you guys think?
musachy
Ian Roughley wrote:
Yes - this was the direction that we wanted to go in. Try to do as
much as possible in dojo and provide light wrappers in Struts. When
we first implemented the tabs, there was no such dojo
implementation. The one feature that we had that you should check
that has been implemented in dojo is the pub/sub events - so there
should be events that each tabs listens to to refresh itself.
I think as Don pointed out, we want to keep a very lightweight
wrapper in struts and have all the work being done in dojo.
The other big thing that would be a great help is converting the
code from dojo 0.2 to 0.3 :)
Ian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
Ted Husted wrote: Excellent, with my +1 beta, that makes three binding and two supporting votes. Unless there is a rash of -1s over the next day, I'll make the user list announcement on Monday. Meanwhile, are we close to a stable XWork 2 release? I believe a stable XWork 2 is the only thing keeping us form a a GA Struts 2 release. Hey, are plugins a S2 thing, or does XWork 2 support plugins too? The ability to create a plugins-type system is available in XWork 2, but the plugin system itself is a part of Struts 2. Don -Ted. On 10/21/06, Rainer Hermanns [EMAIL PROTECTED] wrote: [ X ] +1 Beta grade for 2.0.1 all - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
[ X ] +1 Beta grade for 2.0.1 all Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
Somewhat related (but mostly not) What parts (if any) of the new API (The bob_lee_api) will be in 2.0.1 (final)? Cheers, Eric On 10/23/06, Rene Gielen [EMAIL PROTECTED] wrote: [ X ] +1 Beta grade for 2.0.1 all Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplicate Aware Interfaces
Excellent, I'm glad I asked. I'll just let it be for now. . . David Don Brown wrote: Talk to Bob Lee. He is in the middle of creating a new API that would replace how Struts 2 apps currently interact with the framework. In that work, he is creating new Struts interfaces, many of which simply wrap xwork ones so that a Struts 2 application wouldn't be tied to or even know about xwork. The interfaces you bring up are part of that conversion, already in progess. Don On 10/23/06, David H. DeWolf [EMAIL PROTECTED] wrote: Both the API and the Core modules have defined the Aware interfaces (RequestAware, ResponseAware, and ParamaterAware). Only the versions in the core module are actually used by the interceptor. I would suggest that we do one of three things: 1) Remove the interfaces defined in org.apache.struts2.servlet (in the api module) to avoid confusion 2) Refactor the ServletConfigInterceptor to use the org.apache.struts2.servlet interfaces defined in the api module and remove the org.apache.struts2.interpceptor interfaces (in the core module). 3) Use reflection to determine whether or not to set the request. In this case I would suggest removing the core interfaces and leaving the api interfaces for convenience (just as we have an Action interface for convenience). Am I right that this duplication is simply oversight? Anyone have any preference as to which option I use to rectify it? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
The API is there, but I don't believe it is fully implemented yet. Don Eric Molitor wrote: Somewhat related (but mostly not) What parts (if any) of the new API (The bob_lee_api) will be in 2.0.1 (final)? Cheers, Eric On 10/23/06, Rene Gielen [EMAIL PROTECTED] wrote: [ X ] +1 Beta grade for 2.0.1 all Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
Let's see. The API is already being used to an extent, but I believe there is remaining work to do. The 2.0.1 distribution is already in its final form. The only question is the quality grade. Right now, it's heading toward beta, and it will probably be stuck there since it has a dependency on XWork2-beta-1. If another distribution in the 2.0.x milestone series is graded General Availablility that doesn't put an end to the series. It just means it's unlikely that we would break backward compatability in a subsequent distribution in that milestone series. If we did need to break compatabiltiy, we would increment the minor version number and go onto the 2.1.x series. The API was deemed optional for the Struts 2.0.x series, so we can implement as much or as little as we like, so long as there are volunteers willing to do the work. Personally, right now, I'm frying other fish, but I suspect other volunteers might be interested in pushing forward. -Ted. On 10/23/06, Eric Molitor [EMAIL PROTECTED] wrote: Somewhat related (but mostly not) What parts (if any) of the new API (The bob_lee_api) will be in 2.0.1 (final)? Cheers, Eric On 10/23/06, Rene Gielen [EMAIL PROTECTED] wrote: [ X ] +1 Beta grade for 2.0.1 all Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplicate Aware Interfaces
Or, jump in and help with the new API. It's been a work in progress for some time now. -Ted. On 10/23/06, David H. DeWolf [EMAIL PROTECTED] wrote: Excellent, I'm glad I asked. I'll just let it be for now. . . David Don Brown wrote: Talk to Bob Lee. He is in the middle of creating a new API that would replace how Struts 2 apps currently interact with the framework. In that work, he is creating new Struts interfaces, many of which simply wrap xwork ones so that a Struts 2 application wouldn't be tied to or even know about xwork. The interfaces you bring up are part of that conversion, already in progess. Don On 10/23/06, David H. DeWolf [EMAIL PROTECTED] wrote: Both the API and the Core modules have defined the Aware interfaces (RequestAware, ResponseAware, and ParamaterAware). Only the versions in the core module are actually used by the interceptor. I would suggest that we do one of three things: 1) Remove the interfaces defined in org.apache.struts2.servlet (in the api module) to avoid confusion 2) Refactor the ServletConfigInterceptor to use the org.apache.struts2.servlet interfaces defined in the api module and remove the org.apache.struts2.interpceptor interfaces (in the core module). 3) Use reflection to determine whether or not to set the request. In this case I would suggest removing the core interfaces and leaving the api interfaces for convenience (just as we have an Action interface for convenience). Am I right that this duplication is simply oversight? Anyone have any preference as to which option I use to rectify it? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
Whether we finalize the API or scrap it for GA doesn't really matter to me. What concerns me is the fact that the state it's in right now is rather confusing to the developer. Once I get through a few tiles and other issues I'm working with right now, I'll be willing to dive into the API stuff. David Ted Husted wrote: Let's see. The API is already being used to an extent, but I believe there is remaining work to do. The 2.0.1 distribution is already in its final form. The only question is the quality grade. Right now, it's heading toward beta, and it will probably be stuck there since it has a dependency on XWork2-beta-1. If another distribution in the 2.0.x milestone series is graded General Availablility that doesn't put an end to the series. It just means it's unlikely that we would break backward compatability in a subsequent distribution in that milestone series. If we did need to break compatabiltiy, we would increment the minor version number and go onto the 2.1.x series. The API was deemed optional for the Struts 2.0.x series, so we can implement as much or as little as we like, so long as there are volunteers willing to do the work. Personally, right now, I'm frying other fish, but I suspect other volunteers might be interested in pushing forward. -Ted. On 10/23/06, Eric Molitor [EMAIL PROTECTED] wrote: Somewhat related (but mostly not) What parts (if any) of the new API (The bob_lee_api) will be in 2.0.1 (final)? Cheers, Eric On 10/23/06, Rene Gielen [EMAIL PROTECTED] wrote: [ X ] +1 Beta grade for 2.0.1 all Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
Sorry, I'm not being clear. A GA tag on a distribution in the 2.0.x series will have no affect on the new API. The API is marked optional, and work can continue, and further distributions made in the 2.0.x series, regardless of how much work is, or isn't, being done. We had several GA release in the 1.2.x series, and many new features were added along the way. One of the triggers for the 2.1.x series might be that the new API becomes ready for primetime, and that we are ready to make it the default. But there can be several 2.0.x GA releases in the meantime. -Ted. On 10/23/06, David H. DeWolf [EMAIL PROTECTED] wrote: Whether we finalize the API or scrap it for GA doesn't really matter to me. What concerns me is the fact that the state it's in right now is rather confusing to the developer. Once I get through a few tiles and other issues I'm working with right now, I'll be willing to dive into the API stuff. David Ted Husted wrote: Let's see. The API is already being used to an extent, but I believe there is remaining work to do. The 2.0.1 distribution is already in its final form. The only question is the quality grade. Right now, it's heading toward beta, and it will probably be stuck there since it has a dependency on XWork2-beta-1. If another distribution in the 2.0.x milestone series is graded General Availablility that doesn't put an end to the series. It just means it's unlikely that we would break backward compatability in a subsequent distribution in that milestone series. If we did need to break compatabiltiy, we would increment the minor version number and go onto the 2.1.x series. The API was deemed optional for the Struts 2.0.x series, so we can implement as much or as little as we like, so long as there are volunteers willing to do the work. Personally, right now, I'm frying other fish, but I suspect other volunteers might be interested in pushing forward. -Ted. On 10/23/06, Eric Molitor [EMAIL PROTECTED] wrote: Somewhat related (but mostly not) What parts (if any) of the new API (The bob_lee_api) will be in 2.0.1 (final)? Cheers, Eric On 10/23/06, Rene Gielen [EMAIL PROTECTED] wrote: [ X ] +1 Beta grade for 2.0.1 all Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Should we submit 2.0.1 for mirroring (was Re: [VOTE] Struts 2.0.1 Quality)
Late last week there were issues with Minotaur's RAID. It survived the move to Portland, but I don't know if it's back up to snuff yet. It's only our first S2 beta, but should we submit 2.0.1 for mirroring to take some of the heat off Minotaur? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Should we submit 2.0.1 for mirroring (was Re: [VOTE] Struts 2.0.1 Quality)
+1 Ted Husted wrote: Late last week there were issues with Minotaur's RAID. It survived the move to Portland, but I don't know if it's back up to snuff yet. It's only our first S2 beta, but should we submit 2.0.1 for mirroring to take some of the heat off Minotaur? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Should we submit 2.0.1 for mirroring (was Re: [VOTE] Struts 2.0.1 Quality)
On 10/23/06, Ted Husted [EMAIL PROTECTED] wrote: Late last week there were issues with Minotaur's RAID. It survived the move to Portland, but I don't know if it's back up to snuff yet. It's only our first S2 beta, but should we submit 2.0.1 for mirroring to take some of the heat off Minotaur? I have no problem with that, especially since it's now a Beta release. -- Martin Cooper -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Should we submit 2.0.1 for mirroring (was Re: [VOTE] Struts 2.0.1 Quality)
+1 -- James Mitchell 678.910.8017 On Oct 23, 2006, at 8:21 PM, Ted Husted wrote: Late last week there were issues with Minotaur's RAID. It survived the move to Portland, but I don't know if it's back up to snuff yet. It's only our first S2 beta, but should we submit 2.0.1 for mirroring to take some of the heat off Minotaur? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
