Re: [jelly] gump taglib breakages
On Wed, 19 Jan 2005, Dion Gillard [EMAIL PROTECTED] wrote: Do you mean the gump build is broken, or the taglibs build in isolation is broken? In the httpclient needs codec now case this really is just a place where the taglib inherits a dependency on commons-codec via commons-httpclient but the project.xml doesn't know this. If you add this, I don't think anything else needs to change and it should be perfectly backwards compatible. AFAIU httpclient 3.x is not that far from a release anyway. I'm happy to fix the builds if they're broken using they're stated dependencies, but as for changing the builds to keep up with HEAD of Jetty or BSF, I don't see the point. Fair enough. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BETWIXT] Betwixt debug logging problem.
--- robert burrell donkin [EMAIL PROTECTED] wrote: this is a bug which has now been fixed on CVS HEAD. please upgrade. hopefully there will be a release sometime soon... thanks. Unfortunately I'm behind firewall, so no CVS access is possible. regards, = [ Konstantin Pribluda ( ko5tik ) ] Plugins for xdoclet-2 are released. check it out at: http://www.sourceforge.net/projects/xdoclet-plugins/ [ http://www.pribluda.de ] __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] RC2?
We should maybe make a round of the bugs submitted, or ? Hans mentioned he wanted to give a stab at JELLY-177, looks good. Looks like JELLY-191 and JELLY-196 could be considered... Any opinion ? paul Le 20 janv. 05, à 06:43, Dion Gillard a écrit : Yep, I'm up for RC2 after some testing and then assuming no showstoppers, a 1.0 straight after. On Thu, 20 Jan 2005 00:32:32 -0500, Hans Gilde [EMAIL PROTECTED] wrote: I couldn't fix the problems with my weak ref implementation, so I tweaked Paul's fix a little to make it thread safe and better for inheritance. Anyway, the memory leak is gone and all unit tests pass after many iterations. Are we ready for an RC2 and, hopefully, a quick release of version 1? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/feedparser build.xml
burton 2005/01/20 00:54:06
Modified:feedparser build.xml
Log:
...
Revision ChangesPath
1.12 +4 -3 jakarta-commons-sandbox/feedparser/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/feedparser/build.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- build.xml 18 Jan 2005 19:39:36 - 1.11
+++ build.xml 20 Jan 2005 08:54:06 - 1.12
@@ -1,6 +1,6 @@
?xml version=1.0 encoding=ISO-8859-1?
-project name=feedparser default=help basedir=.
+project name=feedparser default=jakarta-feedparser.jar basedir=.
property environment=env/
@@ -32,11 +32,12 @@
/fileset
+!-- This is not a good idea. These libs should go in the ant home
dir
+
fileset dir=${ext.lib.path}
-
include name=*.jar/
-
/fileset
+ --
fileset dir=${ant.home}/lib
include name=*.jar/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] gump taglib breakages
Stefan Bodewig wrote: In the httpclient needs codec now case this really is just a place where the taglib inherits a dependency on commons-codec via commons-httpclient but the project.xml doesn't know this. If you add this, I don't think anything else needs to change and it should be perfectly backwards compatible. AFAIU httpclient 3.x is not that far from a release anyway. Yes, in practice this is going to be fine, but its hardly a good practice to introduce a stated dependency on something you're not using. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate AnchorParser.java AnchorParserListener.java ProbeLocator.java
burton 2005/01/20 01:00:37
Modified:feedparser/src/java/org/apache/commons/feedparser
DefaultFeedDirectoryParserListener.java
FeedDirectoryParserListener.java FeedFilter.java
FeedParser.java
feedparser/src/java/org/apache/commons/feedparser/impl
DebugFeedParserListener.java
feedparser/src/java/org/apache/commons/feedparser/locate
AnchorParser.java AnchorParserListener.java
ProbeLocator.java
Added: feedparser/src/java/org/apache/commons/feedparser
HTMLFeedParser.java
Log:
Experimental support for XFN to verify that the format can work within the
FeedParser infra
Revision ChangesPath
1.3 +6 -1
jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/DefaultFeedDirectoryParserListener.java
Index: DefaultFeedDirectoryParserListener.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/DefaultFeedDirectoryParserListener.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DefaultFeedDirectoryParserListener.java 28 Feb 2004 03:35:21 -
1.2
+++ DefaultFeedDirectoryParserListener.java 20 Jan 2005 09:00:37 -
1.3
@@ -39,6 +39,11 @@
public void onItemEnd() throws FeedParserException {}
+public void onRelation( FeedParserState state,
+String value ) {}
+
+public void onRelationEnd() {}
+
public void onFolder( FeedParserState state,
String name ) throws FeedParserException {}
1.3 +37 -8
jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/FeedDirectoryParserListener.java
Index: FeedDirectoryParserListener.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/FeedDirectoryParserListener.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FeedDirectoryParserListener.java 28 Feb 2004 03:35:21 - 1.2
+++ FeedDirectoryParserListener.java 20 Jan 2005 09:00:37 - 1.3
@@ -32,8 +32,12 @@
* dl
* dtFDML/dt
* ddhttp://www.intertwingly.net/wiki/fdml//dd
- * dtOPML/dt
- * dtOCS/dt
+ *
+ * dtOPML (Outline Processor Markup Language)/dt
+ * dtOCS (Open Content Syndication)/dt
+ *
+ * dtXFN (XHTML Friends Network)/dt
+ *
* /dl
*
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton
(burtonator)/a
@@ -42,12 +46,19 @@
public interface FeedDirectoryParserListener extends FeedParserListener {
/**
- * Called when an directory item is found.
+ * Called when an directory item is found. This is compatible with the
+ * FeedParserListener so that existing implementations work. This
provides
+ * a mechanism to index FDML, OPML, OCS, etc with existing feed parsers.
*
- * @param weblog The HTML URL to the root of the weblog.
- * Example. http://www.peerfear.org
+ * @param weblog The HTML URL to the root of the weblog. Example:
+ * http://www.peerfear.org
*
- * @param feed The XML URL to the RSS/Atom feed for this weblog.
+ * @param title The title of the feed or weblog. Maybe be null when not
+ * specified.
+ *
+ * @param feed The XML URL to the RSS/Atom feed for this weblog. This
may
+ * be null in some situations when we don't have a feed URL
+ *
* @see FeedParserListener#onItem
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
*/
@@ -60,8 +71,26 @@
public void onItemEnd() throws FeedParserException;
/**
+ * Called when we've found a relation for a given item. This way you can
+ * specify the relationship you have with a given entry in your
directory.
+ * This is mostly for compatibility purposes with XFN so that the values
can
+ * be 'met', 'date', 'sweetheart', 'friend'.
+ *
+ * For XFN we would call onItem() methods and then onRelation() methods
with
+ * each of the relations passed.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
+ */
+public void onRelation( FeedParserState state,
+String value );
+
+public void onRelationEnd();
+
+/**
* Called when a new Folder is found. If feeds are in the default root
- * folder this method is not called.
+ * folder this method is not called. This is mostly for OPML support but
+ * could be used within other feed
cvs commit: jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate AnchorParserException.java
burton 2005/01/20 01:00:57
Added: feedparser/src/java/org/apache/commons/feedparser/locate
AnchorParserException.java
Log:
...
Revision ChangesPath
1.1
jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate/AnchorParserException.java
Index: AnchorParserException.java
===
/*
* Copyright 1999,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.feedparser.locate;
import java.io.*;
import java.net.*;
import java.util.*;
import java.util.regex.*;
/**
*
*
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
*/
public class AnchorParserException extends Exception {
/**
*
* Create a new codeAnchorParserException/code instance.
*
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
*/
public AnchorParserException() {
}
public AnchorParserException( String message ) {
super( message );
}
public AnchorParserException( Exception e ) {
super( e );
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/feedparser/tests/directory xfn1.html
burton 2005/01/20 01:01:38 Added: feedparser/tests/directory xfn1.html Log: ... Revision ChangesPath 1.1 jakarta-commons-sandbox/feedparser/tests/directory/xfn1.html Index: xfn1.html === html body a href=http://jane-blog.example.org/; rel=sweetheart date metJane/a a href=http://dave-blog.example.org/; rel=friend metDave/a a href=http://darryl-blog.example.org/; rel=friend metDarryl/a a href=http://www.metafilter.com/;MetaFilter/a a href=http://james-blog.example.com/; rel=metJames Expert/a /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Email] To release or not to release
Ok, thanks... build was done. before I now roll the release one question, I got this *test failure* does anyone know more about that? Thanks! Matthias test:test: [junit] Running org.apache.commons.mail.DefaultAuthenticatorTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,21 sec [junit] Running org.apache.commons.mail.EmailAttachmentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 11,206 sec [junit] Running org.apache.commons.mail.EmailTest [junit] Tests run: 36, Failures: 0, Errors: 0, Time elapsed: 4,797 sec [junit] Running org.apache.commons.mail.HtmlEmailTest java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(Unknown Source) at java.net.ServerSocket.bind(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at com.dumbster.smtp.SimpleSmtpServer.run(Unknown Source) at java.lang.Thread.run(Unknown Source) java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(Unknown Source) at java.net.ServerSocket.bind(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at com.dumbster.smtp.SimpleSmtpServer.run(Unknown Source) at java.lang.Thread.run(Unknown Source) [junit] Tests run: 6, Failures: 1, Errors: 1, Time elapsed: 5,909 sec [junit] [ERROR] TEST org.apache.commons.mail.HtmlEmailTest FAILED [junit] Running org.apache.commons.mail.MultiPartEmailTest org.apache.commons.mail.EmailException: javax.mail.NoSuchProviderException: smtp at org.apache.commons.mail.Email.send(Email.java:824) at org.apache.commons.mail.MultiPartEmail.send(MultiPartEmail.java:212) at org.apache.commons.mail.MultiPartEmailTest.testSend(MultiPartEmailTest.j ava:173) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTe stRunner.java:325) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnit Task.java:848) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask .java:556) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask .java:532) at org.apache.tools.ant.Task.perform(Task.java:341) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:616 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at
Re: [jelly] gump taglib breakages
On Thu, 20 Jan 2005, Brett Porter [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: In the httpclient needs codec now case this really is just a place where the taglib inherits a dependency on commons-codec via commons-httpclient but the project.xml doesn't know this. If you add this, I don't think anything else needs to change and it should be perfectly backwards compatible. AFAIU httpclient 3.x is not that far from a release anyway. Yes, in practice this is going to be fine, but its hardly a good practice to introduce a stated dependency on something you're not using. True. But that you are going to use soon 8-) You could upgrade the dependency to httpclient 3.0-beta. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] gump taglib breakages
Yes, in practice this is going to be fine, but its hardly a good practice to introduce a stated dependency on something you're not using. True. But that you are going to use soon 8-) You could upgrade the dependency to httpclient 3.0-beta. Is httpclient 2.0 instantaneously disappearing when 3.0 is released? IMO if a project introduces a major version (or a release otherwise not backwards compatible), and they continue to support the previous version (ie its not archived), then gump should allow a project to build against it. With Jelly approaching (finally) a 1.0 release, its really not the time to be upgrading to beta dependencies :) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33176] New: - copyPropertes(List, List) does not work - pls warn about this
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=33176. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33176 Summary: copyPropertes(List, List) does not work - pls warn about this Product: Commons Version: unspecified Platform: PC URL: http://cvs.apache.org/viewcvs.cgi/jakarta- commons/beanutils/src/java/org/apache/commons/beanutils/ BeanUtilsBean.java?rev=1.17view=markup OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Bean Utilities AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] my application tries to copy a list. List workerList = new ArrayList(); BeanUtils.copyProperties(workerList, msg.getAllRecip()); the size of the ArrayList allRecip in my msg object is 6. After the copy, the size of the workerList remains 0. Sure, workerList.addAll(msg.getAllRecip()); works as an alternative, but wouldn't it be appropriate to warn the user of copyProperties ? Might be related to Bug 16206 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57828 ] Paul Libbrecht commented on JELLY-85: - Is thread guarantees the following excerpt of Tag interface javadoc? A Tag is only ever used by a single thread so that Tag developers do not need to concern themselves with mutli-threading issues when writing a Tag. Wouldn't i be simpler to say that Thread safety is guaranteed by the usage of a single context per thread ? Or do you have situations where a single context is used by several threads ? My tests and personal usages are fine with the current status of the tags, even with your memory-leak-test. paul TagScript doesn't clear its cached tags after run() --- Key: JELLY-85 URL: http://issues.apache.org/jira/browse/JELLY-85 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0-beta-4 Reporter: Scott Howlett Attachments: StaticTagScript_patch.txt, TagScript_patch.txt, includeAndDefineExample.zip TagScript caches the tags it generates in a ThreadLocal. At the beginning of run() it checks to see if the context wants to cache tags - if not, it clears the cache and regenerates it. But there is no corresponding check and cache clearing at the end of run(). So if a tag holds onto some significant resource, that resource will hang around until the thread goes away or until the tag is run again. I am using Jelly Swing extensively, and various tags end up attached to the AWT Event thread for the lifetime of my application. As a quick fix, I have a patch that simply repeats the check-and-clear-cache behavior at the end of TagScript.run(). I also have a patch that adds this behavior to StaticTagScript, whose run() never seems to clear cached tags. I am probably just unclear, but it seems to me that there is a deeper issue as well - the context is being asked whether it wants to cache tags, but the result of this question affects the TagScript, which is really independent of the context. It seems like if context wants to cache tags, perhaps the ThreadLocal used for their storage ought to belong to the context somehow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33176] - [beanutils] copyProperties(List, List) does not work - pls warn about this
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=33176. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33176 [EMAIL PROTECTED] changed: What|Removed |Added Summary|copyPropertes(List, List) |[beanutils] |does not work - pls warn|copyProperties(List, List) |about this |does not work - pls warn ||about this -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JXPath] On contributing XOM-support
I think we will have to wait 'till the issues around the licenses are resolved. I am very sorry about that. For now I could put a link on the JXPath home page pointing to your site. I hope that this issue will be resolved. A link to my site and any comments are welcome. Once again, thank you. Shirasu, what you could do is to ask the XOM guys for either dual licensing or considering using the Apache license. ...maybe worth a shot. Thanks for you contribution! The legal stuff is alway a pain. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] API - methods for logging entry and exit events
Tomas Znamenacek wrote:
4. The event of method entry or exit is a trace kind of event and should
not be logged at different severity(should not have a method on the logging
interface) but it should be encapsulated in the message that is being
logged. Also, some enter/exit events might have more importance than
others, therefore the fact that an event represents enter or exit point
should be a state of the message not its severity.
The proposed interface will allow us to make a logging call for method
enter/exit event without having to create another object(message object)
and set the enter/exit flag on it.
If there is a logging implementation that allows the enter/exit be a flag
on message object, the wrapper for this implementation can certainly have
the enter/exit methods implemented that way.
When enter/exit events need to be logged on different levels, we start
talking about two dimensional space of logging events. Adding support for
this into a thin wrapper that is designed to bridge many(all?) different
APIs, will get too complicated and would loose the simplicity and ease of
use.
Indeed, it's still possible with:
if (log.isDebugEnabled()) {
log.enter(this, foo);
}
There is no need for a level parameter on the enter/exit methods.
Emmanuel Bourg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] gump taglib breakages
On Thu, 20 Jan 2005, Brett Porter [EMAIL PROTECTED] wrote: Is httpclient 2.0 instantaneously disappearing when 3.0 is released? Don't most projects think that way? There are some honorary exceptions, but how often do you see use 2.x instead if users find a bug in 1.x? Moving these philosophical discussions out of the way IMO if a project introduces a major version (or a release otherwise not backwards compatible), and they continue to support the previous version (ie its not archived), then gump should allow a project to build against it. Gump does. There is a project descriptor for the httpclient 2.x branch, that you could build against. project name=commons-httpclient-2.0-branch You may find it requires commons-codec as well, though. Not sure about httpclient 2.0.2, which is their latest non-beta release. With Jelly approaching (finally) a 1.0 release, its really not the time to be upgrading to beta dependencies :) Understood. So you are going to have a final release of forehead before that? Just kidding. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] gump taglib breakages
Is httpclient 2.0 instantaneously disappearing when 3.0 is released? Don't most projects think that way? There are some honorary exceptions, but how often do you see use 2.x instead if users find a bug in 1.x? Yes, but if it is working fine, there is rarely motivation to move just because. Gump does. There is a project descriptor for the httpclient 2.x branch, that you could build against. project name=commons-httpclient-2.0-branch Ok, sorry. I should have checked that first. I'll give that a try. With Jelly approaching (finally) a 1.0 release, its really not the time to be upgrading to beta dependencies :) Understood. So you are going to have a final release of forehead before that? beta-5 is a final release - the code hasn't been touched since ;) Actually, we've already discussed folding forehead into Jelly and getting rid of the dependency. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] RC2?
Looks good in Maven 1.1 HEAD. Still leaking memory in multiproject sites, but I haven't done any recent work to isolate the cause of that. JSL remains the suspect, but nothing solid to back that. +1 on an RC2 release after standing bugs are fixed. - Brett Dion Gillard wrote: Yep, I'm up for RC2 after some testing and then assuming no showstoppers, a 1.0 straight after. On Thu, 20 Jan 2005 00:32:32 -0500, Hans Gilde [EMAIL PROTECTED] wrote: I couldn't fix the problems with my weak ref implementation, so I tweaked Paul's fix a little to make it thread safe and better for inheritance. Anyway, the memory leak is gone and all unit tests pass after many iterations. Are we ready for an RC2 and, hopefully, a quick release of version 1? Hans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sandbox VFS
Hello, I'm trying to use the wonderful VFS. It works quite well but I've a problem with writing in zip file. Searching for informations, I wonder if VFS is still a live project and if sometimes, it will leave the sandbox to become a complete Jakarta-Common project ? I want to use it in a professionnal application and I need to be sure the project goes on (I can't really maintain all that code alone but I can help if necessary). Thanks for your response... Stéphane. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[commons-el] new release?
Hi folks, on your project site the last release is from 2003. There are some changes in CVS that aren't reflected by the shipped JAR. eg. Logger replaced by [commons-logging] eg. Coercions' methods refactored... Do you plan to roll out a new release? That contains these changes? Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JXPath] unordered node-sets
Dmitri, Dmitri Plotnikov dmitri at apache.org writes: Ok, I think I now get it. Sorry about having been so obtuse. To make the search interruptable, we should eliminate the isChildOrderingRequired method. Actually I don't even know why we have it. Paths like //foo would produce results in the right order even without it. Try this: comment out the DescendantContext#isChildOrderingRequired method. Let me know if it makes a difference. If it does without breaking anything else, I will make the change permanent. Yes, that change did help! I will still leave my dirty hack in for interrupting other kinds of badly written expressions. Cheers, --knut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JXPath] On contributing XOM-support
Dear Torsten, Thank you very much for your advice. I will try to negotiate with them for a different licence. Thanks, -- shirasu hiroyuki([EMAIL PROTECTED]) From: Torsten Curdt [EMAIL PROTECTED] Subject: Re: [JXPath] On contributing XOM-support Date: Thu, 20 Jan 2005 11:19:15 +0100 snip/ what you could do is to ask the XOM guys for either dual licensing or considering using the Apache license. ...maybe worth a shot. Thanks for you contribution! The legal stuff is alway a pain. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] 1.0.5 release
+1 from me. On Wed, 19 Jan 2005 20:26:01 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: +1 Craig On Wed, 19 Jan 2005 22:49:09 +, robert burrell donkin [EMAIL PROTECTED] wrote: IMO the first step before any work can begin on any improvements is to release the current code (this contains an important enhancement improving memory release in the 1.0.x series of releases). therefore, i propose that we should start the release process for 1.0.5 by electing a release manager and formulating a release plan. i'm willing to act as release manager for this release. my vision would be that a release branch would be taken as soon as possible but with a long release candidate phase would follow to allow the release to be tested. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-177) In JellyServlet, the procedure used to determine the script's location is too simplistic
[ http://issues.apache.org/jira/browse/JELLY-177?page=history ]
dion gillard updated JELLY-177:
---
Version: 1.0-beta-5
1.0-RC1
(was: 1.0)
Fix Version: 1.0-RC2
In JellyServlet, the procedure used to determine the script's location is too
simplistic
Key: JELLY-177
URL: http://issues.apache.org/jira/browse/JELLY-177
Project: jelly
Type: Bug
Components: core / taglib.core
Versions: 1.0-beta-5, 1.0-RC1
Environment: Servlet, 1.0RC1
Reporter: Denis Robert
Priority: Minor
Fix For: 1.0-RC2
In JellyServlet, the procedure used to determine the script's location is too
simplistic; it misses simple cases like the a *.jelly servlet-mapping.
I suggest replacing the getScript method with something like (taken in part
from the Freemarker servlet):
protected URL getScript(HttpServletRequest req)
throws MalformedURLException {
String scriptUrl = null;
String includedPath = (String)
req.getAttribute(javax.servlet.include.servlet_path);
if (includedPath != null) { //This is the result of a
RequestDispatcher include...
String includedPathInfo = (String)
req.getAttribute(javax.servlet.include.path_info);
if (includedPathInfo != null) {
scriptUrl = includedPathInfo;
} else {
scriptUrl = includedPath;
}
} else {
scriptUrl = req.getParameter(script);
if (scriptUrl == null) {
scriptUrl = req.getPathInfo();
}
if (scriptUrl == null) {
scriptUrl = req.getServletPath();
}
}
URL url = getServletContext().getResource(scriptUrl);
if (url == null) {
throw new IllegalArgumentException(Invalid script url:
+ scriptUrl);
}
return url;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] sandbox VFS
Stéphane Rault wrote: I'm trying to use the wonderful VFS. It works quite well but I've a problem with writing in zip file. Searching for informations, I wonder if VFS is still a live project and if sometimes, it will leave the sandbox to become a complete Jakarta-Common project ? I want to use it in a professionnal application and I need to be sure the project goes on (I can't really maintain all that code alone but I can help if necessary). Well, VFS is alive in a manner that I try to fix major problems and reported bugs. I decided to go in small steps as I use it in our project as java.io.File replacement (where possible) and thus have to ensure its stability. Currently I feel very comfortable about its stability. As soon as I have more time I would like to implement something like file-locking. You are right, I too think its time to discuss a plan how to migrate it to commons proper - I planed to poll for it in a couple of months. Not sure what the community thinks about it. --- Mario smime.p7s Description: S/MIME Cryptographic Signature
Re: [vfs] sandbox VFS
Mario Ivankovits wrote: Well, VFS is alive in a manner that I try to fix major problems and reported bugs. I decided to go in small steps as I use it in our project as java.io.File replacement (where possible) and thus have to ensure its stability. Currently I feel very comfortable about its stability. As soon as I have more time I would like to implement something like file-locking. Yes, and the NFS support would be interesting too.. I saw it in the TO DO List. You are right, I too think its time to discuss a plan how to migrate it to commons proper - I planed to poll for it in a couple of months. Not sure what the community thinks about it. Sure that it would be a good idea. !! So, for now, I decided to keep it in my project but in a secure way (I encapsulate it in a single class to change it more easily.) In some weeks, I will be more free time and I will spend some time reading the sources. Thanks for answering... Stéphane. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] sandbox VFS
You are right, I too think its time to discuss a plan how to migrate it to commons proper - I planed to poll for it in a couple of months. Not sure what the community thinks about it. Hi -- I use it as a crucial piece of one of my projects and it's behaving beautifully.. I'm all for moving it to commons proper.. Cheers, - Filip PS: any specs for what you'd like to do file locking wise? It's one of the things I need next, so maybe I can help? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vfs] file locking
[EMAIL PROTECTED] wrote: PS: any specs for what you'd like to do file locking wise? It's one of the things I need next, so maybe I can help? I would like to see what [transaction] http://jakarta.apache.org/commons/transaction/ do and if this could be used for this purpose. A first look at it seems promising. If possible the lock should be passed to the real filesystem too. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox VFS
Stéphane Rault wrote:
I'm trying to use the wonderful VFS. It works quite well but I've a
problem with writing in zip file. Searching for informations, I wonder
if VFS is still a live project and if sometimes, it will leave the
sandbox to become a complete Jakarta-Common project ?
I'd like to see some more utility methods for manipulating file objects.
For example, much of my code needs:
void saveAs() throws IOException;
void moveTo() throws IOException;
void copyTo() throws IOException;
I use these as high-level operations which use do-or-die semantics
(succeed or throw an exception) and call more basic file object
operations to do the work. Here is the implementation of saveAs() with
a lot of things unexplained (but I use readable names, so I hope that
helps -- a WhimFile is just a java.io.File with these extra operations;
I'm using it to demonstrate my ideas to my coworkers):
private static void saveMaybeBackup(final WhimFile original,
final InputStream newContents, final boolean keepBackup)
throws IOException {
final WhimFile scratch = original.createTempWhimFile(save, null);
try {
copyAndClose(newContents, scratch.getOutputStream());
if (keepBackup original.exists())
original.moveToWithOverwrite(original.createBackupFile());
// TODO: if scratch.moveTo throws, restore original from backup?
scratch.moveToWithOverwrite(original);
} finally {
scratch.delete();
}
}
Cheers,
--binkley
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[vfs] more FileUtils
B. K. Oxley (binkley) wrote: I'd like to see some more utility methods for manipulating file objects. For example, much of my code needs: void saveAs() throws IOException; void moveTo() throws IOException; void copyTo() throws IOException; For sure, we could introduce a FileUtils, but ... private static void saveMaybeBackup(final WhimFile original, ... this MaybeBackup is a thing we could discuss at its own. How should a backup be done and named? a) backup to *.bak b) use versioning - e.g. *.bak_01, *.bak_02 b.1) with max versions c) use timestamping - e.g. *.bak_20050101 c.1) but not more than 20 backups and so on. Said that, I think, if such a method allows a BackupPolicy and we provide SimpleBackupPolicy (case a) and NoBackupPolicy this could be a real enhancement. Could you please post a proposal about the methods and its functions you would like to see. This would be a great start. Thanks! Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] more FileUtils
Mario Ivankovits wrote: ... this MaybeBackup is a thing we could discuss at its own. How should a backup be done and named? a) backup to *.bak b) use versioning - e.g. *.bak_01, *.bak_02 b.1) with max versions c) use timestamping - e.g. *.bak_20050101 c.1) but not more than 20 backups Just an example. What I did was give the WhimFile instance methods to cover these cases so that extending classes could implement their own policy. I didn't intend to clutter my example with these issues! I should be more careful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] more FileUtils
Brian Oxley wrote: Mario Ivankovits wrote: ... this MaybeBackup is a thing we could discuss at its own. How should a backup be done and named? a) backup to *.bak b) use versioning - e.g. *.bak_01, *.bak_02 b.1) with max versions c) use timestamping - e.g. *.bak_20050101 c.1) but not more than 20 backups Just an example. What I did was give the WhimFile instance methods to cover these cases so that extending classes could implement their own policy. I didn't intend to clutter my example with these issues! I should be more careful. No No - my fault, I tend to be a little bit rush if it comes to new functions and then such details comes into my mind too early. Is there a format I should follow in writing said proposal? I think it is sufficient if you just write it into a mail. Method(args, ...) Description Method(args, ...) Description ... and so on. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33184] New: - ability to set a default Locale on the ValidatorResources
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=33184. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33184 Summary: ability to set a default Locale on the ValidatorResources Product: Commons Version: unspecified Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P2 Component: Validator AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] ValidatorResources's getForm(() method will fall back to its static field 'defaultLocale' when no Locale information is specified. This defaultLocale is essentially Locale.getDefault() call. In our app, we need to support two business cases where in one we want en_US as the default but in the other we want en_UK as the default. We want to be able to set the default locale on the ValidatorResources created for these two business cases. If there is a getDefaultLocale() method on the ValidatorResources that can return the static default Locale object only when the instance default object is not set. Then existing behavior will be kept where the client is also given a chance to set the default as needed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33185] New: - testSaveInvalidURL in TestFileConfiguration fails
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=33185. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33185 Summary: testSaveInvalidURL in TestFileConfiguration fails Product: Commons Version: unspecified Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Configuration AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The newly added test testSaveInvalidURL in TestFileConfiguration fails because config.save(http://www.apache.org;) does not fail as anticipated. This statement actually succeeds in creating a subdirectory http: and creates the file www.apache.org in it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33184] - [validator] Ability to set a default Locale on the ValidatorResources
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=33184. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33184 [EMAIL PROTECTED] changed: What|Removed |Added Summary|ability to set a default|[validator] Ability to set a |Locale on the |default Locale on the |ValidatorResources |ValidatorResources -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33185] - [configuration] testSaveInvalidURL in TestFileConfiguration fails
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=33185. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33185 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |minor Summary|testSaveInvalidURL in |[configuration] |TestFileConfiguration fails |testSaveInvalidURL in ||TestFileConfiguration fails -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: Logging
Date: 2005-01-20T14:46:13 Editor: 82.38.65.173 Wiki: Jakarta Commons Wiki Page: Logging URL: http://wiki.apache.org/jakarta-commons/Logging Added link to 1.0.5 release development page Change Log: -- @@ -10,7 +10,7 @@ * /[How to Configure the Logging Factory and the Logging Class] * /[Commons Logging FUD] * [:/1.0.4ReleasePlan] - + * [:/1.0.5ReleasePlan] == Related == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] New: Logging/1.0.5ReleasePlan
Date: 2005-01-20T14:59:55 Editor: 82.38.65.173 Wiki: Jakarta Commons Wiki Page: Logging/1.0.5ReleasePlan URL: http://wiki.apache.org/jakarta-commons/Logging/1.0.5ReleasePlan Created release plan New Page: = Commons Logging 1.0.5 ReleasePlan = == Background == JCL 1.0.4 was release in July. The 1.0.x codebase is mature and most of the limitations of the design are well understood. A small number of improvements have been made since this release some very important for some use cases. There is now considerable interest in pushing JCL onwards from this codebase. The time seems apt for the release of JCL1.0.5 == Status == RELEASE PLAN UNDER DEVELOPMENT = Pre-Release Tasks = Anyone who wants to volunteer for a task, just add something == Documentation Review == * Ensure that javadocs and website are up to date. * The new optional distribution which offers enhanced memory recycling in some environments needs documentation creating. == Bug Review == == Bug Fix == == Test Compatibility == As a point release, this should be fully backwards compatible. This needs checking. == Release Notes == This will be prepared in the traditional way (by using CVS commit logs). = Release Plan = == Repository == A release branch will be taken as soon as the preliminary work is complete. This will allow work to continue on HEAD. If possible, this step should be postponed until after jakarta commons is converted to SVN. == Release Notes == Any changes made after the branch is taken and code frozen will be added as they are made. == Release Candidate == A release candidate will be prepared. Since backwards and future compatibility with Log4J is of crucial importance, users and developers will be asked to test their current installations with the release candidate. Therefore a suitable gap (to allow this testing) will be left between the announcement of the release and the release vote. Committers will be encouraged to test this RC on their own application before VOTEing +1. = Post Release = == Process Bugs Marked Later == = Comments = * Version compiled on jdk1.4 doesn't seem to work on JDk1.3. Therefore, the jdk14Logger needs to be compiled with 1.4 and everything else with 1.3 for the release. Up to [:Logging] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: Logging/1.0.5ReleasePlan
Date: 2005-01-20T15:01:03 Editor: 82.38.65.173 Wiki: Jakarta Commons Wiki Page: Logging/1.0.5ReleasePlan URL: http://wiki.apache.org/jakarta-commons/Logging/1.0.5ReleasePlan no comment Change Log: -- @@ -6,7 +6,7 @@ == Status == -RELEASE PLAN UNDER DEVELOPMENT +DRAFT RELEASE PLAN UNDER DEVELOPMENT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] 1.0.5 release
On 19 Jan 2005, at 22:51, Richard Sitze wrote: robert burrell donkin [EMAIL PROTECTED] wrote on 01/19/2005 04:49:09 PM: snip i'm willing to act as release manager for this release. my vision would be that a release branch would be taken as soon as possible but with a long release candidate phase would follow to allow the release to be tested. ... waiting to see your release plan ;-) http://wiki.apache.org/jakarta-commons/Logging/1_2e0_2e5ReleasePlan - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BETWIXT] Betwixt debug logging problem.
On 20 Jan 2005, at 08:40, Konstantin Priblouda wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: this is a bug which has now been fixed on CVS HEAD. please upgrade. hopefully there will be a release sometime soon... thanks. Unfortunately I'm behind firewall, so no CVS access is possible. then use a recent nightly or even cvsgrab :) the release should happen once jakarta commons has converted to SVN. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/xmlunit XmlTestCase.java
rdonkin 2005/01/20 15:09:45
Modified:betwixt/src/java/org/apache/commons/betwixt/schema
ComplexType.java Element.java ElementReference.java
GlobalComplexType.java GlobalElement.java
LocalComplexType.java Schema.java
betwixt/src/test/org/apache/commons/betwixt/schema
TestSchemaGeneration.java
betwixt/src/test/org/apache/commons/betwixt/xmlunit
XmlTestCase.java
Log:
Fixed buggy behaviour when creating schema for beans with cyclic graphs. Unit
tests contributed by Susan Liu. Issue#33168
Revision ChangesPath
1.3 +20 -6
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/ComplexType.java
Index: ComplexType.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/ComplexType.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ComplexType.java 16 Jun 2004 11:21:26 - 1.2
+++ ComplexType.java 20 Jan 2005 23:09:44 - 1.3
@@ -25,6 +25,9 @@
import org.apache.commons.betwixt.XMLBeanInfo;
/**
+ * Models a codecomplexType/code.
+ * Global (top level) complex types are represented by [EMAIL PROTECTED]
GlobalComplexType}.
+ * Locally defined or referenced complex types are represented by [EMAIL
PROTECTED] LocalComplexType}.
* @author a href='http://jakarta.apache.org/'Jakarta Commons Team/a
* @version $Revision$
*/
@@ -37,6 +40,17 @@
public ComplexType() {}
public ComplexType(TranscriptionConfiguration configuration,
ElementDescriptor elementDescriptor, Schema schema) throws
IntrospectionException {
+elementDescriptor = fillDescriptor(elementDescriptor, schema);
+init(configuration, elementDescriptor, schema);
+}
+
+/**
+ * @param elementDescriptor
+ * @param schema
+ * @return
+ * @throws IntrospectionException
+ */
+protected ElementDescriptor fillDescriptor(ElementDescriptor
elementDescriptor, Schema schema) throws IntrospectionException {
if (elementDescriptor.isHollow()) {
// need to introspector for filled descriptor
Class type = elementDescriptor.getSingularPropertyType();
@@ -46,7 +60,7 @@
XMLBeanInfo filledBeanInfo = schema.introspect(type);
elementDescriptor = filledBeanInfo.getElementDescriptor();
}
-init(configuration, elementDescriptor, schema);
+return elementDescriptor;
}
protected void init(TranscriptionConfiguration configuration,
ElementDescriptor elementDescriptor, Schema schema) throws
IntrospectionException {
@@ -79,7 +93,7 @@
* @return
*/
public List getElements() {
- return elements;
+ return elements;
}
/**
@@ -87,7 +101,7 @@
* @param element
*/
public void addElement(ElementReference element) {
- elements.add(element);
+elements.add(element);
}
/**
@@ -104,7 +118,7 @@
* @return
*/
public List getAttributes() {
- return attributes;
+return attributes;
}
/**
@@ -112,7 +126,7 @@
* @param attribute
*/
public void addAttribute(Attribute attribute) {
- attributes.add(attribute);
+ attributes.add(attribute);
}
}
1.3 +2 -1
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Element.java
Index: Element.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Element.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Element.java 16 Jun 2004 11:21:26 - 1.2
+++ Element.java 20 Jan 2005 23:09:44 - 1.3
@@ -17,6 +17,7 @@
package org.apache.commons.betwixt.schema;
/**
+ * Implmented by codeelement/code definition.
* @author a href='http://jakarta.apache.org/'Jakarta Commons Team/a
* @version $Revision$
*/
1.3 +2 -3
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/ElementReference.java
Index: ElementReference.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/ElementReference.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ElementReference.java 16 Jun 2004 11:21:26 - 1.2
+++ ElementReference.java 20 Jan 2005 23:09:44 - 1.3
@@ -42,8 +42,7 @@
public
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema TestRecursiveBeanSchemaGeneration.java
rdonkin 2005/01/20 15:10:05
Added: betwixt/src/test/org/apache/commons/betwixt/schema
TestRecursiveBeanSchemaGeneration.java
Log:
Fixed buggy behaviour when creating schema for beans with cyclic graphs. Unit
tests contributed by Susan Liu. Issue#33168
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/TestRecursiveBeanSchemaGeneration.java
Index: TestRecursiveBeanSchemaGeneration.java
===
/*
* Copyright 2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.betwixt.schema;
import java.io.StringWriter;
import junit.framework.Test;
import junit.framework.TestSuite;
import junit.textui.TestRunner;
import org.apache.commons.betwixt.AbstractTestCase;
import org.apache.commons.betwixt.io.BeanWriter;
import org.xml.sax.InputSource;
/**
* @author a href='http://jakarta.apache.org/commons'Jakarta Commons
Team/a, a href='http://www.apache.org'Apache Software Foundation/a
*/
public class TestRecursiveBeanSchemaGeneration extends AbstractTestCase{
public TestRecursiveBeanSchemaGeneration(String name) {
super(name);
}
public static void main( String[] args ) {
TestRunner.run( suite() );
}
/**
* A unit test suite for JUnit
*/
public static Test suite() {
return new TestSuite(TestRecursiveBeanSchemaGeneration.class);
}
public void testLoopBeanWithAttributes() throws Exception {
SchemaTranscriber transcriber = new SchemaTranscriber();
transcriber.getXMLIntrospector().getConfiguration().setAttributesForPrimitives(true);
Schema schema = transcriber.generate(LoopBean.class);
StringWriter out = new StringWriter();
out.write(?xml version='1.0'?);
BeanWriter writer = new BeanWriter(out);
writer.setBindingConfiguration(transcriber.createSchemaBindingConfiguration());
writer.getXMLIntrospector().setConfiguration(transcriber.createSchemaIntrospectionConfiguration());
writer.write(schema);
String xsd = out.getBuffer().toString();
//The expected schema is manual generated, may not be completely
match the betwixt generated
String expected =?xml version='1.0'?xsd:schema
xmlns:xsd='http://www.w3.org/2001/XMLSchema' +
xsd:element name='LoopBean'
type='org.apache.commons.betwixt.schema.LoopBean'/ +
xsd:complexType
name='org.apache.commons.betwixt.schema.LoopBean' +
xsd:sequence +
xsd:element name='friend'
type='org.apache.commons.betwixt.schema.LoopBean' minOccurs='0'
maxOccurs='1'/ +
/xsd:sequence +
xsd:attribute name='name' type='xsd:string'/ +
/xsd:complexType +
/xsd:schema;
xmlAssertIsomorphicContent(parseString(expected), parseString(xsd));
LoopBean loopBean = new LoopBean(Harry);
loopBean.setFriend(new LoopBean(Sally));
out = new StringWriter();
out.write(?xml version='1.0'?);
writer = new BeanWriter(out);
writer.getBindingConfiguration().setMapIDs(false);
writer.getXMLIntrospector().getConfiguration().setAttributesForPrimitives(true);
writer.write(loopBean);
String xml = out.getBuffer().toString();
xmlAssertIsValid(xml, xsd);
}
public void testCyclicBean() throws Exception {
SchemaTranscriber transcriber = new SchemaTranscriber();
transcriber.getXMLIntrospector().getConfiguration().setAttributesForPrimitives(true);
Schema schema = transcriber.generate(CyclicBean.class);
StringWriter out = new StringWriter();
out.write(?xml version='1.0'?);
BeanWriter writer = new BeanWriter(out);
writer.setBindingConfiguration(transcriber.createSchemaBindingConfiguration());
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema ParentColumn.java
rdonkin 2005/01/20 15:10:20
Added: betwixt/src/test/org/apache/commons/betwixt/schema
ParentColumn.java
Log:
Fixed buggy behaviour when creating schema for beans with cyclic graphs. Unit
tests contributed by Susan Liu. Issue#33168
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/ParentColumn.java
Index: ParentColumn.java
===
/*
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.betwixt.schema;
/**
* p This is a bean specifically designed to test cyclic references.
* The idea is that there's a count that counts every time
codegetFriend/code
* gets called and throws a codeRuntimeException/code if the count gets
too high./p
*
* @author a href='http://jakarta.apache.org/commons'Jakarta Commons
Team/a, a href='http://www.apache.org'Apache Software Foundation/a
*/
public class ParentColumn {
private String name;
public ParentColumn(String name)
{
this.name = name;
}
public String getName()
{
return name;
}
public String toString()
{
return [ParentColumn] name= + name;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema LoopBean.java
rdonkin 2005/01/20 15:11:18
Added: betwixt/src/test/org/apache/commons/betwixt/schema
LoopBean.java
Log:
Fixed buggy behaviour when creating schema for beans with cyclic graphs. Unit
tests contributed by Susan Liu. Issue#33168
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/LoopBean.java
Index: LoopBean.java
===
/*
* Copyright 2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.betwixt.schema;
/**
* @author a href='http://jakarta.apache.org/commons'Jakarta Commons
Team/a, a href='http://www.apache.org'Apache Software Foundation/a
*/
public class LoopBean {
private static int count = 0;
private static final int max_count = 100;
private LoopBean friend;
private String name;
public LoopBean(String name)
{
this.name = name;
}
public LoopBean getFriend()
{
if (++count max_count)
{
throw new RuntimeException(Looping!);
}
return friend;
}
public void setFriend(LoopBean friend)
{
this.friend = friend;
}
public String getName()
{
return name;
}
public String toString()
{
return [LoopBean] name= + name;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema CyclicBean.java
rdonkin 2005/01/20 15:12:37
Added: betwixt/src/test/org/apache/commons/betwixt/schema
CyclicBean.java
Log:
Fixed buggy behaviour when creating schema for beans with cyclic graphs. Unit
tests contributed by Susan Liu. Issue#33168
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/CyclicBean.java
Index: CyclicBean.java
===
/*
* Copyright 2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.betwixt.schema;
import java.util.Vector;
/**
* p This is a bean specifically designed to test cyclic references.
* The idea is that there's a count that counts every time
codegetFriend/code
* gets called and throws a codeRuntimeException/code if the count gets
too high./p
*
* @author a href='http://jakarta.apache.org/commons'Jakarta Commons
Team/a, a href='http://www.apache.org'Apache Software Foundation/a
*/
public class CyclicBean {
private Vector layers = new Vector(); //CyclicLayer
private String name;
public CyclicBean(String name)
{
this.name = name;
}
public Vector getLayers()
{
return this.layers;
}
public void setLayers(Vector vLayers)
{
this.layers = vLayers;
}
public void addLayer(CyclicLayer aLayer)
{
layers.add(aLayer);
}
public String getName()
{
return name;
}
public String toString()
{
return [CyclicBean] name= + name;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema CyclicColumn.java
rdonkin 2005/01/20 15:13:51
Added: betwixt/src/test/org/apache/commons/betwixt/schema
CyclicColumn.java
Log:
Fixed buggy behaviour when creating schema for beans with cyclic graphs. Unit
tests contributed by Susan Liu. Issue#33168
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/CyclicColumn.java
Index: CyclicColumn.java
===
/*
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.betwixt.schema;
/**
* p This is a bean specifically designed to test cyclic references.
* The idea is that there's a count that counts every time
codegetFriend/code
* gets called and throws a codeRuntimeException/code if the count gets
too high./p
*
* @author a href='http://jakarta.apache.org/commons'Jakarta Commons
Team/a, a href='http://www.apache.org'Apache Software Foundation/a
*/
public class CyclicColumn extends ParentColumn {
private static int count = 0;
private static final int max_count = 100;
private CyclicBean bean;
public CyclicColumn(String name)
{
super(name);
}
public CyclicBean getBean()
{
if (++count max_count)
{
throw new RuntimeException(Cyclic Reference!);
}
return bean;
}
public void setBean(CyclicBean aBean)
{
this.bean = aBean;
}
public String toString()
{
return [CyclicColumn] name= + getName();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema CyclicLayer.java
rdonkin 2005/01/20 15:15:38
Added: betwixt/src/test/org/apache/commons/betwixt/schema
CyclicLayer.java
Log:
Fixed buggy behaviour when creating schema for beans with cyclic graphs. Unit
tests contributed by Susan Liu. Issue#33168
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/CyclicLayer.java
Index: CyclicLayer.java
===
/*
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.betwixt.schema;
import java.util.Vector;
/**
* p This is a bean specifically designed to test cyclic references.
* The idea is that there's a count that counts every time
codegetFriend/code
* gets called and throws a codeRuntimeException/code if the count gets
too high./p
*
* @author a href='http://jakarta.apache.org/commons'Jakarta Commons
Team/a, a href='http://www.apache.org'Apache Software Foundation/a
*/
public class CyclicLayer {
private Vector columns = new Vector(); //CyclicColumn
private String name;
public CyclicLayer(String name)
{
this.name = name;
}
public Vector getColumns()
{
return this.columns;
}
public void setColumns(Vector vColumns)
{
this.columns = vColumns;
}
public void addColumn(CyclicColumn aColumn)
{
columns.add(aColumn);
}
public String getName()
{
return name;
}
public String toString()
{
return [CyclicLayer] name= + name;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33168] - [Betwixt] release 0.6 can't generate XML schema for cyclic bean.
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=33168. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33168 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 00:16 --- Fix committed. Many thanks. The units tests were just what I needed, but unfortunately the fix was a little trickier than I'd initially thought. The fix isn't as elegant as I'd like and has set me thinking that it's a pity that if there's a demand, it's a pity that this code base isn't pushed on. Realistically, this code isn't really high enough on my priority list to receive the attention it deserves but it's pretty independent and not so constrained by backwards compatibility as the rest. So, if you have an itch for better Betwixt support for schema, I'd be glad to provide advice and to review any patches you submit if you feel like contributing code... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[digester][VOTE] Remove licence text from javadoc
Hi, In August 2004, the build.xml file was modified so that when generating Javadoc a copy of the apache licence was inserted as an xml comment into the footer of generated pages. Unforunately, this has caused complications, because javadoc appears to have cross-platform issues with the quote marks in the text; on MS-Windows, the quotes need to be escaped or a javadoc error is reported, but if they are escaped then the escape marks get copied verbatim to the output under Linux. In addition, this change makes the build.xml file a bit clumsy; the license is quite a lot of text to fit into an xml attribute! Yes, it would be possible to have separate footer text for windows vs linux, but that would make build.xml even uglier. The licence text seemed unnecessary to me, as: * Javadoc is not useful as a stand-alone product; * Javadoc is generated from source files which *do* have complete license text within them; and * the output documents an API, with APIs not being copyrightable I posted a question to [EMAIL PROTECTED] re this, and got this reply: = On Thu, 2005-01-20 at 07:58 -0800, Brian Behlendorf wrote: On Wed, 19 Jan 2005, Jeffrey Thompson wrote: Interesting question. First, a perspective point. The copyright notice in the file is primarily for Apache's benefit. It puts people on notice that Apache claims copyright on the material. Well, first, it really should be: Copyright [] The Apache Software Foundation or its licensors, as applicable. [snip] On the other hand, the license (though it does have some benefit to Apache) is primarily for the user's benefit. Without it, the user has no license at all. So, is the user put at a disadvantage in any way because the license isn't embedded in the JavaDoc? Wouldn't anyone who understands how JavaDoc works know exactly how to find out what license is available for that material? My sense is that this is splitting hairs a bit and that the full license, or even the reference to it, doesn't need to be included in the javadoc output - just as we don't embed it as a string in compiled code when we distribute binaries. = So in summary: I propose that the build.xml footer text be modified to contain: Copyright 2001-2004 The Apache Software Foundation or its licensors, as applicable. And that the licence text be removed. You can see the entire thread at: http://mail-archives.eu.apache.org/mod_mbox/www-legal-discuss/200501.mbox/index.html with subject: Licence required in Javadoc output? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester][VOTE] Remove licence text from javadoc
For now, I am -1 on this. Unless I'm mistaken, the reason the license is in there is because we were specifically asked by the board to include it. Until we are explicitly told by the board that this is no longer the case, I believe it needs to stay there. I don't count Brian's comments on legal-discuss as sufficient for a go-ahead to remove it, since he was not speaking with his board member hat on. (That is, he mailed from his CollabNet account, not his ASF account.) (Note that I would be happy to see the license requirement in the Javadocs go away; I just don't think we have sufficient say-so to do that quite yet.) -- Martin Cooper On Fri, 21 Jan 2005 13:50:17 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Hi, In August 2004, the build.xml file was modified so that when generating Javadoc a copy of the apache licence was inserted as an xml comment into the footer of generated pages. Unforunately, this has caused complications, because javadoc appears to have cross-platform issues with the quote marks in the text; on MS-Windows, the quotes need to be escaped or a javadoc error is reported, but if they are escaped then the escape marks get copied verbatim to the output under Linux. In addition, this change makes the build.xml file a bit clumsy; the license is quite a lot of text to fit into an xml attribute! Yes, it would be possible to have separate footer text for windows vs linux, but that would make build.xml even uglier. The licence text seemed unnecessary to me, as: * Javadoc is not useful as a stand-alone product; * Javadoc is generated from source files which *do* have complete license text within them; and * the output documents an API, with APIs not being copyrightable I posted a question to [EMAIL PROTECTED] re this, and got this reply: = On Thu, 2005-01-20 at 07:58 -0800, Brian Behlendorf wrote: On Wed, 19 Jan 2005, Jeffrey Thompson wrote: Interesting question. First, a perspective point. The copyright notice in the file is primarily for Apache's benefit. It puts people on notice that Apache claims copyright on the material. Well, first, it really should be: Copyright [] The Apache Software Foundation or its licensors, as applicable. [snip] On the other hand, the license (though it does have some benefit to Apache) is primarily for the user's benefit. Without it, the user has no license at all. So, is the user put at a disadvantage in any way because the license isn't embedded in the JavaDoc? Wouldn't anyone who understands how JavaDoc works know exactly how to find out what license is available for that material? My sense is that this is splitting hairs a bit and that the full license, or even the reference to it, doesn't need to be included in the javadoc output - just as we don't embed it as a string in compiled code when we distribute binaries. = So in summary: I propose that the build.xml footer text be modified to contain: Copyright 2001-2004 The Apache Software Foundation or its licensors, as applicable. And that the licence text be removed. You can see the entire thread at: http://mail-archives.eu.apache.org/mod_mbox/www-legal-discuss/200501.mbox/index.html with subject: Licence required in Javadoc output? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jelly] RC2?
Could you give me an example of something that leaks? If Maven reuses the JellyContext, it'll still leak. Maven would have to add in a line to clear the Tag cache. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 6:12 AM To: Jakarta Commons Developers List Subject: Re: [jelly] RC2? Looks good in Maven 1.1 HEAD. Still leaking memory in multiproject sites, but I haven't done any recent work to isolate the cause of that. JSL remains the suspect, but nothing solid to back that. +1 on an RC2 release after standing bugs are fixed. - Brett Dion Gillard wrote: Yep, I'm up for RC2 after some testing and then assuming no showstoppers, a 1.0 straight after. On Thu, 20 Jan 2005 00:32:32 -0500, Hans Gilde [EMAIL PROTECTED] wrote: I couldn't fix the problems with my weak ref implementation, so I tweaked Paul's fix a little to make it thread safe and better for inheritance. Anyway, the memory leak is gone and all unit tests pass after many iterations. Are we ready for an RC2 and, hopefully, a quick release of version 1? Hans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jelly] RC2?
I'm for fixing JELLY-177 and JELLY-196 (haven't really looked at 196, just the description). 191 is for a TagLib, so it would be released separately anyway. The code for JELLY-177 looks good when copied verbatim. I did a couple of Servlet tests but nothing that could be automated without Cactus. Will commit this tonight or tomorrow after a little more testing. Hans -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 3:45 AM To: Jakarta Commons Developers List Subject: Re: [jelly] RC2? We should maybe make a round of the bugs submitted, or ? Hans mentioned he wanted to give a stab at JELLY-177, looks good. Looks like JELLY-191 and JELLY-196 could be considered... Any opinion ? paul Le 20 janv. 05, à 06:43, Dion Gillard a écrit : Yep, I'm up for RC2 after some testing and then assuming no showstoppers, a 1.0 straight after. On Thu, 20 Jan 2005 00:32:32 -0500, Hans Gilde [EMAIL PROTECTED] wrote: I couldn't fix the problems with my weak ref implementation, so I tweaked Paul's fix a little to make it thread safe and better for inheritance. Anyway, the memory leak is gone and all unit tests pass after many iterations. Are we ready for an RC2 and, hopefully, a quick release of version 1? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57868 ] Hans Gilde commented on JELLY-85: - Absolutely, this would be much easier. But it gets complicated when you look at what creating a new context means. Like, contexts search up the ie parent tree for variables and other stuff. And tags can search up from a thread tag to fiind parent... TagScript doesn't clear its cached tags after run() --- Key: JELLY-85 URL: http://issues.apache.org/jira/browse/JELLY-85 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0-beta-4 Reporter: Scott Howlett Attachments: StaticTagScript_patch.txt, TagScript_patch.txt, includeAndDefineExample.zip TagScript caches the tags it generates in a ThreadLocal. At the beginning of run() it checks to see if the context wants to cache tags - if not, it clears the cache and regenerates it. But there is no corresponding check and cache clearing at the end of run(). So if a tag holds onto some significant resource, that resource will hang around until the thread goes away or until the tag is run again. I am using Jelly Swing extensively, and various tags end up attached to the AWT Event thread for the lifetime of my application. As a quick fix, I have a patch that simply repeats the check-and-clear-cache behavior at the end of TagScript.run(). I also have a patch that adds this behavior to StaticTagScript, whose run() never seems to clear cached tags. I am probably just unclear, but it seems to me that there is a deeper issue as well - the context is being asked whether it wants to cache tags, but the result of this question affects the TagScript, which is really independent of the context. It seems like if context wants to cache tags, perhaps the ThreadLocal used for their storage ought to belong to the context somehow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jelly] RC2?
You'd need to build Maven from CVS HEAD to use the latest version of Jelly (it is currently set to beta-4, but I've tried it with RC2-SNAPSHOT as well - was just waiting for the release to update). maven multiproject:site for jelly-tags should do it. IIRC, the project is disposed of, so the jellycontext's should also be (I mean garbage collected here - nothing explicit is done). However, I haven't looked at that in a year. If there's a way to tell a context to clean up as it is going out of scope, that could definitely be added. - Brett Quoting Hans Gilde [EMAIL PROTECTED]: Could you give me an example of something that leaks? If Maven reuses the JellyContext, it'll still leak. Maven would have to add in a line to clear the Tag cache. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 6:12 AM To: Jakarta Commons Developers List Subject: Re: [jelly] RC2? Looks good in Maven 1.1 HEAD. Still leaking memory in multiproject sites, but I haven't done any recent work to isolate the cause of that. JSL remains the suspect, but nothing solid to back that. +1 on an RC2 release after standing bugs are fixed. - Brett Dion Gillard wrote: Yep, I'm up for RC2 after some testing and then assuming no showstoppers, a 1.0 straight after. On Thu, 20 Jan 2005 00:32:32 -0500, Hans Gilde [EMAIL PROTECTED] wrote: I couldn't fix the problems with my weak ref implementation, so I tweaked Paul's fix a little to make it thread safe and better for inheritance. Anyway, the memory leak is gone and all unit tests pass after many iterations. Are we ready for an RC2 and, hopefully, a quick release of version 1? Hans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33190] New: - Facility for passing an Iterator object into the 'View' part of an MVC framework
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=33190. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33190 Summary: Facility for passing an Iterator object into the 'View' part of an MVC framework Product: Commons Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Collections AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Note that this enhancement is not Struts/OJB/etc specific: I'm just using this as an example that I believe will be easy for people to relate to. Generally stated, I'm proposing a special Iterator implementation that will automatically close resources at the end of the iteration. If you're using an MVC framework like Struts or Spring, there's a frequent need to pass Iterator objects into the request scope so that a JSP in the View can loop over the Iterator and, for example, print out some values. If you are reading a large number of records from a DB, you could create a copy of the Collection in your Action class and pass an Iterator through by dropping it into the request. A better approach that requires less memory is one which would allow you to pass an Iterator object that performs lazy initialization, since this is more efficient in terms of memory use. However, because the View and the Controller are seperate layers, you would need to close your database connection before forwarding the request to the JSP. Since, in Struts, your Action class's execute() method has already terminated at this time, you're left with ugly hacks like using scriptlet code to call close() on certain objects. The approach that I'm proposing here is one which I picked up off of the OJB user list a while ago. I've implemented a special Iterator() that calls close() on an resource object when there are no more elements in the iteration. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33190] - Facility for passing an Iterator object into the 'View' part of an MVC framework
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=33190. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33190 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 06:32 --- Created an attachment (id=14060) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14060action=view) ResourceClosingIterator Interface that is used by the ResourceClosingIterator. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33190] - Facility for passing an Iterator object into the 'View' part of an MVC framework
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=33190. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33190 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #14060|ResourceClosingIterator |ResourceClosingIteratorSuppo description||rt -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33190] - Facility for passing an Iterator object into the 'View' part of an MVC framework
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=33190. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33190 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 06:34 --- Created an attachment (id=14061) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14061action=view) ResourceClosingIterator -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
