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
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
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
--- 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
--- 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
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
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
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
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.
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.
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);
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:
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:
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
===
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,
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
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
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
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
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
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 @@
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
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 @@
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
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
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
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
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
+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
29 matches
Mail list logo
