The existing development mailing lists for Jakarta subprojects (BCEL, BSF, Cactus, ECS, JCS, JMeter, ORO, Regexp and retired subproject Slide) are merging. Two new lists will be soon be created, one for development discussions and another for notifications (such as SVN, Bugzilla, JIRA, Gump). Subscribers to any of the existing development lists mentioned above (also see CC header of this message) will be subscribed to the two new lists automatically. The existing lists that appear in the CC header of this message will subsequently be closed, with appropriate forwards in place to point to the merged list. The shared development discussions mailing list will use the convention of identifying the subproject associated with the posting in the email subject using square brackets. For example, a recent email sent to the jmeter-dev list had the subject: Exposing run info with JMX Once the shared mailing list is set up, the convention would be to use the following email subject instead: [JMeter] Exposing run info with JMX As a reminder, unsubscribing from a mailing list called list@jakarta.apache.org can be done by sending an email to list-unsubscribe@jakarta.apache.org (replace "list" with actual name of the mailing list to unsubscribe from). -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[Relaying result to all lists] The vote to merge dev lists at Jakarta has passed with the following binding votes cast: 5 +1s: Felipe Leme Daniel Savarese Vadim Gritsenko Rahul Akolkar Stephen Colebourne 2 +0s: Sebastian Bazley Rony Flatscher 2 -1s: Thomas Vandahl Torsten Curdt I also count 4 non-binding +1s (Mark Murphy, Venkat Krishnamurthy, Henri Yandell, Jörg Schaible) and 3 non-binding -1s (Hanson Char, Giuseppe, Tim Cronin). Two non-binding +1s were cast by folks who until recently were on the PMC (bayard, joehni) so perhaps not giving their votes enough credit is getting too technical here. We'll encourage simple conventions (as Commons was mentioned, for example) to make filtering email, searching archives etc. as convenient as we can on a shared list. Hope is that will alleviate to some extent the primary concern of those who've voted against. I will open an INFRA ticket for this merge in a week or so (after I post another heads up note with more details, dev mailing list conventions etc. to the lists). Thanks to everyone who voted. -Rahul On Mon, Oct 19, 2009 at 4:02 PM, Rahul Akolkar <rahul.akolkar@gmail.com> wrote: > [Suggestion is to please reply to the general@jakarta list only] > > This is a vote to consolidate the development lists at Jakarta into > one development and one notifications list. For background including > timing, anticipated benefits and some discussion, see proposal [1] > thread. > > [ ] +1 > [ ] -1 > > While not required, it'd be nice if anyone voting against could > briefly state the reason(s). And you're ofcourse welcome to vote +/-0 > if you really want. > > Vote will run atleast 72 hours and will close no sooner than Thursday 5 pm EST. > > TIA. > -Rahul > > [1] (long, possibly fragmented URL below) > http://mail-archives.apache.org/mod_mbox/jakarta-general/200910.mbox/%3cce1f2ea80910091443t5cad1db0na0663c416cb83a72@mail.gmail.com%3e > --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[Suggestion is to please reply to the general@jakarta list only] This is a vote to consolidate the development lists at Jakarta into one development and one notifications list. For background including timing, anticipated benefits and some discussion, see proposal [1] thread. [ ] +1 [ ] -1 While not required, it'd be nice if anyone voting against could briefly state the reason(s). And you're ofcourse welcome to vote +/-0 if you really want. Vote will run atleast 72 hours and will close no sooner than Thursday 5 pm EST. TIA. -Rahul [1] (long, possibly fragmented URL below) http://mail-archives.apache.org/mod_mbox/jakarta-general/200910.mbox/%3cce1f2ea80910091443t5cad1db0na0663c416cb83a72@mail.gmail.com%3e --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[Out of necessity, this is heavily cross-posted. Suggestion is to send any replies to the general@jakarta list only to keep any discussion in one place.] We currently have 8 active development lists at Jakarta, each devoted to a subproject. I've been subscribed to all for a while and based on my observations and the overall benefits of doing so, I think its time to consolidate them into a single development list at Jakarta. Motivations (not in any order): * Flattens and simplifies oversight - Not much else to be said on that. * Communication - Subprojects can often have various touch points. So, Rony's surprise today at the BSF taglib being retired is one example. Lets have all dev discussions on one list. * Cross-pollination - Most subprojects are at the point where it certainly wouldn't hurt to have the active folks from all of Jakarta around for dev discussions, votes etc. * Manageable overhead - More on this later, but we have a number of usual suspects showing up on many of the dev lists, they'd barely notice a difference. Others can manage, IMO/hopefully. Operationally: * The combined list traffic will obviously be more than any one of the separate lists. However, development tends to be in spurts on these lists and the probabilistic chances of more than a couple of subproject spurts happening at the same time seems quite low. Overall, combined traffic is not at all overpowering IMO. * The proposal will include closing current dev lists and adding all subscribers to the one new dev list. We'll post a heads up on these lists before that. Throw in site-cvs@ as well for good measure. * We could repurpose general@ as the one dev list, but OTOH, seems worthwhile to maintain the dev / general separation. * No changes proposed to the user lists. Thoughts? Lets say a little over a week (10 days, which should give us two weekends) for initial feedback and opinions please. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
Hi, is this project still under active development? I've made a few changes that I would like to commit if I get access: 1) Renamed all variables named "enum" so that it compiles under java 1.5 2) Replaced "Ørjan" with "Orjan" in "authour"-annotations (some people get compile-warnings - could probably be fixed some other way but I was lazy) 3) Most importantly for me: I've added some accessor methods for the registry and registryList. Needed for next item. 4) (Probably not relevant for anyone but me, I can keep this in a separate library) I've added a JDOMConverter that converts xhtml-elements to JDOM elements. This is very useful if you have a XHTML-document created using ecs and want to do something structured with it. In my case I wanted to convert it to PDF using the "flying saucer"-library (recommended, btw!). Instead of toString-ing my "html"-element and then parsing it, 10 lines of code converts it to a JDOM document which is then converted to a org.w3c.dom.Document which is what the "flying saucer" requires. Run-time went from 15-seconds to <1 for my sample documents. Narve --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Manfrin reopened ECS-1:
-----------------------------
Perfect, thank you...I really don't want to disturb you...
but some important adjustings are missing:
Here is the list:
org.apache.ecs.rtf.Alignment.java fails because removeElementFromRegistry uses element
hascode to remove an element. The patch is:
# This patch file was generated by NetBeans IDE
Index: Alignment.java
--- Alignment.java Base (BASE)
+++ Alignment.java Locally Modified (Based On LOCAL)
@@ -131,7 +131,7 @@
*/
public Element removeElementFromRegistry(Element element)
{
- type.removeElementFromRegistry(Integer.toString(element.hashCode()));
+ type.removeElementFromRegistry(element);
return(type);
}
org.apache.ecs.StringElement.java continues to fail beacuse still uses hashcodes! The
patch is:
# This patch file was generated by NetBeans IDE
Index: StringElement.java
--- StringElement.java Base (BASE)
+++ StringElement.java Locally Modified (Based On LOCAL)
@@ -105,7 +105,7 @@
*/
public StringElement addElement(String element)
{
- addElement(Integer.toString(element.hashCode()),element);
+ addElementToRegistry(element);
return(this);
}
org.apache.ecs.html.Caption.java continues to fail beacuse still uses hashcodes! The
patch is:
# This patch file was generated by NetBeans IDE
Index: Caption.java
--- Caption.java Base (BASE)
+++ Caption.java Locally Modified (Based On LOCAL)
@@ -77,7 +77,7 @@
*/
public Caption addElement(String element)
{
- addElementToRegistry(Integer.toString(element.hashCode()),element);
\ No newline at end of file
+ addElementToRegistry(element);
\ No newline at end of file
return(this);
}
org.apache.ecs.html.Select.java now uses a deprecated (and expensive) way of iterating
on elements. The patch is:
# This patch file was generated by NetBeans IDE
Index: Select.java
--- Select.java Base (BASE)
+++ Select.java Locally Modified (Based On LOCAL)
@@ -177,10 +177,10 @@
public Select selectOption(int option)
{
- Enumeration enum_ = keys();
+ Enumeration enum_ = elements();
for(int x = 0; enum_.hasMoreElements(); x++)
{
- ConcreteElement element = (ConcreteElement)getElement((String)enum_.nextElement());
+ ConcreteElement element = (ConcreteElement)enum_.nextElement();
if(x == option)
{
((Option)element).setSelected(true);
org.apache.ecs.xhtml.caption.java continues to fail beacuse still uses hashcodes! The
patch is:
# This patch file was generated by NetBeans IDE
Index: caption.java
--- caption.java Base (BASE)
+++ caption.java Locally Modified (Based On LOCAL)
@@ -91,7 +91,7 @@
*/
public caption addElement(String element)
{
- addElementToRegistry(Integer.toString(element.hashCode()),element);
+ addElementToRegistry(element);
return(this);
}
Thank you in advance.
Mauro
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip, secondConcreteElement.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Burrell Donkin closed ECS-2.
-----------------------------------
Resolution: Fixed
Committed. Many Thanks.
If you have any more patches, I hope that you won't have to wait so long.
Robert
> ECSDefaults can be configured only statically from a properties file, not dinamically
> -------------------------------------------------------------------------------------
>
> Key: ECS-2
> URL: https://issues.apache.org/jira/browse/ECS-2
> Project: ECS
> Issue Type: Improvement
> Reporter: Mauro Manfrin
> Attachments: ECSDefaults.zip
>
>
> ECSDefaults can be configured only statically from a properties file, not dinamically.
> I think this is a purposeless.
> But some features like CaseType, Codeset and most of all PrettyPrinting are often needed
to be changed dinamically
> (for example in webapp lifecycle, switching from a test to a production state).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
Author: rdonkin
Date: Sun Jul 27 06:15:04 2008
New Revision: 680100
URL: http://svn.apache.org/viewvc?rev=680100&view=rev
Log:
ECS-2 dynamic configuration of ECSDefaults, https://issues.apache.org/jira/browse/ECS-2. Contributed
by Mauro Manfrin.
Modified:
jakarta/ecs/trunk/src/java/org/apache/ecs/ECSDefaults.java
Modified: jakarta/ecs/trunk/src/java/org/apache/ecs/ECSDefaults.java
URL: http://svn.apache.org/viewvc/jakarta/ecs/trunk/src/java/org/apache/ecs/ECSDefaults.java?rev=680100&r1=680099&r2=680100&view=diff
==============================================================================
--- jakarta/ecs/trunk/src/java/org/apache/ecs/ECSDefaults.java (original)
+++ jakarta/ecs/trunk/src/java/org/apache/ecs/ECSDefaults.java Sun Jul 27 06:15:04 2008
@@ -37,7 +37,7 @@
This singleton allows the properties to gracefully default in the
case of an error.
*/
- private static ECSDefaults defaults = new ECSDefaults();
+ private final static ECSDefaults defaults = new ECSDefaults();
// now follows the private methods called by the
private ResourceBundle resource;
@@ -147,6 +147,14 @@
{
return defaults.codeset;
}
+
+ /**
+ Changes the default codeset dinamically.
+ */
+ public static void setDefaultCodeset(String codeset)
+ {
+ defaults.codeset=codeset;
+ }
/**
Position of tag relative to start and end.
@@ -165,6 +173,14 @@
}
/**
+ Changes the default caseType dinamically.
+ */
+ public static void setDefaultCaseType(int case_type)
+ {
+ defaults.case_type=case_type;
+ }
+
+ /**
Default start-of-tag character.
*/
public static char getDefaultStartTag()
@@ -189,6 +205,14 @@
}
/**
+ Changes the default caseType dinamically.
+ */
+ public static void setDefaultPrettyPrint(boolean pretty_print)
+ {
+ defaults.pretty_print=pretty_print;
+ }
+
+ /**
This private constructor is used to create the singleton used in the public static
methods.
*/
private ECSDefaults ()
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Burrell Donkin closed ECS-1.
-----------------------------------
Resolution: Fixed
Committed. Many Thanks.
Please test and reopen if it hasn't be applied cleanly. (The diffs didn't apply cleanly against
trunk, most likely due to formatting issues.)
Apologies for my slowness and thanks again for taking the trouble to report and fix this issue.
Robert
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip, secondConcreteElement.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
Author: rdonkin
Date: Sun Jul 27 04:29:18 2008
New Revision: 680091
URL: http://svn.apache.org/viewvc?rev=680091&view=rev
Log:
Bug fix ECS-1 problem with hashcodes on 64bit JVMs https://issues.apache.org/jira/browse/ECS-1.
Contributed by Mauro Manfrin.
Modified:
jakarta/ecs/trunk/src/java/org/apache/ecs/ConcreteElement.java
Modified: jakarta/ecs/trunk/src/java/org/apache/ecs/ConcreteElement.java
URL: http://svn.apache.org/viewvc/jakarta/ecs/trunk/src/java/org/apache/ecs/ConcreteElement.java?rev=680091&r1=680090&r2=680091&view=diff
==============================================================================
--- jakarta/ecs/trunk/src/java/org/apache/ecs/ConcreteElement.java (original)
+++ jakarta/ecs/trunk/src/java/org/apache/ecs/ConcreteElement.java Sun Jul 27 04:29:18 2008
@@ -38,11 +38,11 @@
*/
public class ConcreteElement extends ElementAttributes implements Cloneable
{
- /** The line separator to use for pretty printing */
- private static String lineSeparator = System.getProperty("line.separator");
+ /** The line separator to use for pretty printing */
+ private static String lineSeparator = System.getProperty("line.separator");
/** @serial registry registry */
- private Hashtable registry = new Hashtable(4); // keep a list of elements that need to
be added to the element
+ private Hashtable registry; // keep a list of elements that need to be added to the element
/** Maintain an ordered list of elements */
private Vector registryList = new Vector(2);
@@ -50,17 +50,41 @@
{
}
+ private static final String HASHCODE_AUTOGENERATED="org.apache.ecs.#@HcAg@#";
+ /** Utility to test for autogenerated key names
+ @param the key as given by the keys() enumeration.
+ */
+ private boolean isAutoGenerated(String name) {
+ return (name!=null) && name.startsWith(HASHCODE_AUTOGENERATED);
+ }
+
+ /** Utility to search for elements with autogenerated keys in the registryList
+ @param the key as given by the keys() enumeration.
+ */
+
+ private ConcreteElement searchAutoGenerated(String name) {
+ int hashcode=Integer.parseInt(name.substring(HASHCODE_AUTOGENERATED.length()));
+ Object o;
+ for (int i=0;i<registryList.size();i++) {
+ o=registryList.get(i);
+ if (o!=null && o.hashCode()==hashcode) return (ConcreteElement)o;
+ }
+ return null;
+ }
+
/**
If the object is in the registry return otherwise return null.
@param element the name of the object to locate.
*/
- public ConcreteElement getElement(String element)
+ public ConcreteElement getElement(String name)
{
- if(registry.containsKey(element))
- {
- return (ConcreteElement)registry.get(element);
+ if (isAutoGenerated(name)) {
+ return searchAutoGenerated(name);
+ }
+ else {
+ if (registry==null) return null;
+ return (ConcreteElement)registry.get(name);
}
- return null;
}
/**
@@ -71,7 +95,7 @@
{
if ( element == null )
return(this);
- addElementToRegistry(Integer.toString(element.hashCode()),element);
+ addElementToRegistry(null,element);
return(this);
}
@@ -80,17 +104,20 @@
@param hashcode internal name of element
@param element element to be added to the registry.
*/
- public Element addElementToRegistry(String hashcode,Element element)
+ public Element addElementToRegistry(String name,Element element)
{
- if ( hashcode == null || element == null )
+ if ( element == null )
return(this);
element.setFilterState(getFilterState());
if(ECSDefaults.getDefaultPrettyPrint() != element.getPrettyPrint())
element.setPrettyPrint(getPrettyPrint());
- registry.put(hashcode,element);
- if(!registryList.contains(hashcode))
- registryList.addElement(hashcode);
+ if (name!=null) {
+ if (registry==null) registry=new Hashtable(4);
+ registry.put(name,element);
+ }
+ if(!registryList.contains(element))
+ registryList.addElement(element);
return(this);
}
@@ -105,7 +132,7 @@
if ( element == null )
return(this);
setFilterState(filter);
- addElementToRegistry(Integer.toString(element.hashCode()),element);
+ addElementToRegistry(null,element);
return(this);
}
@@ -114,12 +141,12 @@
@param element element to be added to the registry.
@param filter should we filter this element?
*/
- public Element addElementToRegistry(String hashcode, Element element,boolean filter)
+ public Element addElementToRegistry(String name, Element element,boolean filter)
{
- if ( hashcode == null )
+ if ( name == null )
return(this);
setFilterState(filter);
- addElementToRegistry(hashcode,element);
+ addElementToRegistry(name,element);
return(this);
}
@@ -133,7 +160,7 @@
if ( value == null )
return(this);
setFilterState(filter);
- addElementToRegistry(Integer.toString(value.hashCode()),value);
+ addElementToRegistry(value);
return(this);
}
@@ -143,12 +170,12 @@
@param element element to be added to the registry.
@param filter does this need to be filtered?
*/
- public Element addElementToRegistry(String hashcode, String value,boolean filter)
+ public Element addElementToRegistry(String name, String value,boolean filter)
{
- if ( hashcode == null )
+ if ( name == null )
return(this);
setFilterState(filter);
- addElementToRegistry(hashcode,value);
+ addElementToRegistry(name,value);
return(this);
}
@@ -168,9 +195,9 @@
Registers an element in the head element list
@param element element to be added to the registry.
*/
- public Element addElementToRegistry(String hashcode,String value)
+ public Element addElementToRegistry(String name,String value)
{
- if ( hashcode == null )
+ if ( name == null )
return(this);
// We do it this way so that filtering will work.
@@ -183,7 +210,7 @@
se.setFilterState(getFilterState());
se.setFilter(getFilter());
se.setPrettyPrint(getPrettyPrint());
- addElementToRegistry(hashcode,se);
+ addElementToRegistry(name,se);
return(this);
}
@@ -193,7 +220,17 @@
*/
public Element removeElementFromRegistry(Element element)
{
- removeElementFromRegistry(Integer.toString(element.hashCode()));
+ boolean contained=registryList.remove(element);
+ if (contained && registry!=null) {
+ java.util.Iterator i=registry.entrySet().iterator();
+ java.util.Map.Entry me;
+ while (i.hasNext()) {
+ me=(java.util.Map.Entry)i.next();
+ if (element==me.getValue()) {
+ registry.remove(me.getKey());
+ }
+ }
+ }
return(this);
}
@@ -201,10 +238,17 @@
Removes an element from the head element registry
@param hashcode element to be added to the registry.
*/
- public Element removeElementFromRegistry(String hashcode)
+ public Element removeElementFromRegistry(String name)
{
- registry.remove(hashcode);
- registryList.removeElement(hashcode);
+ if (isAutoGenerated(name)) {
+ Object o=searchAutoGenerated(name);
+ if (o!=null) registryList.remove(o);
+ }
+ else {
+ if (registry==null) return this;
+ Object o=registry.remove(name);
+ if (o!=null) registryList.removeElement(o);
+ }
return(this);
}
@@ -214,38 +258,58 @@
*/
public boolean registryHasElement(Element element)
{
- return(registry.contains(element));
+ return(registryList.contains(element));
}
- /**
- Get the keys of this element.
- */
- public Enumeration keys()
- {
- return(registryList.elements());
- }
+ /**
+ Get the keys of this element.
+ * @deprecated
+ */
+ public Enumeration keys()
+ {
+ Vector v=new Vector(registryList.size());
+ for (int j=0;j<registryList.size();j++) {
+ v.add(HASHCODE_AUTOGENERATED+registryList.get(j).hashCode());
+ }
+ if (registry!=null) {
+ java.util.Iterator i=registry.entrySet().iterator();
+ while (i.hasNext()) {
+ java.util.Map.Entry me=(java.util.Map.Entry)i.next();
+ int j=registryList.indexOf(me.getValue());
+ if (j>=0) v.set(j,me.getKey());
+ }
+ }
+ return v.elements();
+ }
/**
Get an enumeration of the elements that this element contains.
*/
public Enumeration elements()
{
- return(registry.elements());
+ return(registryList.elements());
}
/**
Find out if this element is in the element registry.
@param element find out if this element is in the registry
*/
- public boolean registryHasElement(String hashcode)
+ public boolean registryHasElement(String name)
{
- return(registry.containsKey(hashcode));
+ if (isAutoGenerated(name)) {
+ Object o=searchAutoGenerated(name);
+ return o!=null;
+ }
+ else {
+ if (registry==null) return false;
+ return(registry.containsKey(name));
+ }
}
-
+
/**
Overload output(OutputStream).
@param output OutputStream to write to.
- @param ConcreteElement Instance of ConcreteElement
+ @param ConcreteElement Instance of ConcreteElement
*/
public static void output(OutputStream out, ConcreteElement ce)
{
@@ -262,8 +326,8 @@
int tabLevel = ce.getTabLevel();
try
{
- if (ce.registry.size() == 0)
- {
+ if (ce.registryList.size() == 0)
+ {
ce.output(out);
}
else
@@ -281,7 +345,7 @@
while(enum_.hasMoreElements())
{
- Object obj = ce.registry.get((String)enum_.nextElement());
+ Object obj = (Object)enum_.nextElement();
if(obj instanceof GenericElement)
{
Element e = (Element)obj;
@@ -329,34 +393,34 @@
ioe.printStackTrace(new PrintWriter(out));
}
}
-
+
/**
Override output(OutputStream) incase any elements are in the registry.
@param output OutputStream to write to.
*/
public void output(OutputStream out)
- {
- if (this.registry.size() == 0)
- {
- int tabLevel = getTabLevel();
- if ((getPrettyPrint() && this instanceof Printable) && (tabLevel >
0))
- {
- try
- {
- this.putTabs(tabLevel, out);
- }
- catch(IOException ioe)
- {
- ioe.printStackTrace(new PrintWriter(out));
- }
- }
+ {
+ if (this.registryList.size() == 0)
+ {
+ int tabLevel = getTabLevel();
+ if ((getPrettyPrint() && this instanceof Printable) && (tabLevel
> 0))
+ {
+ try
+ {
+ this.putTabs(tabLevel, out);
+ }
+ catch(IOException ioe)
+ {
+ ioe.printStackTrace(new PrintWriter(out));
+ }
+ }
super.output(out);
- }
- else
- {
- output(out,this);
- }
- }
+ }
+ else
+ {
+ output(out,this);
+ }
+ }
/**
Writer version of this method.
@@ -373,72 +437,72 @@
@param output OutputStream to write to.
*/
public void output(PrintWriter out)
- {
- boolean prettyPrint = getPrettyPrint();
- int tabLevel = getTabLevel();
- if (registry.size() == 0)
- {
- if ((prettyPrint && this instanceof Printable) && (tabLevel > 0))
- putTabs(tabLevel, out);
-
- super.output(out);
- }
- else
- {
- if ((prettyPrint && this instanceof Printable) && (tabLevel > 0))
- putTabs(tabLevel, out);
+ {
+ boolean prettyPrint = getPrettyPrint();
+ int tabLevel = getTabLevel();
+ if (registryList.size() == 0)
+ {
+ if ((prettyPrint && this instanceof Printable) && (tabLevel >
0))
+ putTabs(tabLevel, out);
- out.write(createStartTag());
+ super.output(out);
+ }
+ else
+ {
+ if ((prettyPrint && this instanceof Printable) && (tabLevel >
0))
+ putTabs(tabLevel, out);
+
+ out.write(createStartTag());
// If this is a StringElement that has ChildElements still print the TagText
if(getTagText() != null)
out.write(getTagText());
Enumeration enum_ = registryList.elements();
- while(enum_.hasMoreElements())
- {
- Object obj = registry.get((String)enum_.nextElement());
- if(obj instanceof GenericElement)
- {
- Element e = (Element)obj;
- if (prettyPrint && this instanceof Printable)
- {
+ while(enum_.hasMoreElements())
+ {
+ Object obj = (Object)enum_.nextElement();
+ if(obj instanceof GenericElement)
+ {
+ Element e = (Element)obj;
+ if (prettyPrint && this instanceof Printable)
+ {
if (getNeedLineBreak()) {
- out.write(lineSeparator);
- e.setTabLevel(tabLevel + 1);
- }
- }
- e.output(out);
- }
- else
- {
- if (prettyPrint && this instanceof Printable)
- {
+ out.write(lineSeparator);
+ e.setTabLevel(tabLevel + 1);
+ }
+ }
+ e.output(out);
+ }
+ else
+ {
+ if (prettyPrint && this instanceof Printable)
+ {
if (getNeedLineBreak()) {
- out.write(lineSeparator);
- putTabs(tabLevel + 1, out);
- }
- }
- String string = obj.toString();
- if(getFilterState())
- out.write(getFilter().process(string));
- else
- out.write(string);
- }
- }
- if (getNeedClosingTag())
- {
- if (prettyPrint && this instanceof Printable)
- {
+ out.write(lineSeparator);
+ putTabs(tabLevel + 1, out);
+ }
+ }
+ String string = obj.toString();
+ if(getFilterState())
+ out.write(getFilter().process(string));
+ else
+ out.write(string);
+ }
+ }
+ if (getNeedClosingTag())
+ {
+ if (prettyPrint && this instanceof Printable)
+ {
if (getNeedLineBreak()) {
- out.write(lineSeparator);
- if (tabLevel > 0)
- putTabs(tabLevel, out);
- }
- }
- out.write(createEndTag());
- }
- }
- }
+ out.write(lineSeparator);
+ if (tabLevel > 0)
+ putTabs(tabLevel, out);
+ }
+ }
+ out.write(createEndTag());
+ }
+ }
+ }
/**
Allows all Elements the ability to be cloned.
@@ -475,4 +539,5 @@
{
return registryList.isEmpty();
}
+
}
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614535#action_12614535
]
Robert Burrell Donkin commented on ECS-1:
-----------------------------------------
Hi Mauro
Sounds good :-)
ECS was created before the unit testing revolution (if you can remember those days) so I'm
going to need a clear head to analyse the patch. Hopefully, should get to before the end of
the weekend.
Thanks for your patience.
Robert
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip, secondConcreteElement.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Manfrin updated ECS-1:
----------------------------
Attachment: secondConcreteElement.zip
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip, secondConcreteElement.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610191#action_12610191
]
Mauro Manfrin commented on ECS-1:
---------------------------------
Ok, you're right! I'm wrong.
I work on these issue some months ago, and so I forgot these details.
I commented out those lines to avoid confusion, but for binary compatibility that is a problem,
I know.
I have 2 solutions:
1) changing the semantics for the keys enumeration; that enumeration will enumerate only "explictly
given" keys (someone really used that enumeration?)
2) reimplementing a new keys() method (and also deprecating it) to construct an enumeration
of objects in registryList, inventing a new key for all those elements without an "explicitly
given name" (elements not in registry). The new name is something like #@HcAg@#454545 where
454545 is the hascode for the object.
Then, perfecting registry access methods to recognize those names, and looking excplicitly
in registryList for objects with the correct hashcode.
This new implementation of keys() should guarantee binary compatibility, and deprecation of
that method will prevent hascode complex accesses and hascode issues.
For the second solution, I'll attach "secondConcreteElement.zip" with the ConcreteElement.java
class and ConcreteElement.patch (created with NetBeansSvn...hope it works).
That seems to work good; here you have a little test that fills a registry and then empties
that registry:
public static void main(String[] ss) {
Div d=new Div();
d.addElementToRegistry(new BR());
P p=new P();
d.addElementToRegistry("myMainParagraph",p);
d.addElementToRegistry(new Div());
d.addElementToRegistry("string content");
Enumeration e=d.keys();
while (e.hasMoreElements()) {
String s=(String)e.nextElement();
System.out.println(s);
d.removeElement(s);
}
System.out.println(d);
}
What do you think?
Mauro
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610040#action_12610040
]
Robert Burrell Donkin commented on ECS-1:
-----------------------------------------
It's harder for me to work from sample files than a clean patch. Below is the patch that I'm
using (it's a svn diff). It's possible that I haven't been able to convert accurately.
+// public Enumeration keys()
+// {
+// return(registryList.elements());
+// }
is commented out in the patched version and so the patched code looks like it's no longer
binary compatible with the last release.
Robert
Index: src/java/org/apache/ecs/rtf/Alignment.java
===================================================================
--- src/java/org/apache/ecs/rtf/Alignment.java (revision 673206)
+++ src/java/org/apache/ecs/rtf/Alignment.java (working copy)
@@ -131,7 +131,7 @@
*/
public Element removeElementFromRegistry(Element element)
{
- type.removeElementFromRegistry(Integer.toString(element.hashCode()));
+ type.removeElementFromRegistry(element);
return(type);
}
Index: src/java/org/apache/ecs/ConcreteElement.java
===================================================================
--- src/java/org/apache/ecs/ConcreteElement.java (revision 673206)
+++ src/java/org/apache/ecs/ConcreteElement.java (working copy)
@@ -42,7 +42,7 @@
private static String lineSeparator = System.getProperty("line.separator");
/** @serial registry registry */
- private Hashtable registry = new Hashtable(4); // keep a list of elements that need to
be added to the element
+ private Hashtable registry; // keep a list of elements that need to be added to the element
/** Maintain an ordered list of elements */
private Vector registryList = new Vector(2);
@@ -54,13 +54,10 @@
If the object is in the registry return otherwise return null.
@param element the name of the object to locate.
*/
- public ConcreteElement getElement(String element)
+ public ConcreteElement getElement(String name)
{
- if(registry.containsKey(element))
- {
- return (ConcreteElement)registry.get(element);
- }
- return null;
+ if (registry==null) return null;
+ return (ConcreteElement)registry.get(name);
}
/**
@@ -71,7 +68,7 @@
{
if ( element == null )
return(this);
- addElementToRegistry(Integer.toString(element.hashCode()),element);
+ addElementToRegistry(null,element);
return(this);
}
@@ -80,17 +77,20 @@
@param hashcode internal name of element
@param element element to be added to the registry.
*/
- public Element addElementToRegistry(String hashcode,Element element)
+ public Element addElementToRegistry(String name,Element element)
{
- if ( hashcode == null || element == null )
+ if ( element == null )
return(this);
element.setFilterState(getFilterState());
if(ECSDefaults.getDefaultPrettyPrint() != element.getPrettyPrint())
element.setPrettyPrint(getPrettyPrint());
- registry.put(hashcode,element);
- if(!registryList.contains(hashcode))
- registryList.addElement(hashcode);
+ if (name!=null) {
+ if (registry==null) registry=new Hashtable(4);
+ registry.put(name,element);
+ }
+ if(!registryList.contains(element))
+ registryList.addElement(element);
return(this);
}
@@ -105,7 +105,7 @@
if ( element == null )
return(this);
setFilterState(filter);
- addElementToRegistry(Integer.toString(element.hashCode()),element);
+ addElementToRegistry(null,element);
return(this);
}
@@ -114,12 +114,12 @@
@param element element to be added to the registry.
@param filter should we filter this element?
*/
- public Element addElementToRegistry(String hashcode, Element element,boolean filter)
+ public Element addElementToRegistry(String name, Element element,boolean filter)
{
- if ( hashcode == null )
+ if ( name == null )
return(this);
setFilterState(filter);
- addElementToRegistry(hashcode,element);
+ addElementToRegistry(name,element);
return(this);
}
@@ -133,7 +133,7 @@
if ( value == null )
return(this);
setFilterState(filter);
- addElementToRegistry(Integer.toString(value.hashCode()),value);
+ addElementToRegistry(value);
return(this);
}
@@ -143,12 +143,12 @@
@param element element to be added to the registry.
@param filter does this need to be filtered?
*/
- public Element addElementToRegistry(String hashcode, String value,boolean filter)
+ public Element addElementToRegistry(String name, String value,boolean filter)
{
- if ( hashcode == null )
+ if ( name == null )
return(this);
setFilterState(filter);
- addElementToRegistry(hashcode,value);
+ addElementToRegistry(name,value);
return(this);
}
@@ -168,9 +168,9 @@
Registers an element in the head element list
@param element element to be added to the registry.
*/
- public Element addElementToRegistry(String hashcode,String value)
+ public Element addElementToRegistry(String name,String value)
{
- if ( hashcode == null )
+ if ( name == null )
return(this);
// We do it this way so that filtering will work.
@@ -183,7 +183,7 @@
se.setFilterState(getFilterState());
se.setFilter(getFilter());
se.setPrettyPrint(getPrettyPrint());
- addElementToRegistry(hashcode,se);
+ addElementToRegistry(name,se);
return(this);
}
@@ -193,7 +193,7 @@
*/
public Element removeElementFromRegistry(Element element)
{
- removeElementFromRegistry(Integer.toString(element.hashCode()));
+ registryList.remove(element);
return(this);
}
@@ -201,10 +201,11 @@
Removes an element from the head element registry
@param hashcode element to be added to the registry.
*/
- public Element removeElementFromRegistry(String hashcode)
+ public Element removeElementFromRegistry(String name)
{
- registry.remove(hashcode);
- registryList.removeElement(hashcode);
+ if (registry==null) return this;
+ Object o=registry.remove(name);
+ if (o!=null) registryList.removeElement(o);
return(this);
}
@@ -214,32 +215,33 @@
*/
public boolean registryHasElement(Element element)
{
- return(registry.contains(element));
+ return(registryList.contains(element));
}
/**
Get the keys of this element.
*/
- public Enumeration keys()
- {
- return(registryList.elements());
- }
+// public Enumeration keys()
+// {
+// return(registryList.elements());
+// }
/**
Get an enumeration of the elements that this element contains.
*/
public Enumeration elements()
{
- return(registry.elements());
+ return(registryList.elements());
}
/**
Find out if this element is in the element registry.
@param element find out if this element is in the registry
*/
- public boolean registryHasElement(String hashcode)
+ public boolean registryHasElement(String name)
{
- return(registry.containsKey(hashcode));
+ if (registry==null) return false;
+ return(registry.containsKey(name));
}
/**
@@ -262,7 +264,7 @@
int tabLevel = ce.getTabLevel();
try
{
- if (ce.registry.size() == 0)
+ if (ce.registryList.size() == 0)
{
ce.output(out);
}
@@ -281,7 +283,7 @@
while(enum_.hasMoreElements())
{
- Object obj = ce.registry.get((String)enum_.nextElement());
+ Object obj = (Object)enum_.nextElement();
if(obj instanceof GenericElement)
{
Element e = (Element)obj;
@@ -336,7 +338,7 @@
*/
public void output(OutputStream out)
{
- if (this.registry.size() == 0)
+ if (this.registryList.size() == 0)
{
int tabLevel = getTabLevel();
if ((getPrettyPrint() && this instanceof Printable) && (tabLevel >
0))
@@ -376,7 +378,7 @@
{
boolean prettyPrint = getPrettyPrint();
int tabLevel = getTabLevel();
- if (registry.size() == 0)
+ if (registryList.size() == 0)
{
if ((prettyPrint && this instanceof Printable) && (tabLevel > 0))
putTabs(tabLevel, out);
@@ -396,7 +398,7 @@
Enumeration enum_ = registryList.elements();
while(enum_.hasMoreElements())
{
- Object obj = registry.get((String)enum_.nextElement());
+ Object obj = (Object)enum_.nextElement();
if(obj instanceof GenericElement)
{
Element e = (Element)obj;
Index: src/java/org/apache/ecs/xhtml/caption.java
===================================================================
--- src/java/org/apache/ecs/xhtml/caption.java (revision 673206)
+++ src/java/org/apache/ecs/xhtml/caption.java (working copy)
@@ -91,7 +91,7 @@
*/
public caption addElement(String element)
{
- addElementToRegistry(Integer.toString(element.hashCode()),element);
+ addElementToRegistry(element);
return(this);
}
Index: src/java/org/apache/ecs/StringElement.java
===================================================================
--- src/java/org/apache/ecs/StringElement.java (revision 673206)
+++ src/java/org/apache/ecs/StringElement.java (working copy)
@@ -105,7 +105,7 @@
*/
public StringElement addElement(String element)
{
- addElement(Integer.toString(element.hashCode()),element);
+ addElementToRegistry(element);
return(this);
}
Index: src/java/org/apache/ecs/html/Caption.java
===================================================================
--- src/java/org/apache/ecs/html/Caption.java (revision 673206)
+++ src/java/org/apache/ecs/html/Caption.java (working copy)
@@ -77,7 +77,7 @@
*/
public Caption addElement(String element)
{
- addElementToRegistry(Integer.toString(element.hashCode()),element);
+ addElementToRegistry(element);
return(this);
}
Index: src/java/org/apache/ecs/html/Select.java
===================================================================
--- src/java/org/apache/ecs/html/Select.java (revision 673206)
+++ src/java/org/apache/ecs/html/Select.java (working copy)
@@ -177,10 +177,10 @@
public Select selectOption(int option)
{
- Enumeration enum_ = keys();
+ Enumeration enum_ = elements();
for(int x = 0; enum_.hasMoreElements(); x++)
{
- ConcreteElement element = (ConcreteElement)getElement((String)enum_.nextElement());
+ ConcreteElement element = (ConcreteElement)enum_.nextElement();
if(x == option)
{
((Option)element).setSelected(true);
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609824#action_12609824
]
Mauro Manfrin commented on ECS-1:
---------------------------------
I tried an approach like that described by you (checking for existence), before.
The issue is efficiency. That way is slower because it has to check for existence every 'add'
operation. Then, if the objects already exists, it has to generate e second key (how?).
So I tried another approach: generating a key on every add operation, using a counter. That
is possible, but my final solution is much more efficient: it doesn't make use of counters
and it construct Hashtables only if really useful (in a normal construction of a page you'll
rarely want to give a key to a tag).
So my approach is quicker and uses less memory (useful on crowded web servers).
I can't understand when you say that "it's no longer possible to enumerate via keys".
ConcreteElement doesn't have methods to Enumerate via keys! (an why enumerating via a key
beeing the hasCode of elements?)
The only enumerate method in ConcreteElement (elements()) is on the full list on all childs!
And that works good.
So I can't see binary compatibility issues. I'll try to convince you.
The only break in binary compatibility could be that:
if you add an Element to the registry using a key, it is expected that you access that element
via the key or the element itself, but if you add the element without giving it a key, it
is expected that you access that element via the element itself (not via his hascode).
In substance, only code like:
concrete.addElementToRegistry(element);
concrete.removeElementFromRegistry(element.hashCode())
no longer works...but I think that this is a bad code.
It is based on the never stated assumption that ConcreteElement implementation is based on
hascodes!!!
Let me know...
Mauro
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609720#action_12609720
]
Robert Burrell Donkin commented on ECS-1:
-----------------------------------------
The problem with the approach taken in this patch is that it's no longer possible to enumerate
via keys. Though this isn't a complete blocker, it would break binary compatibility and I
would prefer an approach that would preserve this if possible.
Perhaps the real problem is that ECS does not check for the existance of an existing value
which is not identical to the element being registered before setting the value. Perhaps another
value could be used in this case. There may well be other issues with this approach, though.
I need some time to think more on this
Robert
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609702#action_12609702
]
Robert Burrell Donkin commented on ECS-1:
-----------------------------------------
Hi Mauro
I'm going to take a look at these now.
Please bear in mind that patches containing just the differences are preferred. To create
a suitable patch, use svn diff against a checkout.
Robert
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Burrell Donkin reassigned ECS-1:
---------------------------------------
Assignee: Robert Burrell Donkin
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Manfrin updated ECS-2:
----------------------------
Attachment: ECSDefaults.zip
ECSDefaults.zip contains e new version of ECSDefaults.java
capable of changing features like CaseType, Codeset and most of all PrettyPrinting.
This evolution exposes 3 new methods to change those default property values.
> ECSDefaults can be configured only statically from a properties file, not dinamically
> -------------------------------------------------------------------------------------
>
> Key: ECS-2
> URL: https://issues.apache.org/jira/browse/ECS-2
> Project: ECS
> Issue Type: Improvement
> Reporter: Mauro Manfrin
> Attachments: ECSDefaults.zip
>
>
> ECSDefaults can be configured only statically from a properties file, not dinamically.
> I think this is a purposeless.
> But some features like CaseType, Codeset and most of all PrettyPrinting are often needed
to be changed dinamically
> (for example in webapp lifecycle, switching from a test to a production state).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
ECSDefaults can be configured only statically from a properties file, not dinamically
-------------------------------------------------------------------------------------
Key: ECS-2
URL: https://issues.apache.org/jira/browse/ECS-2
Project: ECS
Issue Type: Improvement
Reporter: Mauro Manfrin
ECSDefaults can be configured only statically from a properties file, not dinamically.
I think this is a purposeless.
But some features like CaseType, Codeset and most of all PrettyPrinting are often needed to
be changed dinamically
(for example in webapp lifecycle, switching from a test to a production state).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Manfrin updated ECS-1:
----------------------------
Attachment: ecs-maintrunk-patches.zip
This is a version of ConcreteElement that sotores object in the Map only if you give explicitly
a key-name, otherwise it stores only in the Vector.
That seems to work good, with a good retro-compatibility.
I modified classes since the jakarta ECS SVN repository.
You will find the ConcreteElement class, and subsequent 5 classes adaptions.
Pay attention, these patches are based on the trunk, not the 1.4.2 version.
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
> Reporter: Mauro Manfrin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes we can have
two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
addElement(Element element) methods can fail
--------------------------------------------
Key: ECS-1
URL: https://issues.apache.org/jira/browse/ECS-1
Project: ECS
Issue Type: Bug
Environment: in Ibm Virtual Machines, but probabily also in Sun Virtual Machines
Reporter: Mauro Manfrin
Priority: Critical
The class ConcreteElement exposes a method
addElement(Element element)
that calls
addElementToRegistry(Integer.toString(element.hashCode()),element);
so it gives a key valued element.hashCode() to that element.
That's the point: element.hashCode() can't be a unique key because sometimes we can have two
elements with the same hasocode.
javadoc states:
"It is not required that if two objects are unequal according to the
equals(java.lang.Object) method, then calling the hashCode method on each of
the two objects must produce distinct integer results. However, the
programmer should be aware that producing distinct integer results for
unequal objects may improve the performance of hashtables."
So sometimes, two different objects can have the same hashCode!
So, sometimes two calls to addElement(element) can result in only the second
object stored in the ConcreteElement.
So sometimes, on out instalaltion some table rows misses, or some row cells
misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
On Tue, 2008-06-24 at 18:09 +0200, Mauro Manfrin wrote: > Sure, I'm glad to submit you my patches. > I prepared a zip file with the patches > (but how can I give it to you?). i've created a project in JIRA: https://issues.apache.org/jira/browse/ECS please create an issue and attach your patch > I modified classes since the jakarta ECS SVN repository. > You will find the ConcreteElement class, and subsequent 5 classes adaptions. > Pay attention, these patches are based on the trunk, not the 1.4.2 version. > > What are you planning? A new release? A simple trunk commit? a simple commit will be the first stage once you've confirmed the first works, i'll look into creating a release > I benefit on these contact, for submitting you another very simple > evolution, really usefull for adoption of ecs in frameworks. > ECSDefaults can be configured only statically from a properties file, not > dinamically. > I think this is a purposeless. > But some features like CaseType, Codeset and most of all PrettyPrinting are > often needed to be changed dinamically > (for example in webapp lifecycle, switching from a test to a production > state). > So I propose you a very simple evolution of ECSDefaults class, exposing 3 > methods to change these default property values. > (how can I send you this version?) create aPatch ;-) (and submit using JIRA) - robet
On Tue, 2008-05-27 at 15:06 +0200, Mauro Manfrin wrote: > Hello, hello mauro sorry for the late reply (i know it's no excuse but i've been exceptionally busy) > I'm contacting you to notify a Deep Bug I found on ECS project. > > First of all, I want to tell you that my company and I, use ECS1.4.1 and > then 1.4.2 as a kernel library for HTML page construction. > We use Ecs as a sort of base toolkit for our framework that's the base for > our CRM solutions. > Nowaday, I think that more than 10000 telephone operators use our ecs based > solution, 8 hours a day, in contact center applications. That's a real test > environment. > > Well. In the last installation, we used ecs on an AIX RISC JDK 1.5 platform > and we found a strange bug. > I think that that bug affects all releases of ECS, because of a base mistake > in ConcreteElement.java class. > > Let's go to the real problem: > The class ConcreteElement exposes a method > addElement(Element element) > that calls > addElementToRegistry(Integer.toString(element.hashCode()),element); > so it gives a key valued element.hashCode() to that element. > That's the point: element.hashCode() can't be a unique key because sometimes > we can have two elements with the same hasocode. > We experienced it only on IBM JDK, but the sun documentation (javadoc) > states: > > "It is not required that if two objects are unequal according to the > equals(java.lang.Object) method, then calling the hashCode method on each of > the two objects must produce distinct integer results. However, the > programmer should be aware that producing distinct integer results for > unequal objects may improve the performance of hashtables." > > So sometimes, two different objects can have the same hashCode! > So, sometimes two calls to addElement(element) can result in only the second > object stored in the ConcreteElement. > So sometimes, on out instalaltion some table rows misses, or some row cells > misses or... > > I think that's happening when IBM garbage collector compacts the heap, so > that a new object can get same address (i.e. hashcode) of an old shifted > object. interesting http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6321873 (for example) suggests that this problem would not be limited just to AIX > I've done some fixes to resolve. > I've done a version of ConcreteElement that sotores object in the Map only > if you give explicitly a key-name, otherwise it stores only in the Vector. > That seems to work good, with a good retro-compatibility. that sounds like it would work > I know that ECS is not in a work-inprogress state, but why don't give to the > posterity a bugless software? would you consider donating your patch to Apache? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
Hello, I'm contacting you to notify a Deep Bug I found on ECS project. First of all, I want to tell you that my company and I, use ECS1.4.1 and then 1.4.2 as a kernel library for HTML page construction. We use Ecs as a sort of base toolkit for our framework that's the base for our CRM solutions. Nowaday, I think that more than 10000 telephone operators use our ecs based solution, 8 hours a day, in contact center applications. That's a real test environment. Well. In the last installation, we used ecs on an AIX RISC JDK 1.5 platform and we found a strange bug. I think that that bug affects all releases of ECS, because of a base mistake in ConcreteElement.java class. Let's go to the real problem: The class ConcreteElement exposes a method addElement(Element element) that calls addElementToRegistry(Integer.toString(element.hashCode()),element); so it gives a key valued element.hashCode() to that element. That's the point: element.hashCode() can't be a unique key because sometimes we can have two elements with the same hasocode. We experienced it only on IBM JDK, but the sun documentation (javadoc) states: "It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables." So sometimes, two different objects can have the same hashCode! So, sometimes two calls to addElement(element) can result in only the second object stored in the ConcreteElement. So sometimes, on out instalaltion some table rows misses, or some row cells misses or... I think that's happening when IBM garbage collector compacts the heap, so that a new object can get same address (i.e. hashcode) of an old shifted object. I've done some fixes to resolve. I've done a version of ConcreteElement that sotores object in the Map only if you give explicitly a key-name, otherwise it stores only in the Vector. That seems to work good, with a good retro-compatibility. I know that ECS is not in a work-inprogress state, but why don't give to the posterity a bugless software? I rely on a feedback. Thank you, Mauro --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
Thanks Leo, I don't think there are any plans for any ECS releases, but I've applied the patch to trunk (r574772). Hen On 9/4/07, Leo Davis <ldavis@fonix.com> wrote: > Hello, > > I wanted to make some Java 5 specific changes to ECS 1.4.2, but noticed > it didn't compile with Java 5 out of the tarball. I was able to build > after applying the changes in the attached patch, and it should still > build with Java 1.4. > > Leo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: ecs-dev-help@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
Hello, I wanted to make some Java 5 specific changes to ECS 1.4.2, but noticed it didn't compile with Java 5 out of the tarball. I was able to build after applying the changes in the attached patch, and it should still build with Java 1.4. Leo
Please do. Chris Myers wrote: > This might be a repeat (as it looked like the last email bounced) but... > > I was interested in adding/updating the support for Voice XML, and it looked like 2.0 might be a better match architecturally for what I was looking to do. > > I was wondering if anyone was working on this code, and if not, if anyone would mind if I took up an effort to finish it. > > Thanks in advance, > Chris > > > --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
This might be a repeat (as it looked like the last email bounced) but...
I was interested in adding/updating the support for Voice XML, and it looked like 2.0 might
be a better match architecturally for what I was looking to do.
I was wondering if anyone was working on this code, and if not, if anyone would mind if
I took up an effort to finish it.
Thanks in advance,
Chris
On Mon, 2006-08-14 at 08:16 -0700, Chris Myers wrote: > This might be a repeat (as it looked like the last email bounced) but... > > I was interested in adding/updating the support for Voice XML, and it looked like 2.0 might be a better match architecturally for what I was looking to do. > > I was wondering if anyone was working on this code, and if not, if anyone would mind if I took up an effort to finish it. go right ahead :-) - robert
We're discussing various ideas and thoughts on restructuring Jakarta on the general@jakarta mailing list. On the off chance that someone isn't subscribed to the general@jakarta.apache.org mailing list, I thought I'd drop an email to each of the -dev mailing lists so they have a chance to be involved. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
On Sat, 2006-01-21 at 22:35 +0800, TN wrote: > hi there, > > I got trouble when try to write a simple code using HttpClient to login > MSNSpace website. > the result code of client.executeMethod() is 200, but the page returned say: > JavaScript required to sign in > > what's the problem? how to make a HttpClient instance "enable javascript?" i think you are on the wrong list. this list is for ECS (not httpclient). see http://jakarta.apache.org/site/mail2.html. FWIW i think that your problem is that the website requires javascript to function. httpclient is just that: a HTTP client. to the HTTP protocol, java script is just content data. the problem lies in interpreting that content not in the client used to obtain the data. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
hi there, I got trouble when try to write a simple code using HttpClient to login MSNSpace website. the result code of client.executeMethod() is 200, but the page returned say: JavaScript required to sign in what's the problem? how to make a HttpClient instance "enable javascript?" Regards, TN 2006-1-21
ECS 2.0 may very well predate JUnit. I wrote it many years ago, and abandoned it as I lost interest, and 1.4.x met the needs of most everyone. I'd be happy to review any patches you may have. Zhong ZHENG wrote: >Hi, > >I am writing a wiki engine (http://people.apache.org/~zheng/elsie/) and >would like to use ecs to generate clean html codes. So i chose jakarta ecs. >I found that in SVN an ecs-2.0 branch exists. So how about ecs 2.0? Is it >still under development or already stable for use? > >I checked out the ecs 2.0 branch, and found that all tests were written as >java applications (with public static void main method). So why didn't you >use junit to do the unit tests? I am planning to learn how to use ecs 2.0, >and thus I am modifying the tests by using junit. So if that interests you, >i would be glad to contribute the rewritten unit tests to ecs project. > >Regards. > >-- > >ZHENG Zhong > >1 Avenue Alphand >75116 Paris, France >+33 6 76 80 45 90 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
Hi, I am writing a wiki engine (http://people.apache.org/~zheng/elsie/) and would like to use ecs to generate clean html codes. So i chose jakarta ecs. I found that in SVN an ecs-2.0 branch exists. So how about ecs 2.0? Is it still under development or already stable for use? I checked out the ecs 2.0 branch, and found that all tests were written as java applications (with public static void main method). So why didn't you use junit to do the unit tests? I am planning to learn how to use ecs 2.0, and thus I am modifying the tests by using junit. So if that interests you, i would be glad to contribute the rewritten unit tests to ecs project. Regards. -- ZHENG Zhong 1 Avenue Alphand 75116 Paris, France +33 6 76 80 45 90
Greetings,
I suggest the following change to
ecs-1.4.2-src/src/java/org/apache/ecs/ECSDefaults.java:
@@ -243,7 +243,9 @@
{
resource = ResourceBundle.getBundle("org.apache.ecs.ecs");
} else {
- resource = new java.util.PropertyResourceBundle(new
java.io.FileInputStream(props));
+ ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
+ java.io.InputStream inputStream =
classLoader.getResourceAsStream(props);
+ resource = new
java.util.PropertyResourceBundle(inputStream);
}
// set up variables
----------
... or some variant thereof.
For me this made it easier to use ECS in a servlet with a customized
properties file, which, incidentally, was only necessary because ECS
generates invalid XML by default (i.e. it does not translate "&" into
"&"), but that's a separate gripe... anyway is there some list of
known bugs/issues? I did not see ECS in bugzilla or JIRA.
Thanks,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
robert burrell donkin wrote: >ecs is pretty mature (in some ways finished, in other ways there are >more modern technologies which achieve similar goals) so it's probably a >poor choice... > >(of course, if stephan wants to jump in here with a wonderful new idea, >that'd be great...) > > > I don't really have any wonderful new ideas. I've been toying with the idea of re-writing ECS using Tiger, as some of the new language changes would allow me to implement it the way I originally wanted to. However, as you said ECS is a pretty mature/finished product. I'm amazed and pleased it's still being used and being found useful. I'd be interested in hearing about how ECS is currently being used and if people have any suggestions on how it can be improved upon. I've been doing desktop development for a number of years so I'm not sure what is currently in "fashion" in J2EE web application development. Take care, -stephan --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
On Wed, 2005-06-01 at 03:15 -0400, Matt Warden wrote: > ECS Devs, > > I am interested in a possible project working with ECS for Google's > Summer of Code. The Apache Foundation has already agreed to work with > Google for this program, but there was little information regarding > which specific Apache projects are participating. http://wiki.apache.org/general/SummerOfCode2005 another good place to ask would be general at jakarta. many (most?) java developers at apache are subscribed - or try the incubator. ecs is pretty mature (in some ways finished, in other ways there are more modern technologies which achieve similar goals) so it's probably a poor choice... (of course, if stephan wants to jump in here with a wonderful new idea, that'd be great...) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
ECS Devs, I am interested in a possible project working with ECS for Google's Summer of Code. The Apache Foundation has already agreed to work with Google for this program, but there was little information regarding which specific Apache projects are participating. Here is some information regarding what the role of the ECS project would be, if you are interested: http://code.google.com/mentfaq.html Essentially, the project would receive $500 for acting as a mentor. The responsibilities would include the following (from the FAQ): "Create a pool of ideas for students to choose from. Have a person available to take in student ideas should they not find something that appeals to them. Have a person available to review the incoming applications marked for that organization and decide who should go forward with the effort. Have a person to monitor the progress of the students and mentor them as the project goes forward. Have a person ready to take over for that person in the event they go on vacation, are hit by a bus, etc... Be able to tell us about the developer, how they worked with the group, if they should be invited back should we do another summer of code, etc.." I have used ECS before, and I really like the idea behind it. I have experience with Java, among other languages. Please see my resume at: http://mattwarden.com/MattWarden_resume.pdf Additionally, I currently have an article about to be published on DevX about a topic relating to the use of XMLHttpRequest in Javascript, interacting with a PHP-based "server" script. For a student, I have a relatively large amount of experience and knowledge in the area, and I think I could provide a valuable contribution to your project. If you could let me know of any appropriately-sized projects that might be appropriate for Google's Summer of Code and whether you are interested in the program, I would greatly appreciate it. Thanks, -- Matt Warden Miami University Oxford, OH, USA http://mattwarden.com This email proudly and graciously contributes to entropy. --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org
Cool, good job. Thanks, -stephan Henri Yandell wrote: >jakarta/site updated to list ECS under svn and not cvs. > >ECS site updated to say Source Repositories and not CVS Repositories. > >ECS site now checked out of SVN over http (so can't commit) for the live site. > >Should update over the next 4 hours. > >Hen > >On 5/6/05, Henri Yandell <flamefew@gmail.com> wrote: > > >>These have been migrated. >> >>svn co https://svn.apache.org/repos/asf/jakarta/ecs/trunk ecs >>svn co https://svn.apache.org/repos/asf/jakarta/ecs/branches/ecs2 ecs2 >> >>Unless somebody leaps in, I'll update the site with said instructions >>tonight. I figure for ECS we don't have to stress too much about a >>small period of incorrectness. >> >>Hen >> >>On 5/6/05, Henri Yandell <flamefew@gmail.com> wrote: >> >> >>>Migration happening. Avoid the thousands of CVS commits you want to >>>make on ECS :) >>> >>>Hen >>> >>>On 3/31/05, Henri Yandell <flamefew@gmail.com> wrote: >>> >>> >>>>Now that the Infrathon is done with, thought I'd ping this migration >>>>request to get it back onto the list. >>>> >>>>Hen >>>> >>>>On Wed, 2 Mar 2005 23:38:21 -0500, Henri Yandell <flamefew@gmail.com> wrote: >>>> >>>> >>>>>The Jakarta/ECS community would like to migrate to Subversion please. >>>>> >>>>>******** >>>>>We need to export >>>>> >>>>> jakarta-ecs >>>>> jakarta-ecs2 >>>>> >>>>>to SVN and then lock the CVS modules. >>>>> >>>>>The resulting repo we need is: >>>>> >>>>> /jakarta/ >>>>> /ecs/ >>>>> /branches/ (jakarta-ecs branches) >>>>> /ecs2 (jakarta-ecs2 HEAD) >>>>> /tags/ (jakarta-ecs tags) >>>>> /trunk/ (jakarta-ecs HEAD) >>>>> >>>>>( Note in case indentation is not obvious. It would be: >>>>>/jakarta/ecs/branches/ecs2/ ) >>>>> >>>>>********* >>>>> >>>>>The tags/branches for jakarta-ecs2 are all non-important and may be disregarded. >>>>> >>>>>Hen >>>>> >>>>> >>>>> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org >For additional commands, e-mail: ecs-dev-help@jakarta.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ecs-dev-help@jakarta.apache.org