[OT] HaD -- solution hot deploy framework for classes
I figured out how to efficiently do the HaD for classes. Not too hard
actually. This will allow key framework classes to be hot deployed
and will act as a simpler, though how effective remains to be seen,
way to solve the problem IoC is presently used to solve through
dependency injection. The solution is at
http://131.191.32.112:8080/classes.zip . Essentially it is a simple
wrapper solution. I suggest that those interested have a look. There
is a test class to run it and see what is up.
The PointFactory actually can be generalized for all classes when
Sun's Tiger is out with the generic capabilities. The main classes
are given below.
I find hot deploy at least a very interesting if not a real (and I
suspect a real) possibility and hope that the mavens on the list will
not mind me expressing my view. This is the only place I know to do
it, other than the forest, and that creates all those philosophical
problems. I think calling this [OT] and relegating it to the level of
Friday beer conversations should appease those who find this sort of
discussion noisy.
Peace,
Jack
package com.crackwillow.deploy;
import java.io.Serializable;
import com.crackwillow.state.StateContainer;
public interface Point
extends Serializable {
public intgetId();
public intgetX();
public intgetY();
public void move(int dx, int dy);
//- DEPLOY UTILITIES --
public StateContainer getState();
public void setState(StateContainer state);
}
package com.crackwillow.deploy;
import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.Iterator;
import java.util.Set;
import java.util.WeakHashMap;
import com.crackwillow.constant.SiteConstant;
import com.crackwillow.deploy.Point;
import com.crackwillow.id.Id;
public class PointFactory {
private transient static WeakHashMap references = new WeakHashMap();
private static ClassLoader pointClassLoader;
private static Class pointClass;
public static synchronized void setObject(Id id) {
// Clear references that are cut loose.
System.gc();
references.put(id,createPoint(null));
}
public static synchronized Point getObject(Id id) {
Point point = (Point)references.get(id);
return point;
}
public static synchronized Point createPoint(Point existingPoint) {
if (pointClass == null) { loadImpl(); }
Point newPoint = null;
try {
newPoint = (Point) pointClass.newInstance();
} catch(InstantiationException ie) {
ie.printStackTrace();
} catch(IllegalAccessException iae) {
iae.printStackTrace();
}
if (existingPoint != null) {
newPoint.move(existingPoint.getX(), existingPoint.getY());
}
return newPoint;
}
public static synchronized void loadImpl() {
try {
pointClassLoader = new URLClassLoader(new URL[] { new
URL(SiteConstant.DEPLOY) });
} catch (MalformedURLException mue) {
mue.printStackTrace();
}
try {
pointClass =
pointClassLoader.loadClass(com.crackwillow.deploy.PointImpl);
} catch (ClassNotFoundException cnfe) {
cnfe.printStackTrace();
}
System.out.println(references);
Set set = references.keySet();
Iterator iter = set.iterator();
while(iter.hasNext()) {
Id id = (Id)iter.next();
if(id != null) {
Point point = (Point)references.get(id);
point = PointFactory.createPoint(point);
references.put(id,point);
}
}
}
}
package com.crackwillow.point;
import com.crackwillow.deploy.PointFactory;
import com.crackwillow.id.Id;
public class Point {
public Point() {
PointFactory.setObject(id = new Id());
}
public int getX() {
return getObject(id).getX();
}
public int getY() {
return getObject(id).getY();
}
public void move(int dx, int dy) {
getObject(id).move(dx,dy);
}
//- DEPLOY UTILITIES --
private final Id id;
private com.crackwillow.deploy.Point getObject(Id id) {
return PointFactory.getObject(id);
}
}
package com.crackwillow.deploy;
import java.util.Collections;
import java.util.Map;
import java.util.Set;
import com.crackwillow.state.StateContainer;
public class PointImpl
implements Point {
public static int mainId;
public int id;
private int x;
private int y;
public PointImpl() {
mainId += 1;
id = mainId;
}
public int getId() {
return id;
}
public int getX() { return x; }
public int getY() { return y; }
public void move(int dx, int dy) {
// Change these to test hot deploy
x += dx;
y += dy;
}
public boolean equals(Object object) {
if(!(object instanceof PointImpl)) {
return false;
} else {
return (id == ((PointImpl)object).id);
}
}
public int hashCode() {
return id;
}
public int compareTo(Object object) {
if(id
Re: Object configuration and ... JMX dreaming
Yes Vic, good idea ;-). Resin also has a quick JMX tutorial: http://www.caucho.com/resin-3.0/jmx/tutorial/basic/index.xtp It look like IoC to me. .V Vic wrote: We have talked CoR, IoC... but not yet JMX/Modeler. Tomcat 5.5 has JMX. If any singleton types are in the registry, and we get them from registry. It's a big chunk to bite of. I still do not know how to use JMX, but . . . What if there was a way that object in the Chain XML Catalog commands where imeditely in modeler Registry transparently? So CoR is... JMX-able? The benfit is that it can be monitored, like how many sessions, and bla bla. Or at least enable users to build monitored applications. (Like Tomcat 5.5, even on the main menu has monitoring) Modeler does not have much configration code AFAIK, it's just a registry for monitoring AFAIK. It' just an idea and I know... code. (I am sure Tomcat 5.5 has something) I will post some large SoA/dispacher contraption in 10 days or so (on my site). .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Object configuration and ... JMX dreaming
At 5:45 AM -0600 12/3/04, Vic wrote: Yes Vic, good idea ;-). Resin also has a quick JMX tutorial: To save you from talking to yourself ;-), I think JMX instrumentation for Struts is a very cool idea. Then again, I can't describe any specific use cases for it myself at the moment. I'm sure I could come up with some given some time. Maybe folks can start articulating some (perhaps in the Wiki) so that the idea can take shape... Joe http://www.caucho.com/resin-3.0/jmx/tutorial/basic/index.xtp It look like IoC to me. .V Vic wrote: We have talked CoR, IoC... but not yet JMX/Modeler. Tomcat 5.5 has JMX. If any singleton types are in the registry, and we get them from registry. It's a big chunk to bite of. I still do not know how to use JMX, but . . . What if there was a way that object in the Chain XML Catalog commands where imeditely in modeler Registry transparently? So CoR is... JMX-able? The benfit is that it can be monitored, like how many sessions, and bla bla. Or at least enable users to build monitored applications. (Like Tomcat 5.5, even on the main menu has monitoring) Modeler does not have much configration code AFAIK, it's just a registry for monitoring AFAIK. It' just an idea and I know... code. (I am sure Tomcat 5.5 has something) I will post some large SoA/dispacher contraption in 10 days or so (on my site). .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: keeping Eclipse files in our repo [was Re: Package removal with new Digester]
--- Matt Bathje [EMAIL PROTECTED] wrote: David Graham wrote: Eclipse classpath variables don't solve the issue because each developer may be using different variable names. Further, the name of the jar file may be different (ie. have version number in it). In my experience, forcing developers to use the one true setup is a recipe for disaster. This is off topic now so I'm sorry to continue it, but I'm not sure I get your point here. Why would a developer use different variable names? If .classpath/.project for eclipse were included, there must be documentation saying you must setup VARIABLEX to point to RESOURCEX and so forth. IMO, dictating the one true way to setup your IDE (including variable names) is a bad idea. Are you worried that people won't read the documentation? Or that multiple variables may point to the same resource? I would rather write code than reading a bunch of documentation telling me I setup my IDE incorrectly :-). I also don't get why it matters that the name of the jar files may be different. That is the point of the variables. If I have variablex pointing to: c:/matt/struts/libs/resource1.2.3.jar and you have variablex pointing to: c:/david/struts/libs/resourceABC.jar For some reason I was thinking you would setup a variable to the directory the jar was in and then extend the variable with the jar's name. But you would just point the variable to the full jar path as in your example. it doesn't matter as far as I know. One of the developers here compiled his own copy of junit with some specialized stuff in it that I didn't know about for a long time, mostly because we use variables to point to the junit jar :) I do think there would be problems with people forgetting to update a variable to point to the proper version of a resource...but your arguments aren't making sense to me. This problem is completely avoided if you put the jars in a lib directory in your project's cvs/svn repo. No classpath variables, no ant build.properties files, no conflicting jar versions, etc. David Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts API Bean (was Spring dreaming)
--- Ted Husted [EMAIL PROTECTED] wrote: The problem is that one developer's litter is another developer's treasure :) Right now, a lot of components are already pointing to the components we've scattered about the contexts. If we just move them into our own context, then those references would break. To create a migration path, we'd first have to provide an ViewContext to replace direct access to the components, deprecate direct acess, and then, in a future release, move the components our own state mechanism. I like the one api bean approach because then you don't have to remember the names of the objects to lookup in the context. You just remember one name and get the rest from that bean. We don't need a migration path if we do this for 2.0, only for the 1.x series. I'm not sure which series you were planning on doing this in though? David -Ted. On Thu, 02 Dec 2004 09:35:47 -0800, Don Brown wrote: I agree with everything you wrote, however, what I was specifically talking about was some sort of storage bean that all the global Struts components could be stored in, so we don't have all these Struts objects littering the servlet context. Yes, for each request, a ViewContext instance would be created, initialized with this storage bean. Don Ted Husted wrote: The public API bean (where the rubber meets the road) could * not* be stored in application scope, since some of the Struts resources are request and session based. The original idea was the ViewContext (fka ConfigHelper) would be created on a per-request basis (like a Velocity tool). The ViewContext might hold references to members in request, session, or application scope, but the ViewContext client doesn't need to know that. All of the tags and tools can then refer to the ViewContext, rather than having to know where all the bodies are buried. The ViewContext interface could be based on the Velocity tools APIs (http://jakarta.apache.org/velocity/tools/struts/). I worked with these guys initially, and they are very tough about defining what you need, but no more. Internally, we might want to define an ActionContext that provides the same utility as the Action class and would also include the properties from the ActionForm. The idea being you could recode an Action class to use an ActionContext just by changing the references. Aside from the Action, we might also define a ResourceContext subset that could be shared with the business layer. The ResourceContext would include the messaging methods, so that the business layer could create Commons Resources messages (as part of a Command) and return them to Struts. This is an interface that we might define as part of the Commons Resources project, so that it is not tainted as a Struts import. Of course, the ActionContext would implement ResourceContext, so that we can exchange the same object with the business layer. All of these interfaces would implement Commons Chain Context (hence the suffix). The ActionContext could be called from an ActionCommand interface, a Chain Command-like interface with one method: void Execute(ActionContext context) Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API. I would suggest we implement these interfaces as experimental in 1.3.x, so that we can work with them ourselves for a while. In 1.4.x, we could do things like refactor for Spring, and then finalize the new interfaces in 1.5.x. I know I should reduce this to code, but I'm away this week, and trying to keep a few balls in the air until I get back. Eventually, we may to put a collection of Controller beans in application scope, open per module. This might be a place where a BeanFactory might be useful, but I think there are some other issues we need to iron out first. (Else start the revolution!) -Ted. On Tue, 30 Nov 2004 16:00:49 -0800, Don Brown wrote: On the topic of a Struts API bean, I completely agree. We should have one bean, probably actually stored in the servlet context, which contains references to all the Struts-specific components like configuration elements and message resources. Now this, and the Spring topic, do overlap since this API bean could actually be a Spring BeanFactory which might be a more flexible approach actually. This would be separate from the ActionContext idea which would hold references to objects necessary for the execution of actions (chain context, http request/response, all current Action helper methods, etc). Ted, in fact, suggested an API bean previously as well, and I believe has even started sketching out what one might look like. Don Joe Germuska wrote: While I'm one who has had good experiences with Spring's BeanFactory for managing my business objects, maybe we
Re: [OT] Re: keeping Eclipse files in our repo [was Re: Package removal with new Digester]
David Graham wrote: --- Matt Bathje [EMAIL PROTECTED] wrote: Why would a developer use different variable names? If .classpath/.project for eclipse were included, there must be documentation saying you must setup VARIABLEX to point to RESOURCEX and so forth. IMO, dictating the one true way to setup your IDE (including variable names) is a bad idea. Are you worried that people won't read the documentation? Or that multiple variables may point to the same resource? I would rather write code than reading a bunch of documentation telling me I setup my IDE incorrectly :-). Fair enough :) Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts API Bean (was Spring dreaming)
At 7:18 AM -0800 12/3/04, David Graham wrote: I like the one api bean approach because then you don't have to remember the names of the objects to lookup in the context. You just remember one name and get the rest from that bean. We don't need a migration path if we do this for 2.0, only for the 1.x series. I'm not sure which series you were planning on doing this in though? I think it should definitely be a clear design constraint on anything 2.0, but I'd like to try to do it on 1.x too. I don't think that's *too* hard, since in most cases, Struts is doing the writing, especially to the Servlet context. I'm going to keep thinking about it and talking about it on the dev list, though. To be honest, my cycles aren't going to be going into a 2.0 revolution too soon; I'm expecting to stay focused on pushing Struts 1.x forward for a while. My personal top priority is the chain request processor. Other near term things I'm thinking about are: * small changes to take advantage of our agreement on the move to Servlet 2.3 -- especially nesting exceptions anywhere they are caught and a JSP or ServletException are thrown. That should make debugging a bit easier. * adding the properties to ActionConfig (hopefully this weekend. I'll do this on 1.3 and not worry about fitting it into the 1.2 branch. I realized the digester rules to achieve the config syntax Martin proposed will be a bit wonky, but not a stopper) * providing an ActionForm method which returns ActionMessages from a validation method so we can push ahead on fully deprecating ActionErrors. (Also 1.3. I'll mention the strategy in another thread to help it be seen...) Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.2.6 Quality
At 10:51 PM -0800 12/2/04, Martin Cooper wrote: My own vote... Beta. While a number of issues have been reported, my opinion is that #32490 is enough to preclude GA, since I believe we need to have the tag libraries in sync for a GA release. I agree: Beta. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32515] New: - missing dependency in maven.xml for struts-el
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32515. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32515 Summary: missing dependency in maven.xml for struts-el Product: Struts Version: Nightly Build Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P3 Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] one of the test classes (DOMHelper.java) references org.apache.xpath so the dependency for xalan needs to be added project.xml. I chose 2.5.1 because that is the latest on ibiblio. dependency groupIdxalan/groupId artifactIdxalan/artifactId version2.5.1/version urlhttp://xml.apache.org/xalan-j/url /dependency -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32515] - missing dependency in maven.xml for struts-el
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32515. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32515 --- Additional Comments From [EMAIL PROTECTED] 2004-12-03 17:52 --- Created an attachment (id=13640) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13640action=view) dependency for project.xml in struts-el project -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ActionForm.validateForm(...) to replace ActionForm.validate(...)
In order to push forward on full deprecation of ActionErrors, I
propose adding the following method to ActionForm:
public ActionMessages validateForm(ActionMapping mapping,
HttpServletRequest request) {
return validate(mapping, request);
}
and then changing one line in the Request Processing chain:
ActionMessages errors = form.validate(mapping, request);
to
ActionMessages errors = form.validateForm(mapping, request);
I'm not sure now why we haven't done this earlier. Someone suggested
it on one of the lists a while ago and it seemed clear once I saw it,
but I haven't had time to do anything about it.
My inclination is to do this only on the 1.3 (HEAD) branch, and to
make the change in RequestProcessor.java even though it is slated for
obsolescence, and then also to make the change in
o.a.s.chain.AbstractValidateActionForm (which actually still uses
ActionErrors, actually.)
If it didn't seem strange that it hasn't been done already, I might
have just gone ahead and done it without raising the question -- so
I'm wondering if I'm missing something?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Fw: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Joe, fyi.this was in moderation.
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message -
From: Joe Germuska [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 03, 2004 10:59 AM
Subject: ActionForm.validateForm(...) to replace ActionForm.validate(...)
In order to push forward on full deprecation of ActionErrors, I
propose adding the following method to ActionForm:
public ActionMessages validateForm(ActionMapping mapping,
HttpServletRequest request) {
return validate(mapping, request);
}
and then changing one line in the Request Processing chain:
ActionMessages errors = form.validate(mapping, request);
to
ActionMessages errors = form.validateForm(mapping, request);
I'm not sure now why we haven't done this earlier. Someone suggested
it on one of the lists a while ago and it seemed clear once I saw it,
but I haven't had time to do anything about it.
My inclination is to do this only on the 1.3 (HEAD) branch, and to
make the change in RequestProcessor.java even though it is slated for
obsolescence, and then also to make the change in
o.a.s.chain.AbstractValidateActionForm (which actually still uses
ActionErrors, actually.)
If it didn't seem strange that it hasn't been done already, I might
have just gone ahead and done it without raising the question -- so
I'm wondering if I'm missing something?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsBuildingFromSourceUsingEclipse
Date: 2004-12-03T09:12:51 Editor: HalDeadman [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsBuildingFromSourceUsingEclipse URL: http://wiki.apache.org/struts/StrutsBuildingFromSourceUsingEclipse no comment Change Log: -- @@ -1,3 +1,5 @@ + * StrutsBuildingFromSourceWithEclipseMavenSubversion - How to setup struts in Eclipse now that code is in Subversion repository. + To get the Struts 1.1 source to compile as a project in Eclipse use the following guide: 1) From the CVS perspective, create a new repository pointing at the Apache CVS server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] New: StrutsBuildingFromSourceWithEclipseMavenSubversion
Date: 2004-12-03T09:59:16
Editor: HalDeadman [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: StrutsBuildingFromSourceWithEclipseMavenSubversion
URL:
http://wiki.apache.org/struts/StrutsBuildingFromSourceWithEclipseMavenSubversion
no comment
New Page:
##language:en
=== Prerequisites ===
You should have the following software installed:
* [http://www.eclipse.org/ Eclipse] - Popular Development Platform
* [http://subclipse.tigris.org/ Subclipse] - Eclipse Plugin that provides
Subversion repository access
* [http://maven.apache.org/ Maven] - Project build tool capable of downloading
dependent jars and creating eclipse config files.
=== Overview ===
1. Install Eclipse 3.0.1
1. Install Subclipse Plugin (0.9.24+)
* In Eclipse under Help menu, Software Updates-Find and Install-Search for
new features to install
* Add remote site name Subclipse with this URL:
http://subclipse.tigris.org/update
* Follow steps in wizard
1. Install Maven
* make sure maven.bat is in PATH
1. Import Team Project Set xml file (see contents below)
* see contents of XML listed inline in this Wiki
* Team Project Set functionality in Eclipse is under File-Import-Team
Project Set
* importing will take some time as all code is pulled down from the repository
1. Define MAVEN_REPO classpath variable in Eclipse
* Setting is in Preferences under Java-Build Path-Classpath Variables
* MAVEN_REPO on windows may default to something like C:/Documents and
Settings/Administrator/.maven/repository
1. Run maven eclipse in each project directory to download required libs and
create .classpath and .project files for project
1. Refresh projects in Eclipse to read new config files generated by Maven
=== Team Project Set ===
* Save the following XML to a file called something like struts-head.psf.
* This file is meant to be imported using the File-Import-Team Project Set
functionality in Eclipse.
{{{
?xml version=1.0 encoding=UTF-8?
psf version=2.0
provider id=org.tigris.subversion.subclipse.core.svnnature
project
reference=0.9.3,http://svn.apache.org/repos/asf/struts/core/trunk,struts-core/
project
reference=0.9.3,http://svn.apache.org/repos/asf/struts/el/trunk,struts-el/
project
reference=0.9.3,http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts-shale,struts-shale/
/provider
/psf
}}}
=== Notes ===
* The example team project set file above creates projects for struts-core,
struts-el and struts-shale.
* Trying to run maven eclipse for struts-shale will not work unless you
change the servlet-api dependency from 5.0.28 to 5.0.18 because 5.0.28 is not
on ibiblio at this time. Make this change in project.xml.
* The team project set could also be used to pull down the source for a
particular tag or branch.
* The struts-core project contains legacy javadoc for struts 1.0 and struts
1.1, if these were zipped up the checkout process would probably be somewhat
faster.
* I believe there is a Maven Eclipse plugin that may simplify this but I
haven't tried it out.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
We didn't do it earlier because we wanted to use commons-resources for
message passing. That hasn't happened so we may as well add the
validateForm() method and deprecate validate().
David
--- Joe Germuska [EMAIL PROTECTED] wrote:
In order to push forward on full deprecation of ActionErrors, I
propose adding the following method to ActionForm:
public ActionMessages validateForm(ActionMapping mapping,
HttpServletRequest request) {
return validate(mapping, request);
}
and then changing one line in the Request Processing chain:
ActionMessages errors = form.validate(mapping, request);
to
ActionMessages errors = form.validateForm(mapping, request);
I'm not sure now why we haven't done this earlier. Someone suggested
it on one of the lists a while ago and it seemed clear once I saw it,
but I haven't had time to do anything about it.
My inclination is to do this only on the 1.3 (HEAD) branch, and to
make the change in RequestProcessor.java even though it is slated for
obsolescence, and then also to make the change in
o.a.s.chain.AbstractValidateActionForm (which actually still uses
ActionErrors, actually.)
If it didn't seem strange that it hasn't been done already, I might
have just gone ahead and done it without raising the question -- so
I'm wondering if I'm missing something?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
We did just get Commons Resources promoted out of the sandbox, and I'm
hopeful that we'll get that puppy released soon. Finally!
--
Martin Cooper
On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
[EMAIL PROTECTED] wrote:
We didn't do it earlier because we wanted to use commons-resources for
message passing. That hasn't happened so we may as well add the
validateForm() method and deprecate validate().
David
--- Joe Germuska [EMAIL PROTECTED] wrote:
In order to push forward on full deprecation of ActionErrors, I
propose adding the following method to ActionForm:
public ActionMessages validateForm(ActionMapping mapping,
HttpServletRequest request)
{
return validate(mapping, request);
}
and then changing one line in the Request Processing chain:
ActionMessages errors = form.validate(mapping, request);
to
ActionMessages errors = form.validateForm(mapping, request);
I'm not sure now why we haven't done this earlier. Someone suggested
it on one of the lists a while ago and it seemed clear once I saw it,
but I haven't had time to do anything about it.
My inclination is to do this only on the 1.3 (HEAD) branch, and to
make the change in RequestProcessor.java even though it is slated for
obsolescence, and then also to make the change in
o.a.s.chain.AbstractValidateActionForm (which actually still uses
ActionErrors, actually.)
If it didn't seem strange that it hasn't been done already, I might
have just gone ahead and done it without raising the question -- so
I'm wondering if I'm missing something?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
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: Object configuration and ... JMX dreaming
Vic, Are you thinking this would this be a good idea to manage the Struts API Bean thats being talked about? http://article.gmane.org/gmane.comp.jakarta.struts.devel/23601 ... or did you have other ideas where it could be put to work? Niall - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Vic [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, December 03, 2004 12:30 PM Subject: Re: Object configuration and ... JMX dreaming At 5:45 AM -0600 12/3/04, Vic wrote: Yes Vic, good idea ;-). Resin also has a quick JMX tutorial: To save you from talking to yourself ;-), I think JMX instrumentation for Struts is a very cool idea. Then again, I can't describe any specific use cases for it myself at the moment. I'm sure I could come up with some given some time. Maybe folks can start articulating some (perhaps in the Wiki) so that the idea can take shape... Joe http://www.caucho.com/resin-3.0/jmx/tutorial/basic/index.xtp It look like IoC to me. .V Vic wrote: We have talked CoR, IoC... but not yet JMX/Modeler. Tomcat 5.5 has JMX. If any singleton types are in the registry, and we get them from registry. It's a big chunk to bite of. I still do not know how to use JMX, but . . . What if there was a way that object in the Chain XML Catalog commands where imeditely in modeler Registry transparently? So CoR is... JMX-able? The benfit is that it can be monitored, like how many sessions, and bla bla. Or at least enable users to build monitored applications. (Like Tomcat 5.5, even on the main menu has monitoring) Modeler does not have much configration code AFAIK, it's just a registry for monitoring AFAIK. It' just an idea and I know... code. (I am sure Tomcat 5.5 has something) I will post some large SoA/dispacher contraption in 10 days or so (on my site). .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - 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: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Wouldn't it be better to get rid of this in 1.3 with the move to Chain?
Doesn't everything get thrown up in the air and re-defined at that point
including Action's being deprecated in favour of objects that just implement
the Command interface?
Niall
- Original Message -
From: Martin Cooper [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Friday, December 03, 2004 7:59 PM
Subject: Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
We did just get Commons Resources promoted out of the sandbox, and I'm
hopeful that we'll get that puppy released soon. Finally!
--
Martin Cooper
On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
[EMAIL PROTECTED] wrote:
We didn't do it earlier because we wanted to use commons-resources for
message passing. That hasn't happened so we may as well add the
validateForm() method and deprecate validate().
David
--- Joe Germuska [EMAIL PROTECTED] wrote:
In order to push forward on full deprecation of ActionErrors, I
propose adding the following method to ActionForm:
public ActionMessages validateForm(ActionMapping mapping,
HttpServletRequest
request) {
return validate(mapping, request);
}
and then changing one line in the Request Processing chain:
ActionMessages errors = form.validate(mapping, request);
to
ActionMessages errors = form.validateForm(mapping, request);
I'm not sure now why we haven't done this earlier. Someone suggested
it on one of the lists a while ago and it seemed clear once I saw it,
but I haven't had time to do anything about it.
My inclination is to do this only on the 1.3 (HEAD) branch, and to
make the change in RequestProcessor.java even though it is slated for
obsolescence, and then also to make the change in
o.a.s.chain.AbstractValidateActionForm (which actually still uses
ActionErrors, actually.)
If it didn't seem strange that it hasn't been done already, I might
have just gone ahead and done it without raising the question -- so
I'm wondering if I'm missing something?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
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: Object configuration and ... JMX dreaming
Niall Pemberton wrote:
Vic,
Are you thinking this would this be a good idea to manage the Struts API
Bean thats being talked about?
http://article.gmane.org/gmane.comp.jakarta.struts.devel/23601
Exactly! Not sure what version. Just expose it for now.
... or did you have other ideas where it could be put to work?
Maybe in some version we can configure things in there. While in
produciton reload Struts, Validation, comands, configure view capabilities.
I do have now a design that exposes my DAO to JMX. Main part:
public class MonitorSrv extends HttpServlet {
public void init() { // load on start up
HtmlAdaptorServer srv = new HtmlAdaptorServer(8082);
// this is part of Sun RI + port
BaseJmx jmx = BaseJmx.getInstance();
// this is just a MBean server based on RI
//I used instead of modeler Reigster object
try {
jmx.register(srv);
} catch (Exception e) {
. . .
}
srv.start();
}
So if you just surf to localhost:8082 you get a JMX console, getters/setters
Once this jmx is out there, users can register their own stuff.
What I do not like ... is more than one way to configure. So I say...
digester at load time and jmx at run time.
.V
Niall
- Original Message -
From: Joe Germuska [EMAIL PROTECTED]
To: Vic [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, December 03, 2004 12:30 PM
Subject: Re: Object configuration and ... JMX dreaming
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
At 8:41 PM + 12/3/04, Niall Pemberton wrote:
Wouldn't it be better to get rid of this in 1.3 with the move to Chain?
Doesn't everything get thrown up in the air and re-defined at that point
including Action's being deprecated in favour of objects that just implement
the Command interface?
I guess I had figured on 1.3 being more transitional than that. But,
even if one were to use a command instead of an action, we haven't
talked (yet) about changing the validation model.
I haven't heard anyone propose a major change to the model of Struts
populates an ActionForm and calls a method on it which tests its
validity and is able to return a bundle of messages explaining
validation errors if there are any. My preference would be to defer
any changes that dramatic until 1.4, although with the chain, it
would be a little easier for people to prototype those kinds in the
sandbox or on SourceForge (or whereever...)
Perhaps it is worth trying to come up with a more future proof
implementation, though. This isn't a burning issue -- clearly people
are confused about the ActionMessages/ActionErrors situation, but I
think that's under control. By future-proof, I mean something that
passes in the resources-equivalent of ActionMessages, and possibly
which passes in something like a ValidationContext which would
eliminate the explicit dependency on HttpServletRequest.
Joe
Niall
- Original Message -
From: Martin Cooper [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Friday, December 03, 2004 7:59 PM
Subject: Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
We did just get Commons Resources promoted out of the sandbox, and I'm
hopeful that we'll get that puppy released soon. Finally!
--
Martin Cooper
On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
[EMAIL PROTECTED] wrote:
We didn't do it earlier because we wanted to use commons-resources for
message passing. That hasn't happened so we may as well add the
validateForm() method and deprecate validate().
David
--- Joe Germuska [EMAIL PROTECTED] wrote:
In order to push forward on full deprecation of ActionErrors, I
propose adding the following method to ActionForm:
public ActionMessages validateForm(ActionMapping mapping,
HttpServletRequest
request) {
return validate(mapping, request);
}
and then changing one line in the Request Processing chain:
ActionMessages errors = form.validate(mapping, request);
to
ActionMessages errors = form.validateForm(mapping, request);
I'm not sure now why we haven't done this earlier. Someone suggested
it on one of the lists a while ago and it seemed clear once I saw it,
but I haven't had time to do anything about it.
My inclination is to do this only on the 1.3 (HEAD) branch, and to
make the change in RequestProcessor.java even though it is slated for
obsolescence, and then also to make the change in
o.a.s.chain.AbstractValidateActionForm (which actually still uses
ActionErrors, actually.)
If it didn't seem strange that it hasn't been done already, I might
have just gone ahead and done it without raising the question -- so
I'm wondering if I'm missing something?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
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]
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsShale
Date: 2004-12-03T13:19:05 Editor: CraigMcClanahan [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsShale URL: http://wiki.apache.org/struts/StrutsShale no comment Change Log: -- @@ -3,4 +3,7 @@ * [http://svn.apache.org/viewcvs.cgi/*checkout*/struts/sandbox/trunk/struts-shale/README.html Proposal Details] (latest SVN version) * [http://www.apache.org/~craigmcc/struts-shale/ API Javadocs] (periodically updated) + * [http://cvs.apache.org/builds/jakarta-struts/nightly/struts-shale/ Nightly Builds] of core framework, + sample application, and test framework + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Object configuration and ... JMX dreaming
Sounds like a great idea and something that would be fun to do, but for me I
don't deploy/change my *live* webapp that often and so theres no real
selling point to my users to develop a feature like this - similar to the
Hot Deployment stuff Jack/Michaels been talking about. I guess for people
in larger teams (mines a team of one :-) it would probably sell itself as a
development feature alone.
Niall
- Original Message -
From: Vic [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 03, 2004 8:48 PM
Subject: Re: Object configuration and ... JMX dreaming
Niall Pemberton wrote:
Vic,
Are you thinking this would this be a good idea to manage the Struts
API
Bean thats being talked about?
http://article.gmane.org/gmane.comp.jakarta.struts.devel/23601
Exactly! Not sure what version. Just expose it for now.
... or did you have other ideas where it could be put to work?
Maybe in some version we can configure things in there. While in
produciton reload Struts, Validation, comands, configure view
capabilities.
I do have now a design that exposes my DAO to JMX. Main part:
public class MonitorSrv extends HttpServlet {
public void init() { // load on start up
HtmlAdaptorServer srv = new HtmlAdaptorServer(8082);
// this is part of Sun RI + port
BaseJmx jmx = BaseJmx.getInstance();
// this is just a MBean server based on RI
//I used instead of modeler Reigster object
try {
jmx.register(srv);
} catch (Exception e) {
. . .
}
srv.start();
}
So if you just surf to localhost:8082 you get a JMX console,
getters/setters
Once this jmx is out there, users can register their own stuff.
What I do not like ... is more than one way to configure. So I say...
digester at load time and jmx at run time.
.V
Niall
- Original Message -
From: Joe Germuska [EMAIL PROTECTED]
To: Vic [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, December 03, 2004 12:30 PM
Subject: Re: Object configuration and ... JMX dreaming
-
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]
[Apache Struts Wiki] Updated: StrutsShale
Date: 2004-12-03T13:20:04 Editor: CraigMcClanahan [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsShale URL: http://wiki.apache.org/struts/StrutsShale no comment Change Log: -- @@ -3,7 +3,6 @@ * [http://svn.apache.org/viewcvs.cgi/*checkout*/struts/sandbox/trunk/struts-shale/README.html Proposal Details] (latest SVN version) * [http://www.apache.org/~craigmcc/struts-shale/ API Javadocs] (periodically updated) - * [http://cvs.apache.org/builds/jakarta-struts/nightly/struts-shale/ Nightly Builds] of core framework, - sample application, and test framework + * [http://cvs.apache.org/builds/jakarta-struts/nightly/struts-shale/ Nightly Builds] of core framework, sample application, and test framework - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Object configuration and ... JMX dreaming
Being able to monitor is a big deal! As soon as we know what this RequestProcessBeanThingObject is, anyone can make an mBean. Then it be obvois that you do want to look at it. My use case is that I want to look at DAO cache and Lucene cache for hits/misses and size of SoftHashMap % relative to VM heap size. This is realy hard to get via stress test and lets you evalute your design decsssions. Also, I can force invalidate something out of turn. For example lets say I update content on the back end DB, now I want DAO and Lucene to reset. Also my clients LOVE to look at monitors. Man I show them some stress test tool that shows sessions and what type they are, now all the digintaries look at it. THEY want to buy a 60 LCD to put in the recpetion of IT! Monitoring makes them feel that they are doing something to the CEO. The saying at IBM used to be that the value of system is messured by managemnt in pounds of paper it produces. Everyone loves reports on their desk. 1.5 has a bulit in JMX VM monitor, look at it once and there goes your productivity. In the old days, 3 tier meant client/server and managment tier. JMX sounds scary but it was easy once I read up enough. Also, I do not think it's intrusive now, in the sense thatno mater what the RequestProcessBeanThingObject is, it can be monitored. I think it'd be one of the more popular features. Hell, it can be done for 1.27 or whatever the counter says, and no, it does not force you to have 1.5 but I can't image it working w/1.3. .V Niall Pemberton wrote: Sounds like a great idea and something that would be fun to do, but for me I don't deploy/change my *live* webapp that often and so theres no real selling point to my users to develop a feature like this - similar to the Hot Deployment stuff Jack/Michaels been talking about. I guess for people in larger teams (mines a team of one :-) it would probably sell itself as a development feature alone. Niall - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
I wasn't proposing changing the validation model at all - but with the
advent of Chain we could deprecate the validate(mapping, request) method in
favour of a validate(Context) method in ActionForm. This would provide more
flexibility and cause less confusion because the method name has stayed the
same. I would also suggest that the new validate method shouldn't return
anything, with the ActionForm being responsible for sticking the messages in
the Context. That way if/when thing move to commons resources we won't face
the same problem again.
Niall
- Original Message -
From: Joe Germuska [EMAIL PROTECTED]
To: Niall Pemberton [EMAIL PROTECTED]; Struts Developers
List [EMAIL PROTECTED]
Sent: Friday, December 03, 2004 9:09 PM
Subject: Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
At 8:41 PM + 12/3/04, Niall Pemberton wrote:
Wouldn't it be better to get rid of this in 1.3 with the move to Chain?
Doesn't everything get thrown up in the air and re-defined at that point
including Action's being deprecated in favour of objects that just
implement
the Command interface?
I guess I had figured on 1.3 being more transitional than that. But,
even if one were to use a command instead of an action, we haven't
talked (yet) about changing the validation model.
I haven't heard anyone propose a major change to the model of Struts
populates an ActionForm and calls a method on it which tests its
validity and is able to return a bundle of messages explaining
validation errors if there are any. My preference would be to defer
any changes that dramatic until 1.4, although with the chain, it
would be a little easier for people to prototype those kinds in the
sandbox or on SourceForge (or whereever...)
Perhaps it is worth trying to come up with a more future proof
implementation, though. This isn't a burning issue -- clearly people
are confused about the ActionMessages/ActionErrors situation, but I
think that's under control. By future-proof, I mean something that
passes in the resources-equivalent of ActionMessages, and possibly
which passes in something like a ValidationContext which would
eliminate the explicit dependency on HttpServletRequest.
Joe
Niall
- Original Message -
From: Martin Cooper [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Friday, December 03, 2004 7:59 PM
Subject: Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
We did just get Commons Resources promoted out of the sandbox, and I'm
hopeful that we'll get that puppy released soon. Finally!
--
Martin Cooper
On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
[EMAIL PROTECTED] wrote:
We didn't do it earlier because we wanted to use commons-resources
for
message passing. That hasn't happened so we may as well add the
validateForm() method and deprecate validate().
David
--- Joe Germuska [EMAIL PROTECTED] wrote:
In order to push forward on full deprecation of ActionErrors, I
propose adding the following method to ActionForm:
public ActionMessages validateForm(ActionMapping mapping,
HttpServletRequest
request) {
return validate(mapping, request);
}
and then changing one line in the Request Processing chain:
ActionMessages errors = form.validate(mapping, request);
to
ActionMessages errors = form.validateForm(mapping,
request);
I'm not sure now why we haven't done this earlier. Someone
suggested
it on one of the lists a while ago and it seemed clear once I saw
it,
but I haven't had time to do anything about it.
My inclination is to do this only on the 1.3 (HEAD) branch, and to
make the change in RequestProcessor.java even though it is slated
for
obsolescence, and then also to make the change in
o.a.s.chain.AbstractValidateActionForm (which actually still uses
ActionErrors, actually.)
If it didn't seem strange that it hasn't been done already, I
might
have just gone ahead and done it without raising the question --
so
I'm wondering if I'm missing something?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Re: [VOTE] Struts 1.2.6 Quality
I was of the impression that committers and up judged quality and PMC members were in charge of deciding whether distribution would happen or not. quot After a new release is built, it must be tested before being released to the public. Majority approval is required before the release can be made. Once a release is approved by the Committers, the Project Management Committee can authorize its distribution on behalf of the Foundation. /quot Am I misinterpreting that? Eddie - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, December 03, 2004 12:49 AM Subject: [VOTE] Struts 1.2.6 Quality The Struts 1.2.6 test build has been available for about two weeks now. Once you have had a chance to form an opinion on the quality of this build, please respond to the following vote. - Based on its quality, the Struts 1.2.6 build should be classified as: [ ] Alpha [ ] Beta [ ] General Availability (GA) - If you are voting for Alpha or Beta, please state your concerns with the build as it is today. Only the votes of Struts PMC members are binding. However, all opinions and feedback are welcome. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0449-1, 12/02/2004 Tested on: 12/3/2004 8:55:48 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.2.6 Quality
I don't see a difference, Martin. It's moot to me. I haven't had time to test it, so I hadn't intended to voice any input. I don't see what you're quoting to say that only PMC members have voting rights on the quality of a release though. In fact, I still feel my original view is valid: PMC members are there to authorize the release, once committers determine it's quality by a vote. I'm not trying to be thick :-) I just don't see what you're pointing to as an authority on the matter. It's more for the sake of my understanding, I suppose. I might care in the future ;-) Y'all have fun. I've got to make a road trip this weekend :-( No rest for the wicked! Night, Eddie - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Eddie Bush [EMAIL PROTECTED] Cc: Struts Developers List [EMAIL PROTECTED] Sent: Friday, December 03, 2004 9:31 PM Subject: Re: [VOTE] Struts 1.2.6 Quality You're quoting from the Jakarta decision making page. We're not at Jakarta any more, and have our own process now. You have some catching up to do, Eddie. ;-) Here's what we're doing these days: http://struts.apache.org/releases.html -- Martin Cooper On Fri, 3 Dec 2004 20:55:47 -0600, Eddie Bush [EMAIL PROTECTED] wrote: I was of the impression that committers and up judged quality and PMC members were in charge of deciding whether distribution would happen or not. quot After a new release is built, it must be tested before being released to the public. Majority approval is required before the release can be made. Once a release is approved by the Committers, the Project Management Committee can authorize its distribution on behalf of the Foundation. /quot Am I misinterpreting that? Eddie - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, December 03, 2004 12:49 AM Subject: [VOTE] Struts 1.2.6 Quality The Struts 1.2.6 test build has been available for about two weeks now. Once you have had a chance to form an opinion on the quality of this build, please respond to the following vote. - Based on its quality, the Struts 1.2.6 build should be classified as: [ ] Alpha [ ] Beta [ ] General Availability (GA) - If you are voting for Alpha or Beta, please state your concerns with the build as it is today. Only the votes of Struts PMC members are binding. However, all opinions and feedback are welcome. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0449-1, 12/02/2004 Tested on: 12/3/2004 8:55:48 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0449-1, 12/02/2004 Tested on: 12/3/2004 9:57:04 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.2.6 Quality
The page Martin pointed out says it needs a vote. The ByeLaws page says this about voting... * Decision Making All Volunteers are encouraged to participate in decisions, but the decision itself is made by the Project Management Committee. The Project is a Minimum Threshod Meritocracy. * Voting Any subscriber to the list may vote on any issue or action item. Votes from Contributors and Committers are especially welcome. However, the only binding votes are those cast by a PMC Member. http://struts.apache.org/bylaws.html Niall - Original Message - From: Eddie Bush [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; Martin Cooper [EMAIL PROTECTED] Sent: Saturday, December 04, 2004 3:57 AM Subject: Re: [VOTE] Struts 1.2.6 Quality I don't see a difference, Martin. It's moot to me. I haven't had time to test it, so I hadn't intended to voice any input. I don't see what you're quoting to say that only PMC members have voting rights on the quality of a release though. In fact, I still feel my original view is valid: PMC members are there to authorize the release, once committers determine it's quality by a vote. I'm not trying to be thick :-) I just don't see what you're pointing to as an authority on the matter. It's more for the sake of my understanding, I suppose. I might care in the future ;-) Y'all have fun. I've got to make a road trip this weekend :-( No rest for the wicked! Night, Eddie - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Eddie Bush [EMAIL PROTECTED] Cc: Struts Developers List [EMAIL PROTECTED] Sent: Friday, December 03, 2004 9:31 PM Subject: Re: [VOTE] Struts 1.2.6 Quality You're quoting from the Jakarta decision making page. We're not at Jakarta any more, and have our own process now. You have some catching up to do, Eddie. ;-) Here's what we're doing these days: http://struts.apache.org/releases.html -- Martin Cooper On Fri, 3 Dec 2004 20:55:47 -0600, Eddie Bush [EMAIL PROTECTED] wrote: I was of the impression that committers and up judged quality and PMC members were in charge of deciding whether distribution would happen or not. quot After a new release is built, it must be tested before being released to the public. Majority approval is required before the release can be made. Once a release is approved by the Committers, the Project Management Committee can authorize its distribution on behalf of the Foundation. /quot Am I misinterpreting that? Eddie - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, December 03, 2004 12:49 AM Subject: [VOTE] Struts 1.2.6 Quality The Struts 1.2.6 test build has been available for about two weeks now. Once you have had a chance to form an opinion on the quality of this build, please respond to the following vote. - Based on its quality, the Struts 1.2.6 build should be classified as: [ ] Alpha [ ] Beta [ ] General Availability (GA) - If you are voting for Alpha or Beta, please state your concerns with the build as it is today. Only the votes of Struts PMC members are binding. However, all opinions and feedback are welcome. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0449-1, 12/02/2004 Tested on: 12/3/2004 8:55:48 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0449-1, 12/02/2004 Tested on: 12/3/2004 9:57:04 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - 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 1.2.6 Quality
+1 beta For me, I would also like to see Bug #18169 Bug #21760 fixed - resource/bundle attributes for Commons Validator are broken - requires moving Struts to depend on Validator 1.1.4 Niall - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, December 03, 2004 6:51 AM Subject: Re: [VOTE] Struts 1.2.6 Quality My own vote... Beta. While a number of issues have been reported, my opinion is that #32490 is enough to preclude GA, since I believe we need to have the tag libraries in sync for a GA release. -- Martin Cooper On Thu, 2 Dec 2004 22:49:35 -0800, Martin Cooper [EMAIL PROTECTED] wrote: The Struts 1.2.6 test build has been available for about two weeks now. Once you have had a chance to form an opinion on the quality of this build, please respond to the following vote. - Based on its quality, the Struts 1.2.6 build should be classified as: [ ] Alpha [ ] Beta [ ] General Availability (GA) - If you are voting for Alpha or Beta, please state your concerns with the build as it is today. Only the votes of Struts PMC members are binding. However, all opinions and feedback are welcome. -- Martin Cooper - 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]
