from:"paul"


[ 
https://issues.apache.org/jira/browse/LANG-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512723
 ] 

Paul Benedict commented on LANG-343:


Henri, I read the other issue. There's at least an enhancement here for 2.3 :-) 
The JavaDoc does not clearly state the message will append must not be null. 
I didn't know this and I've been putting full sentences into the exception 
message. Could you change the title of this ticket, and update the javadoc to 
make it known? Just show an example that passing in str will result in a 
message like str must not be null

 Validate: Throw NullArgumentException
 -

 Key: LANG-343
 URL: https://issues.apache.org/jira/browse/LANG-343
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Paul Benedict

 Validate methods should throw NullArgumentException on detecting null, not 
 just IllegalArgumentException (its superclass)

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [BeanUtils] Progressing towards a 1.8.0 release

2007-07-14 Thread Paul Benedict

I've always found it interesting there is a commons-beanutils and 
common-beanutils-core deliverable. The name doesn't suggest what makes 
the first one different. Usually the core artifact is foundational 
(like tapestry-core or struts-core). If it is an API package, I would 
add api to the end .. or fold the two together.


Stephen Colebourne wrote:

Henri Yandell wrote:

One area for discussion is the split between the optional Collections
component and the 'Core' beanutils. Do we maintain that, or should we
just fold the code back together?

1.7.0 shipped three versions:

commons-beanutils-1.7.0.jar
commons-beanutils-core-1.7.0.jar
commons-beanutils-collections-1.7.0.jar

where the first is the sum of the second and third.

Personally I think we should just merge them back together. It's not
worth the effort.


The purpose is to avoid forcing users to take dependencies that they 
are not interested in, [collections] in this case. As such I think 
that the split is a Good Thing.


Stephen

-
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: [BeanUtils] Progressing towards a 1.8.0 release

2007-07-14 Thread Paul Benedict


If I understood Henri correctly, his proposal is to distribute one artifact
with optional collection dependencies. True? If so, I am for it. I don't see
any technical advantage in creating collection-free or collection-only jars.

On 7/14/07, Niall Pemberton [EMAIL PROTECTED] wrote:


On 7/14/07, Dennis Lundberg [EMAIL PROTECTED] wrote:
 Niall Pemberton wrote:
  BeanUtils is getting close to being ready for a 1.8.0 release IMO
  (under 10 issues left targeted for 1.8.0).
 
   http://issues.apache.org/jira/browse/BEANUTILS
 
  One thought I had was to do a 1.8.0 Beta release first to (hopefully)
  get wider testing - thoughts/opinions on that welcome.

 Niall, I saw a couple of commits suggesting a Maven 2 site. Are you
 aiming for that? If so I could go through it, if you want me to.

Hi Dennis,

Yes, I'm aiming to use m2 for the release ATM - just need to decide on
Henri's project structure suggestion to finish up on it. Any help /
suggestions would be much appreciated - thanks.

Niall

 --
 Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-52) [lang] Validate.notNull should throw NullArgumentException


[ 
https://issues.apache.org/jira/browse/LANG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512757
 ] 

Paul Benedict commented on LANG-52:
---

This can be fixed in the 2.x line. Add a second constructor to 
NullArgumentException which accepts both the name of the offending field and 
the message. Because the name isn't provided by Validate, just pass in null for 
it, but if it exists you can append both messages together. 

 [lang] Validate.notNull should throw NullArgumentException
 --

 Key: LANG-52
 URL: https://issues.apache.org/jira/browse/LANG-52
 Project: Commons Lang
  Issue Type: Bug
 Environment: Operating System: All
 Platform: All
Reporter: Jörg Gottschling
Priority: Trivial
 Fix For: 3.0

 Attachments: LANG-52.patch


 Validate.notNull throws a IllegalArgumentException but should throw a
 NullArgumentException

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [BeanUtils] Progressing towards a 1.8.0 release

2007-07-14 Thread Paul Benedict


On 7/14/07, Niall Pemberton [EMAIL PROTECTED] wrote:


I was around (just) when 1.7.0 was released but I have no recollection
of the decisions made on packaging. I believe the bean-collections
related bean stuff came originally from commons collections - so I
presume this allows people to continue to use these classes wihout
taking on the whole of beanutils - and for the bean-collections free
version - assures people there are no other dependencies. Anyway the
main reason to continue to provide them is so anyone who has chosen to
use them can continue to do so.

Niall



If I may guess, 1.7 was built before Maven 2 was released. M1 did not have a
concept of optional dependencies, so the only way to prevent unwanted
dependencies was splitting libraries. IMO, the build technology has improved
and there's no longer a necessity to provide them. For those already using
them, well, unless you are going to upload them to the M1 repository too, I
don't think the split benefits existent users anymore. My 2 cents.

Paul

[jira] Commented: (BEANUTILS-91) PropertyUtils.copyProperties throws exceptions contrary to documentation

[
https://issues.apache.org/jira/browse/BEANUTILS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512770
]

Paul Benedict commented on BEANUTILS-91:

Exceptions are not part of the method signature. Because both the
aforementioned exceptions are checked exceptions, removing them may cause a
compiler error for newly compiled code. The java compiler may find code
catching exceptions that are never thrown and may error, but for already
compiled code, no problems.

PropertyUtils.copyProperties throws exceptions contrary to documentation

Key: BEANUTILS-91
URL: https://issues.apache.org/jira/browse/BEANUTILS-91
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.5
Environment: Operating System: other
Platform: Other
Reporter: Arun Mammen Thomas
Priority: Minor
Fix For: 1.8.0

Attachments: PropertyUtilsTest.java, temp.java

1) The copyProperties method is documented as throwing IllegalAccessException
when access to a particular method is not available. In fact, because
internally the methods to be invoked are filtered for accessiblity
(MethodUtils.getAccessibleMethod) before invocation, the possible sources of
the IllegalAccessException will never actually throw an
IllegalAccessException.
Worse, however, is that the result of a failure to return an accessible
method
is actually taken as occasion to throw a NoSuchMethodException instead.
2) The copyProperties method is also documented as throwing
NoSuchMethodException when a method cannot be found. I'm not sure if this is
an error or not, but a NoSuchMethodException is not thrown when a property of
the same name but a different type is found. (This would, to my mind, be an
occasion of not finding an appropriate method for the setter to function
properly).
Unfortunately, again, there is something worse. In this case, instead of
throwing NoSuchMethodException, an IllegalArgumentException is thrown.
IllegalArgumentException, as a runtime exception, might have been
appropriateexcept for the fact that it is explicitly documented as being
thrown when either the source or the destination arguments are null - no
other
reasons for throwing this are detailed. (Wouldn't NullPointerException be
more appropriate anyway? Curious about the decision to recast this to
IllegalArgumentException) While this is certainly allowed for
RuntimeExceptions, in this case, the documentation is quite misleading about
what is actually to be expected.
I'll attach a JUnitTestCase that captures both of these items.

--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Issue Comment Edited: (BEANUTILS-91) PropertyUtils.copyProperties throws exceptions contrary to documentation

[
https://issues.apache.org/jira/browse/BEANUTILS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512770
]

Paul Benedict edited comment on BEANUTILS-91 at 7/14/07 7:31 PM:
-

Exceptions are not part of the binary method signature. Because both the
aforementioned exceptions are checked exceptions, removing them may cause a
compiler error for newly recompiled code. The java compiler may find code
catching exceptions that are never thrown and may error, but for already
compiled code, no problems.

was:
Exceptions are not part of the method signature. Because both the
aforementioned exceptions are checked exceptions, removing them may cause a
compiler error for newly compiled code. The java compiler may find code
catching exceptions that are never thrown and may error, but for already
compiled code, no problems.

PropertyUtils.copyProperties throws exceptions contrary to documentation

Attachments: PropertyUtilsTest.java, temp.java

--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation

2007-07-13 Thread Paul Benedict (JIRA)


[ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512415
 ] 

Paul Benedict commented on VALIDATOR-232:
-

Niall, I change my position and am fine with Martin's suggestion of 
clientValidation. I think it's verbose, but it is a better choice than than 
scripting because scripting implies a certain technology. While scripting 
may be almost always true for the client, I suppose someone could write a 
validator that uses Flash or something. 

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r555489 - in /jakarta/commons/proper/beanutils/trunk/src: java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java test/org/apache/commons/beanutils/locale/convert

2007-07-12 Thread Paul Benedict


This is trivial, but supplied is spelled wrong. Needs two P's.

On 7/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


Author: niallp
Date: Wed Jul 11 21:53:26 2007
New Revision: 555489

URL: http://svn.apache.org/viewvc?view=revrev=555489
Log:
BEANUTILS-44 FloatLocaleConverter cannot parse negative values - reported
by Paul Jenkins

Modified:


jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java


jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java

Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java?view=diffrev=555489r1=555488r2=555489

==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
Wed Jul 11 21:53:26 2007
@@ -214,8 +214,10 @@
 */
protected Object parse(Object value, String pattern) throws
ParseException {
   final Number parsed = (Number) super.parse(value, pattern);
-  if( Math.abs(parsed.doubleValue() - parsed.floatValue()) 
parsed.floatValue() * 0.1 ) {
- throw new ConversionException(Suplied number is not of type
Float: +parsed.longValue());
+  double doubleValue = parsed.doubleValue();
+  double posDouble = (doubleValue = (double)0) ? doubleValue :
(doubleValue * (double)-1);
+  if (posDouble  Float.MIN_VALUE || posDouble  Float.MAX_VALUE) {
+  throw new ConversionException(Suplied number is not of type
Float: +parsed);
   }
   return new Float(parsed.floatValue()); // unlike superclass it
returns Float type
}

Modified:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java?view=diffrev=555489r1=555488r2=555489

==
---
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
Wed Jul 11 21:53:26 2007
@@ -17,6 +17,8 @@

package org.apache.commons.beanutils.locale.converters;

+import java.text.DecimalFormat;
+import org.apache.commons.beanutils.ConversionException;

/**
  * Test Case for the FloatLocaleConverter class.
@@ -256,6 +258,49 @@
 convertInvalid(converter, defaultValue);
 convertNull(converter, defaultValue);

+}
+
+/**
+ * Test Float limits
+ */
+public void testFloatLimits() {
+
+converter = new FloatLocaleConverter(defaultLocale,
defaultDecimalPattern);
+DecimalFormat fmt = new
DecimalFormat(#.#);
+
+assertEquals(new Float(-0.12), converter.convert(-0.12));
+assertEquals(Positive Float.MAX_VALUE, new Float(
Float.MAX_VALUE), converter.convert(fmt.format(Float.MAX_VALUE)));
+assertEquals(Positive Float.MIN_VALUE, new Float(
Float.MIN_VALUE), converter.convert(fmt.format(Float.MIN_VALUE)));
+
+assertEquals(Negative Float.MAX_VALUE, new Float(
Float.MAX_VALUE * -1), converter.convert(fmt.format(Float.MAX_VALUE *
-1)));
+assertEquals(Negative Float.MIN_VALUE, new Float(
Float.MIN_VALUE * -1), converter.convert(fmt.format(Float.MIN_VALUE *
-1)));
+
+
+try {
+converter.convert(fmt.format((double)Float.MAX_VALUE *
(double)10));
+fail(Positive Too Large should throw ConversionException);
+} catch (ConversionException e) {
+// expected result
+}
+try {
+converter.convert(fmt.format((double)Float.MAX_VALUE *
(double)-10));
+fail(Negative Too Large should throw ConversionException);
+} catch (ConversionException e) {
+// expected result
+}
+
+try {
+converter.convert(fmt.format((double)Float.MIN_VALUE /
(double)10));
+fail(Positive Too Small should throw ConversionException);
+} catch (ConversionException e) {
+// expected result
+}
+try {
+converter.convert(fmt.format((double)Float.MIN_VALUE /
(double)-10));
+fail(Negative Too Small should throw ConversionException);
+} catch

Re: [BeanUtils] Progressing towards a 1.8.0 release

2007-07-12 Thread Paul Benedict


Great job Niall. Kudos.

On 7/12/07, Rahul Akolkar [EMAIL PROTECTED] wrote:


On 7/12/07, Niall Pemberton [EMAIL PROTECTED] wrote:
 BeanUtils is getting close to being ready for a 1.8.0 release IMO
 (under 10 issues left targeted for 1.8.0).

   http://issues.apache.org/jira/browse/BEANUTILS

snip/

Thanks for all the work!


 One thought I had was to do a 1.8.0 Beta release first to (hopefully)
 get wider testing - thoughts/opinions on that welcome.

snap/

IMO, a 1.8.0 Beta sounds like a good idea since there are a few
changes and much downstream testing can be done -- it will give folks
some more time to react. For example, I intend to run the gamut of
tests (Digester - SCXML - things SCXML depends on) and having a Beta
release would let me do that in a more relaxed fashion.

-Rahul


 Niall


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (VALIDATOR-233) Update location of dojo compressor library


[ 
https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511422
 ] 

Paul Benedict commented on VALIDATOR-233:
-

Niall, I have successfully changed the URL on my build and built the entire 
library. I wasn't expecting it to fail for you. I can also load the URL in a 
browser.

 Update location of dojo compressor library
 --

 Key: VALIDATOR-233
 URL: https://issues.apache.org/jira/browse/VALIDATOR-233
 Project: Commons Validator
  Issue Type: Task
  Components: JavaScript
Affects Versions: 1.4
Reporter: Paul Benedict
 Fix For: 1.4


 build-javascript.xml no longer has a valid URL to the compressor library. It 
 is now located at:
 http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation

[
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511424
]

Paul Benedict commented on VALIDATOR-232:
-

Niall, I agree with the example you provided. I think it is a valuable
enhancement to allow people to determine which fields can fail-fast at the
client, but others for back-end processing. Because I don't have this ability,
neither do I use javascript at all on my Struts apps.

I prefer the scriptable attribute over custom validator because it is not
use-case specific. A company may have different requirements, for example, for
an intranet than an internet. Or if there is a bug in a javascript validator,
instead of waiting for the next release, a company could switch it off just for
the problematic fields.

So I see a lot of value in this feature.

Add script attribute to control script generation
-

Key: VALIDATOR-232
URL: https://issues.apache.org/jira/browse/VALIDATOR-232
Project: Commons Validator
Issue Type: New Feature
Components: Framework
Reporter: Paul Benedict
Priority: Minor
Fix For: 1.4

Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch

Add a script=true|false attribute to field to control whether JavaScript
should be generated.
Also see: https://issues.apache.org/struts/browse/STR-1888

--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation

[
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511613
]

Paul Benedict commented on VALIDATOR-232:
-

I don't use any javascript validation on my apps because, specifically, I do
not want to expose any mask elements. In a perfect world, I could switch off
validation scripting for these fields -- not just password fields -- on an
as-needed basis. But because I don't have this freedom, I only do server side
validation. And if I had this option, I may find in the future how useful this
is for other things...

You raise a good point about switching off validations per type or substituting
corrected scripts. However, you'd be surprise how many good java developers do
not know javascript :-) In some instances, a person may simply just choose to
turn it off rather than replace it.

I've been viewing this issue to something like CSS stylesheets. With the CSS
media attribute, and I get to say which media the styling belongs (screen,
printer, audio, etc.). Likewise, I believe it is good to give developers the
freedom to direct what media the validation belongs. For Commons Validator,
there's two media components: scripting and Java. If I don't care for how a
script works, I'd be more willing to disable it and rely on the server-side
version than replace it.

While I haven't done this yet, I'd be very interested in replacing some
client-side validation with perhaps DOJO/Ajax validation. I may want to (1)
have only one form field that uses Web 2.0 features, (2) keep the standard JS
validation on other fields but (3) still rely on the server-side validation for
all fields as standard practice. It opens up some interesting possibilities
here.

Add script attribute to control script generation
-

Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch

Add a script=true|false attribute to field to control whether JavaScript
should be generated.
Also see: https://issues.apache.org/struts/browse/STR-1888

--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation


[ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511634
 ] 

Paul Benedict commented on VALIDATOR-232:
-

I would prefer scriptable -- positive language. This makes more sense than 
script or scripting. There's actually a lot of good usage of this word if 
you Google it.

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New M2 snapshots use org.apache.commons?

2007-07-10 Thread Paul Benedict

Because it has already been discussed, I might as well throw in my two 
cents.


Whatever direction commons decides to take, it's worth acknowledging 
that more than a few popular Apache projects moved to 
org.apache.whatever.* without relocating their previous releases. They 
broke with the Maven 1 conventions and released new versions under the 
naming conventions for Maven 2. Because developers must modify their POM 
to update the version number anyway, editing the groupId is a trivial 
additive.


Paul

Henri Yandell wrote:

On 7/9/07, Wendy Smoak [EMAIL PROTECTED] wrote:

On 7/9/07, Paul Benedict [EMAIL PROTECTED] wrote:

 For development of new releases, should the commons-* folders be 
forgone

 and use org.apache.commons now?

Check the list archives for some past discussion... it has to be
handled carefully with old releases relocated in the central
repository, or downstream users will be adversely affected.

Nabble turns up a few relevant posts:
http://www.nabble.com/forum/Search.jtp?forum=317local=yquery=commons+maven+groupid 



Yeah, my view is that Maven need a better system :) I keep meaning to
dig into the code of how to do such a thing.

Hen

-
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: (VALIDATOR-232) Add script attribute to control script generation


[ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511639
 ] 

Paul Benedict commented on VALIDATOR-232:
-

How doesn't scriptable describe the purpose? script+able = able to be 
scripted. In the context of the Validator, I believe this makes sense since 
that's one of its functions. This is just like mutable = able to be 
muted/changed. IMO, 'clientValidation' doesn't describe the kind of client 
validation, which is in this case, scripting. 

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New M2 snapshots use org.apache.commons?

2007-07-10 Thread Paul Benedict

Good points. I've been through that very same problem many times. I 
guess I am just used to excluding the old names. Yeah, it's a bit of a 
troublemaker, but I'd rather have a correct name. In any case, perhaps 
this name-game will gain traction once Maven adds capabilities to 
provide aliases.


Henri Yandell wrote:

The core issue is one of transitive dependencies clashes.

For example, I had a problem the other day with the antrun plugin
which depends on ant.ant-1.6.5, and we had a dependency of ant-trax
(1.7.0), which depends on org.apache.ant.ant-1.7.0. Those aren't the
same project, so Maven couldn't yell at us for having a clashing
dependency. Not that I know if the plugin system would have warned me
of the clash, it was a fun bug :)

With something as low as Commons, this transitive dependency clash is
really, really valuable.

Hen

On 7/10/07, Paul Benedict [EMAIL PROTECTED] wrote:

Because it has already been discussed, I might as well throw in my two
cents.

Whatever direction commons decides to take, it's worth acknowledging
that more than a few popular Apache projects moved to
org.apache.whatever.* without relocating their previous releases. They
broke with the Maven 1 conventions and released new versions under the
naming conventions for Maven 2. Because developers must modify their POM
to update the version number anyway, editing the groupId is a trivial
additive.

Paul

Henri Yandell wrote:
 On 7/9/07, Wendy Smoak [EMAIL PROTECTED] wrote:
 On 7/9/07, Paul Benedict [EMAIL PROTECTED] wrote:

  For development of new releases, should the commons-* folders be
 forgone
  and use org.apache.commons now?

 Check the list archives for some past discussion... it has to be
 handled carefully with old releases relocated in the central
 repository, or downstream users will be adversely affected.

 Nabble turns up a few relevant posts:
 
http://www.nabble.com/forum/Search.jtp?forum=317local=yquery=commons+maven+groupid 




 Yeah, my view is that Maven need a better system :) I keep meaning to
 dig into the code of how to do such a thing.

 Hen

 -
 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]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation


[ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511647
 ] 

Paul Benedict commented on VALIDATOR-232:
-

You make a good point in regards to the field's ability to be scriptable 
regardless of the Validator. However, since it is obvious that the Validator 
does not control the browser's scripting capabilities, there is nothing wrong 
with using the word's plain meaning: is this field, as defined by the 
validator, configured to allow scripting? But granted, how long can such a 
debate go on? It's a matter of perspective, I suppose. In any event, I suppose 
we'll stick with our opinions until a better word comes along.

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation


[ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511648
 ] 

Paul Benedict commented on VALIDATOR-232:
-

... and I wouldn't mind simply client over clientValidation

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Issue Comment Edited: (VALIDATOR-232) Add script attribute to control script generation


[ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511648
 ] 

Paul Benedict edited comment on VALIDATOR-232 at 7/10/07 9:37 PM:
--

... and I wouldn't mind simply client over clientValidation. But also, I 
would be +1 for clientValidatable so that methods 
(isClientValidatable/setClientValidatable) describe a functional feature, not a 
noun.


 was:
... and I wouldn't mind simply client over clientValidation

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

New M2 snapshots use org.apache.commons?

2007-07-09 Thread Paul Benedict

For development of new releases, should the commons-* folders be forgone 
and use org.apache.commons now?


Thanks,
Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (VALIDATOR-233) Update location of dojo compressor library

Update location of dojo compressor library
--

 Key: VALIDATOR-233
 URL: https://issues.apache.org/jira/browse/VALIDATOR-233
 Project: Commons Validator
  Issue Type: Task
  Components: JavaScript
Affects Versions: 1.4
Reporter: Paul Benedict
 Fix For: 1.4


build-javascript.xml no longer has a valid URL to the compressor library. It is 
now located at:
http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (VALIDATOR-234) Create 1.4 DTD

Create 1.4 DTD
--

 Key: VALIDATOR-234
 URL: https://issues.apache.org/jira/browse/VALIDATOR-234
 Project: Commons Validator
  Issue Type: Task
  Components: Framework
Affects Versions: 1.4
Reporter: Paul Benedict
 Fix For: 1.4


Create 1.4 DTD

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (VALIDATOR-232) Add script attribute to control script generation


 [ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated VALIDATOR-232:


Attachment: VALIDATOR-232.patch

Added new scripting property to Field. 

I chose the term scripting over script because that's the typical language. 
Also, I wanted to reserve script in case one day we allow alternative 
pluggable scripts on a field basis.

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (VALIDATOR-232) Add script attribute to control script generation


 [ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated VALIDATOR-232:


Attachment: VALIDATOR-232.dtd.patch

Attaching patch for the 1.4 DTD. Once the DTD is cloned and checked in, this 
adds the scripting attribute to field

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [proposal] No VOTE needed to elect ASF committers to commons WAS: Re: request karma to commons validator/i18n

2007-07-08 Thread Paul Benedict

What about an optimistic approach? That is, committers _who ask_ with 
a _rationale_ are evaluated thinly and get approval. If they do 
something off the wall, they can be booted out.


Paul

Torsten Curdt wrote:


On 08.07.2007, at 20:54, Rahul Akolkar wrote:


On 7/8/07, Henri Yandell [EMAIL PROTECTED] wrote:

On 7/6/07, Phil Steitz [EMAIL PROTECTED] wrote:

 So my proposal is that any ASF committer who wishes to become a
 commons committer just needs to make that request here on the
 commons-dev mailing list and they will granted karma for both commons
 proper and commons sandbox.  Expectation is of course that ASF
 committers joining the commons will behave
 (http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette).

Obviously I'm +1 on making it easier.


Hm, I know we need active people but...

We have a lot of little code bases. Our individual component code 
bases don't have many committers. I think we only share a general 
oversight across different projects. (I think that's also what bites 
us when we call for release votes) So in that term I do think Commons 
has a different touch than the usual Apache project. We always have a 
higher risk of fix-and-leave type contributors I guess.


I am not sure having anyone get commit access as a rule will help us 
raise the number of people for the individual components. I think 
though that for existing Apache committers the bar should be fairly 
low - if it is not already. Still I personally would prefer to see a 
vote on it. If I have to supply a patch to an Apache project that I am 
not yet involved in - that's OK. I don't expect to get commit access 
straight away just because I have an @apache.org address. But being 
able to come back an say Guys, I provided a patch and you haven't 
applied it within weeks. Want me to do it? seems fair. Either it's a 
wake-up call Sorry, I'll do it or Well, yeah ...do it! Hope you 
stick around and we vote on that guy ..IMHO


Something I would rather would like to see addressed is the question 
of non-apache contributors becoming committers. We have small 
codebases compared to many other Apache projects. So essentially that 
means getting involved is much easier. Does that also mean going 
through us is the easy way to get an @apache.org address? Or are we 
aware of all these facts and getting committership is even harder at 
Commons? (Wondering: How many committer nominations from a non-apache 
background did we have in the past 2 years?) What about contributions 
to sandbox projects? Does it matter (in terms of committership) 
whether you contribute to something that maybe never even gets released?


Our release process has a tendency to frustrate and drive people away 
too. Maybe also something we could improve to have contributors be 
more likely to stick.


...just some RTs.

cheers
--
Torsten



-
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: (FILEUPLOAD-140) Means to preserve text parameters when upload limit exceeded

2007-07-08 Thread Paul Benedict (JIRA)


[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511018
 ] 

Paul Benedict commented on FILEUPLOAD-140:
--

Jochen, please re-evaluate this issue. The first link I sent you was my overall 
objective, but it relates to another issue here: 
https://issues.apache.org/struts/browse/STR-2700

On Windows and Sun machines, if there is a about 20KB of text in a JSP after an 
exceeded upload, the connection will hang indefinitely. This was tested on 
multiple JDKs (4, 5, 6), application servers (Tomcat, Weblogic), and OS. We 
tested with a Mac too but the issue did not exist.

My proposed solution is no more of an invitation for DOS attacks anymore then 
transmitting a large text field. Data is data and frameworks don't see files 
any different than other form field elements.

We patched Struts, but really the patch belongs in FILEUPLOAD as an option. We 
could allow the developer the option to either choose a hanging socket or a 
large upload. :-) I am definitely for the latter because it allows the request 
to complete normally, even if it the response takes longer.

I rate this issue as a critical or blocker because, given the stated 
conditions, the response is unable to be completed unless the workaround is in 
place.

 Means to preserve text parameters when upload limit exceeded
 

 Key: FILEUPLOAD-140
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-140
 Project: Commons FileUpload
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Paul Benedict
Assignee: Jochen Wiedmann

 I am trying to resolve https://issues.apache.org/struts/browse/STR-2585 but 
 am lacking the means to do it. The current use is with the deprecated 
 DiskFileUpload and I prefer to have this class fixed first. When 
 SizeLimitExceededException is thrown, it does not return the items it has 
 collected thus far. I see two possible solutions which involve adding a 
 property on the exception to return them:
 (1) Return the parameters thus gathered or 
 (2) finish out the input stream but throw away all file items and return only 
 the text parameters.
 Otherwise, whenever a the upload exceeds its limit, all other input 
 parameters disappear.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Issue Comment Edited: (FILEUPLOAD-140) Means to preserve text parameters when upload limit exceeded

2007-07-08 Thread Paul Benedict (JIRA)


[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511018
 ] 

Paul Benedict edited comment on FILEUPLOAD-140 at 7/8/07 5:44 PM:
--

Jochen, please re-evaluate this issue. The first link I sent you was my overall 
objective, but it relates to another issue here: 
https://issues.apache.org/struts/browse/STR-2700

On Windows and Sun machines, if there is about 20KB of text in a JSP after an 
exceeded upload, the connection will hang indefinitely. This was tested on 
multiple JDKs (4, 5, 6), application servers (Tomcat, Weblogic), and OS. We 
tested with a Mac too but the issue did not exist.

My proposed solution is no more of an invitation for DOS attacks anymore then 
transmitting a large text field. Data is data and frameworks don't see files 
any different than other form field elements.

We patched Struts, but really the patch belongs in FILEUPLOAD as an option. We 
could allow the developer the option to either choose a hanging socket or a 
large upload. :-) I am definitely for the latter because it allows the request 
to complete normally, even if it the response takes longer.

I rate this issue as a critical or blocker because, given the stated 
conditions, the response is unable to be completed unless the workaround is in 
place.

The hanging is caused by the input stream being full. The response is blocked 
until the stream is finished. The issue should really be renamed allow input 
stream to exhaust or something similar -- throwing away any other data before 
returning.


 was:
Jochen, please re-evaluate this issue. The first link I sent you was my overall 
objective, but it relates to another issue here: 
https://issues.apache.org/struts/browse/STR-2700

On Windows and Sun machines, if there is a about 20KB of text in a JSP after an 
exceeded upload, the connection will hang indefinitely. This was tested on 
multiple JDKs (4, 5, 6), application servers (Tomcat, Weblogic), and OS. We 
tested with a Mac too but the issue did not exist.

My proposed solution is no more of an invitation for DOS attacks anymore then 
transmitting a large text field. Data is data and frameworks don't see files 
any different than other form field elements.

We patched Struts, but really the patch belongs in FILEUPLOAD as an option. We 
could allow the developer the option to either choose a hanging socket or a 
large upload. :-) I am definitely for the latter because it allows the request 
to complete normally, even if it the response takes longer.

I rate this issue as a critical or blocker because, given the stated 
conditions, the response is unable to be completed unless the workaround is in 
place.

 Means to preserve text parameters when upload limit exceeded
 

 Key: FILEUPLOAD-140
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-140
 Project: Commons FileUpload
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Paul Benedict
Assignee: Jochen Wiedmann

 I am trying to resolve https://issues.apache.org/struts/browse/STR-2585 but 
 am lacking the means to do it. The current use is with the deprecated 
 DiskFileUpload and I prefer to have this class fixed first. When 
 SizeLimitExceededException is thrown, it does not return the items it has 
 collected thus far. I see two possible solutions which involve adding a 
 property on the exception to return them:
 (1) Return the parameters thus gathered or 
 (2) finish out the input stream but throw away all file items and return only 
 the text parameters.
 Otherwise, whenever a the upload exceeds its limit, all other input 
 parameters disappear.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (VALIDATOR-232) Add script attribute to control script generation

2007-07-07 Thread Paul Benedict (JIRA)

Add script attribute to control script generation
-

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4


Add a script=true|false attribute to field to control whether JavaScript 
should be generated.

Also see: https://issues.apache.org/struts/browse/STR-1888







-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: issue---regardsbug 113(fixed)

2007-07-06 Thread Paul Libbrecht


Vikas,

please repost with the [vfs] prefix in the subject so that people can  
receive your mail easily.


thanks

paul


Le 4 juil. 07 à 13:14, Vikas Kumar a écrit :


Hi

I am getting this problem as per issue 113(fixed bug).

Please help me to solve this problem.

Thanks  regards

Vikas Kumar



Print Exception**

org.apache.commons.vfs.FileSystemException: Could not read file  
sftp://maan:[EMAIL PROTECTED]/transport/source/students1.txt.


at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream 
(AbstractFileObject.java:1163)


at org.apache.commons.vfs.provider.DefaultFileContent.getInputStream 
(DefaultFileContent.java:360)


at com.adeptia.indigo.services.transport.ftp.SecuredFtp.download 
(SecuredFtp.java:161)


at  
com.adeptia.indigo.services.transport.ftp.FtpSource.createInputStream( 
FtpSource.java:179)


at  
com.adeptia.indigo.services.transport.support.AbstractStreamSource.ini 
tialize(AbstractStreamSource.java:44)


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 org.apache.commons.modeler.BaseModelMBean.invoke 
(BaseModelMBean.java:483)


at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source)

at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source)

at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke 
(Unknown Source)


at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source)

at com.adeptia.indigo.utils.RemoteMBeanProxy 
$LocalHandler.invokeOperation(RemoteMBeanProxy.java:441)


at com.adeptia.indigo.utils.RemoteMBeanProxy$Handler.invoke 
(RemoteMBeanProxy.java:294)


at $Proxy2.initialize(Unknown Source)

at com.adeptia.indigo.jelly.ActivityTag.runSync(ActivityTag.java:313)

at com.adeptia.indigo.jelly.ActivityTag.doTag(ActivityTag.java:250)

at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:278)

at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:133)

at com.werken.blissed.jelly.JellyActivity.perform 
(JellyActivity.java:120)


at com.werken.blissed.ProcessEngine.enterState(ProcessEngine.java:391)

at com.werken.blissed.ProcessEngine.followTransition 
(ProcessEngine.java:509)


at com.werken.blissed.ProcessEngine.checkTransitions 
(ProcessEngine.java:458)


at com.werken.blissed.ProcessEngine.startProcess(ProcessEngine.java: 
366)


at com.werken.blissed.ProcessEngine.spawn(ProcessEngine.java:299)

at com.adeptia.indigo.processflow.BlissedProcessFlow.execute 
(BlissedProcessFlow.java:159)


at com.adeptia.indigo.transaction.IndigoTransaction.execute 
(IndigoTransaction.java:423)


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 org.apache.commons.modeler.BaseModelMBean.invoke 
(BaseModelMBean.java:483)


at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source)

at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source)

at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke 
(Unknown Source)


at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source)

at javax.management.remote.rmi.RMIConnectionImpl.doOperation 
(Unknown Source)


at javax.management.remote.rmi.RMIConnectionImpl.access$100(Unknown  
Source)


at javax.management.remote.rmi.RMIConnectionImpl 
$PrivilegedOperation.run(Unknown Source)


at  
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation 
(Unknown Source)


at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown  
Source)


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 sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)

at sun.rmi.transport.Transport$1.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at sun.rmi.transport.Transport.serviceCall(Unknown Source)

at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)

at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown  
Source)


at java.lang.Thread.run(Unknown Source)

Caused by: org.apache.commons.vfs.FileSystemException: Could not  
connect to SFTP server at sftp://maan:[EMAIL PROTECTED]/.


at org.apache.commons.vfs.provider.sftp.SftpFileSystem.getChannel 
(SftpFileSystem.java:144)


at  
org.apache.commons.vfs.provider.sftp.SftpFileObject.doGetInputStream 
(SftpFileObject.java:380)


at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream 
(AbstractFileObject.java:1159)


... 53 more

Caused by: com.jcraft.jsch.JSchException: java.io.IOException:  
inputstream is closed

Re: request karma to commons validator/i18n

2007-07-06 Thread Paul Benedict


Niall, that's fine by me. You're the lead of the project and I respect your
contributions and leadership. I'll be passing everything by you. No worries.

Paul

On 7/6/07, Henri Yandell [EMAIL PROTECTED] wrote:


On 7/6/07, Niall Pemberton [EMAIL PROTECTED] wrote:
 On 7/6/07, Paul Benedict [EMAIL PROTECTED] wrote:
  I would like to commit to commons validator and commons i18n to
enhance
  them for Struts. For validator, I want to add and finish some issues
in
  the current snapshot, and, respectively, port some good i18n code from
  other Apache projects. Can I get karma for this?

 Although Commons has a liberal policy on giving Karma to ASF
 committers a better (more ASF like) first step IMO would have been to
 start talking about what you want to do first - a good recent example
 of that is Dain:

 http://tinyurl.com/yrmgpf

 Even though I'm already a committer I still regularly create Jira
 tickets and post patches (for code changes) to components that I don't
 have much history on rather than diving straight in.  I'm hoping
 you'll do the same, 'coz I'm going to be unhappy if I start seeing
 Validator commits with no prior discussion.

Ack - Martin just pointed out that it's Sandbox karma on request, not
all of Commons.

I'll adjust - ie: Paul will have commit for i18n, but we'll have to
vote to give him commit to validator.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

request karma to commons validator/i18n

2007-07-05 Thread Paul Benedict

I would like to commit to commons validator and commons i18n to enhance 
them for Struts. For validator, I want to add and finish some issues in 
the current snapshot, and, respectively, port some good i18n code from 
other Apache projects. Can I get karma for this?


Thanks,
Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (FILEUPLOAD-140) Means to preserve text parameters when upload limit exceeded

2007-07-04 Thread Paul Benedict (JIRA)

Means to preserve text parameters when upload limit exceeded


 Key: FILEUPLOAD-140
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-140
 Project: Commons FileUpload
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Paul Benedict
 Fix For: 1.2.1


I am trying to resolve https://issues.apache.org/struts/browse/STR-2585 but am 
lacking the means to do it. The current use is with the deprecated 
DiskFileUpload and I prefer to have this class fixed first. When 
SizeLimitExceededException is thrown, it does not return the items it has 
collected thus far. I see two possible solutions which involve adding a 
property on the exception to return them:

(1) Return the parameters thus gathered or 
(2) finish out the input stream but throw away all file items and return only 
the text parameters.

Otherwise, whenever a the upload exceeds its limit, all other input parameters 
disappear.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: infrastructure work for TLP move

2007-07-02 Thread Paul Libbrecht


Hello Torsten,

indeed... I just wanted to avoid making noise there... but in any  
case... I might be out of the two years window but I would wish to  
keep jelly committership, my ASF user-name is polx.


I would also favour splitting the lists so that commits and jira  
mails come separately but we need to care that they are properly  
advertised and that it is indicated on dev and users that such mails  
are elsewhere.


Also be sure that announces of such (mail-list splitting,  
committership overtake, ...) is announced as a separate mail... such  
long threads as this one needs more hand-pealing.


thanks

paul


Le 1 juil. 07 à 02:32, Torsten Curdt a écrit :

I think it's clear that old committers can get back access at any  
time. That's for sure.
But could you bring this up on commons-dev? We probably should send  
around an announcement for that.


cheers
--
Torsten

On 28.06.2007, at 00:31, Paul Libbrecht wrote:

if I dare request, I would prefer to keep committership even  
though my activities haven't been greatly active in jelly.

Similarly, I think, for Peter Royal.

paul



Le 27 juin 07 à 17:52, Torsten Curdt a écrit :

I've prepared the TODO for the infrastructure work. Please cross- 
check and give feedback. I am not sure how we want to handle the  
wiki migration.


cheers

--
The board has agreed to create the Commons project. (Please note  
that there has been a previous commons TLP)


To aid in the process, would the Infrastructure team please do  
the following:


#===

[1] Root Tasks

Create unix group commons. If it already exists remove previous  
members.


Add following usernames to group commons:

bayard
jochen
imario
scolebourne
dennisl
niallp
mvdb
ozeigermann
joehni
oheger
mbenson
martinc
psteitz
tcurdt
dfs
rwinston
luc
pietsch
dion
brentworden
skitching
rahul

Verify that domain commons.apache.org is correctly setup.


#===
[1] Mailing List

(i) addresses

I. [EMAIL PROTECTED]

* Henri Yandell[EMAIL PROTECTED]
* Jochen Wiedmann  [EMAIL PROTECTED]
* Mario Ivankovits [EMAIL PROTECTED]
* Stephen Colebourne   [EMAIL PROTECTED]
* Dennis Lundberg  [EMAIL PROTECTED]
* Niall Pemberton  [EMAIL PROTECTED]
* Martin van den Bemt  [EMAIL PROTECTED]
* Oliver Zeigermann[EMAIL PROTECTED]
* Jörg Schaible[EMAIL PROTECTED]
* Oliver Heger [EMAIL PROTECTED]
* Matt Benson  [EMAIL PROTECTED]
* Martin Cooper[EMAIL PROTECTED]
* Phil Steitz  [EMAIL PROTECTED]
* Torsten Curdt[EMAIL PROTECTED]
* Daniel Savarese  [EMAIL PROTECTED]
* Rory Winston [EMAIL PROTECTED]
* Luc Maisonobe[EMAIL PROTECTED]
* Joerg Pietschmann[EMAIL PROTECTED]
* Dion Gillard [EMAIL PROTECTED]
* Brent Worden [EMAIL PROTECTED]
* Simon Kitching   [EMAIL PROTECTED]
* Rahul Akolkar[EMAIL PROTECTED]


   II. [EMAIL PROTECTED]  migrate subscribers from  commons- 
[EMAIL PROTECTED]
  III. [EMAIL PROTECTED]  migrate subscribers from  commons- 
[EMAIL PROTECTED]
NOTE: if possible forward [EMAIL PROTECTED] to  
[EMAIL PROTECTED]


(ii) remote moderators ...

  As this is a migration of the mailing list the current  
moderators will take over on the different domain.


(iii) archives

   I. http://commons.apache.org/mail/commons/user/MM.gz
  II. http://commons.apache.org/mail/commons/dev/MM.gz
III. [EMAIL PROTECTED] to be archived in the private area.

(iv) options

   I. Reply-To: Header [X] yes [ ] no
  II. Message Trailer  [X] yes [ ] no

#===
[2] Source Control

(i) Subversion

Move the existing jakarta/commons tree to TLP

#===
[3] Initial Committer list

bayard
jochen
imario
scolebourne
dennisl
niallp
mvdb
ozeigermann
joehni
oheger
mbenson
martinc
psteitz
tcurdt
dfs
rwinston
luc
pietsch
dion
brentworden
skitching
rahul

#===
[4] Wiki

(i) Wiki pages need to be migrated

http://wiki.apache.org/jakarta-commons/FrontPage

This can be done by the community itself.

#===
[5] Bug tracking

(i) Project URLs need to be migrated

This can be done by the community itself.
 
-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]









smime.p7s
Description: S/MIME cryptographic signature

[jira] Created: (LANG-343) Validate: Throw NullArgumentException

2007-06-24 Thread Paul Benedict (JIRA)

Validate: Throw NullArgumentException
-

 Key: LANG-343
 URL: https://issues.apache.org/jira/browse/LANG-343
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Paul Benedict
 Fix For: 2.3.1


Validate methods should throw NullArgumentException on detecting null, not just 
IllegalArgumentException (its superclass)

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[JXPath] ConcurrentModificationException, fix for last() throws NullPointerException, and /node/node/node

2007-06-05 Thread Paul Joey Clark

Three possible bugs here, and one fix.

We have been using JXPath 1.1 to extract elements from webpages, parsed
into Document format by JTidy (or sometimes NekoHTML).  JXPath is great.
=)

But when running JXPath at the same time in many different threads, we
sometimes get:

java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
at java.util.HashMap$EntryIterator.next(HashMap.java:824)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.cleanupCache(JXPathContextReferenceImpl.java:270)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.compileExpression(JXPathContextReferenceImpl.java:252)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPathContextReferenceImpl.java:283)

At the moment we avoid this problem by synchronising all our calls to
JXPath so that they will never execute concurrently.  Maybe some
synchronization should be introduced inside the JXPath library (e.g.
around compileExpression or cleanupCache) to prevent this happening in
general.



Another issue we encountered: the last() function throws a
NullPointerException every time we try to use it:

java.lang.NullPointerException
at
org.apache.commons.jxpath.ri.model.dom.DOMNodeIterator.previous(DOMNodeIterator.java:131)
at
org.apache.commons.jxpath.ri.model.dom.DOMNodeIterator.setPosition(DOMNodeIterator.java:121)
at
org.apache.commons.jxpath.ri.axes.ChildContext.setPosition(ChildContext.java:152)
at
org.apache.commons.jxpath.ri.compiler.CoreFunction.functionLast(CoreFunction.java:335)

We have been working around this by doing path[count(path)], but
it would be nice to fix last() so that it always works.  (See fix
below.)



I thought I might poke around in the code and try to fix this, but
before I started I tried to upgrade to JXPath 1.2.

Unfortunately, I encountered a new problem with this upgrade.  The
XPaths returned to me no longer referred to HTML elements (e.g.
/html[1]/body[1]/p[3]/br[2]).  Searches for //p were now  failing,
and a search for //* revealed that the XPath results now looked like:
/node[1]/node[1]/node[5]/node[4].

I tried again with the source code in subversion, and the results were
the same.

Do you have any idea how to fix this problem?



OK well back to the fix for last().  I just added this second
context.reset() in JXPath 1.1's
org.apache.commons.jxpath.ri.compiler.CoreFunction.functionLast():

protected Object functionLast(EvalContext context) {
assertArgCount(0);
// Move the position to the beginning and iterate through
// the context to count nodes.
int old = context.getCurrentPosition();
context.reset();
int count = 0;
while (context.nextNode()) {
count++;
}

// Restore the current position.
context.reset(); // First reset, since the counting has probably
sent us off the end of the node list.
if (old != 0) {
context.setPosition(old);
}
return new Double(count);
}

Now using last() no longer causes an Exception.  :)

If this seems a valid fix, you may wish you add it to your latest
source.

Thanks, Joey.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (VALIDATOR-230) Enum validator

2007-05-28 Thread Paul Benedict (JIRA)

Enum validator
--

 Key: VALIDATOR-230
 URL: https://issues.apache.org/jira/browse/VALIDATOR-230
 Project: Commons Validator
  Issue Type: New Feature
Affects Versions: 1.3.1 Release
Reporter: Paul Benedict
 Fix For: 1.4


An enum validator which validates a value is member of an Commons Enum type 
or JDK5 type. Attachment forthcoming.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (VALIDATOR-230) Enum validator

2007-05-28 Thread Paul Benedict (JIRA)


 [ 
https://issues.apache.org/jira/browse/VALIDATOR-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated VALIDATOR-230:


Affects Version/s: (was: 1.3.1 Release)

 Enum validator
 --

 Key: VALIDATOR-230
 URL: https://issues.apache.org/jira/browse/VALIDATOR-230
 Project: Commons Validator
  Issue Type: New Feature
Reporter: Paul Benedict
 Fix For: 1.4


 An enum validator which validates a value is member of an Commons Enum type 
 or JDK5 type. Attachment forthcoming.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (LANG-332) EqualsBuilder to alternatively use method properties

2007-05-08 Thread Paul Benedict (JIRA)

EqualsBuilder to alternatively use method properties


 Key: LANG-332
 URL: https://issues.apache.org/jira/browse/LANG-332
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Paul Benedict
 Fix For: 3.0


While it is very nice reflection can be used to build a nice equals method, the 
strategy to focus on private properties is non-negotiable. This strategy is 
incompatible with CGLIB proxies which rely on method invocations to delegate to 
the properties of the inner target. I would prefer a switch to dynamically 
invoke public get* methods over direct property access.

PS: Same thoughts on ReflectionToStringBuilder and HashCodeBuilder

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-3) Drop 1st class dependency on commons-logging

2007-04-22 Thread Paul Smith (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490759
 ] 

Paul Smith commented on CONFIGURATION-3:


I have just raised this log4j-java logging thing on the log4j-dev list.  I'm 
pushing for it in log4j 1.2.15, probably as a standalone companion jar to 
log4j, and support in the Configurator classes.  

 Drop 1st class dependency on commons-logging
 

 Key: CONFIGURATION-3
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Joerg Schaible
Priority: Minor
 Fix For: 2.0


 Currently commons-logging is reported as first class dependency in the project
 reports. This is not true. The only classes that make direct usage of JCL are
 ConfigurationDynaBean/Class and this only for tracing. It would be nice to
 eliminate this reference at all and list JCL only as transitive dependency of
 digester and beanutils.
 We might support logging with the monitor/listener concept of
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38929

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-3) Drop 1st class dependency on commons-logging

2007-04-22 Thread Paul Smith (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490760
 ] 

Paul Smith commented on CONFIGURATION-3:


created Bugzilla entry for log4j: 
http://issues.apache.org/bugzilla/show_bug.cgi?id=42189

 Drop 1st class dependency on commons-logging
 

 Key: CONFIGURATION-3
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Joerg Schaible
Priority: Minor
 Fix For: 2.0


 Currently commons-logging is reported as first class dependency in the project
 reports. This is not true. The only classes that make direct usage of JCL are
 ConfigurationDynaBean/Class and this only for tracing. It would be nice to
 eliminate this reference at all and list JCL only as transitive dependency of
 digester and beanutils.
 We might support logging with the monitor/listener concept of
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38929

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JELLY-275) j:new casts objects to java.lang.String

2007-04-03 Thread Paul Libbrecht (JIRA)


[ 
https://issues.apache.org/jira/browse/JELLY-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486524
 ] 

Paul Libbrecht commented on JELLY-275:
--

Andre,

this really looks like a bug.
I believe that on should rather accept any object but maybe there's something 
hidden somewhere that requires this one to be a string.

The following would be a workaround:

  j:new var=foo className=java.io.File 
j:arg value=./
  /j:new
  j:set var=isFile value=${foo.isFile()}/

paul

 j:new casts objects to java.lang.String
 ---

 Key: JELLY-275
 URL: https://issues.apache.org/jira/browse/JELLY-275
 Project: Commons Jelly
  Issue Type: Bug
  Components: core / taglib.core
Affects Versions: 1.1.1
Reporter: Andre Huertas

 I execute the following Jelly script:
   j:new var=foo className=java.io.File 
   j:arg value=./
   /j:new
   j:invoke method=isFile var=isFile on=${foo} /
 and get the following Exception when I do:
 java.lang.NoSuchMethodException: No such accessible method: isFile() on 
 object: java.lang.String.
 The same happens if I use the util:file tag.
 When I take a look at my log4j file I see the following debug statement:
 DEBUG main org.apache.commons.beanutils.ConvertUtils - Convert string 
 'java.io.File' to class 'java.lang.String'

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jelly] webstartable generic jelly

2007-01-15 Thread Paul Libbrecht



 is something I just managed and it is real easy, to my surprise it 
even works with ant.


Now that there's java web start 1.5 (and JNLP 1.5), it might be useful 
to make:
- a command-line generic jelly that starts in the current directory and 
runs run.jelly or another one given as parameter (note: this outputs 
nothing in the console, it could output to a current-dir log-file)
- a file-extension association so that double-clicked jelly file (unless 
otherwise instructed) could be run by this application


Worth comitting into the jelly tree ?

paul


smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Commented: (JXPATH-10) [jxpath] JXPath 1.1 code using custom functions failing when run in 1.2 onwards

2007-01-08 Thread Paul Parisi (JIRA)


[ 
https://issues.apache.org/jira/browse/JXPATH-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463199
 ] 

Paul Parisi commented on JXPATH-10:
---




 [jxpath] JXPath 1.1 code using custom functions failing when run in 1.2 
 onwards
 ---

 Key: JXPATH-10
 URL: https://issues.apache.org/jira/browse/JXPATH-10
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: 1.2 Final
 Environment: Operating System: other
 Platform: PC
Reporter: Paul Parisi
Priority: Blocker
 Fix For: 1.3


 We have recently attempted to upgrade from a 1.1 release of jxpath
 to 1.2 and found a great deal of our jxpath code fails to run correctly. 
 We isolated the problem to relating to the use of Custom Extension
 Functions and have included sample junit test case snippets that should 
 demonstrate the issue clearly. 
 The background on what we are trying to do with jxpath is as follows
 (included so its clear on what we are trying to use jxpath to achieve):
 Within our project, we make extensive use of Custom Extension Functions in 
 JXPath.  
 We also use JXPath variables significantly, in combination with these 
 functions, 
 that often take a JXPath variable as an argument(s) to the function.
 We now rely heavily on the use of the ExpressionContext interface as the 
 first 
 argument to many of our functions.  The reason for this is that we need a
 convienient way to obtain access to 'original' object references within the
 context invoked by the function (as you would expect).
 However, we have also begun using a very useful combination of features, which
 the API supports in version 1.1, where the first argument always defines the
 ExpressionContext interface (which isn't really part of the method signature -
 from a caller perspective), and a 2nd argument as 'Object' type. Within body 
 of
 the function, we then cast the object of the 2nd argument as a NodeSet (or
 define the NodeSet type within the method signature - either appears to work),
 which provides us with access to the pointers for the object. 
 As previously mentioned, a jxpath variable is passed from the caller of the
 function (received via the 2nd argument in the method signature), which is
 automatically resolved, by jxpath, to the object itself.
 The benefit of casting the object to NodeSet (interface) enables us to 
 retrieve
 the first pointer in the NodeSet list. The first pointer concerns us, as it
 refers to the String value passed to the argument of the function which we 
 need
 access to.  The object reference itself is of little concern in this case, as
 once we have access to the variable name sent to the function, we can access 
 the
 object via the ExpressionContext.
 This all works fine in jxpath 1.1, however, in version 1.2 this functionality 
 is
 now broken, since our objects are no longer being cast to NodeSet (previously
 achieved via the internal implementation of jxpath NodeSet using a 
 SimpleNodeSet
 - as per inspecting jxpath 1.1 source code).
 Note on the use of ExpressionContext: For those methods that declare the
 ExpressionContext interface (which must be the first argument, if used), as 
 part
 of the argument list, the method signature from the caller perspective, 
 excludes
 it from the argument list, as it is implied by jxpath.  In other words, there
 will be one less argument from the caller when the interface is used.  In the
 case where this interface was the only argument, which is common, then the
 caller would be invoking a zero-argument method.  This is behaviour we expect.
 Here is a simplified example of one of our functions using the techniques
 discussed:-
 public static void deleteSomeObject(ExpressionContext expContext, Object obj) 
 {
  // create a local jxpath context to retrieve values for jxpath variables
  JXPathContext localContext = expContext.getJXPathContext();
  // Nodeset of the object passed to method
  NodeSet nodeset = (NodeSet)obj;
  // Retrieve variable name passed to function
  String declaredVariable = nodeset.getPointers().get(0).toString();
  Object objectToDelete = null;
 // If this method was passed the $obj1 var to delete, then retrieve 'Object 
 Type
 1' via $obj1 variable 
if (declaredVariable.equals($obj1)) {
   objectToDelete = (ObjectType1)localContext.getValue($obj1);
   }
   // If this method was passed the $obj2 var to delete, then retrieve 
 'Object
 Type 2' via $obj2 variable 
   if (declaredVariable.equals($obj2)) { 
   objectToDelete = (ObjectType2)localContext.getValue($obj2);
   }
   collectionOfSomeObjects.delete(objectToDelete);
  }
 Which would be used (called) in the following way:-
 ...
 // add to collection
 ObjectType1 objectType1 = new

[jira] Commented: (JXPATH-10) [jxpath] JXPath 1.1 code using custom functions failing when run in 1.2 onwards

2007-01-08 Thread Paul Parisi (JIRA)


[ 
https://issues.apache.org/jira/browse/JXPATH-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463204
 ] 

Paul Parisi commented on JXPATH-10:
---

Hello Matt,
  We originally logged this defected some time back.  I note you are interested 
in knowing our
progress from your comments. 

Since logging this defect we stopped using jxpath 1.2 and commented out all the 
unit tests we had
developed that depending on its functionality (we cannot run two versions of 
jxpath in our 
build system) So essentially we have not been able to upgrade jxpath, however 
we still would like
to do this as we eventually.  If you are able to provide a workaround we would 
be keen to try it out.

regards,
Paul Parisi


 [jxpath] JXPath 1.1 code using custom functions failing when run in 1.2 
 onwards
 ---

 Key: JXPATH-10
 URL: https://issues.apache.org/jira/browse/JXPATH-10
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: 1.2 Final
 Environment: Operating System: other
 Platform: PC
Reporter: Paul Parisi
Priority: Blocker
 Fix For: 1.3


 We have recently attempted to upgrade from a 1.1 release of jxpath
 to 1.2 and found a great deal of our jxpath code fails to run correctly. 
 We isolated the problem to relating to the use of Custom Extension
 Functions and have included sample junit test case snippets that should 
 demonstrate the issue clearly. 
 The background on what we are trying to do with jxpath is as follows
 (included so its clear on what we are trying to use jxpath to achieve):
 Within our project, we make extensive use of Custom Extension Functions in 
 JXPath.  
 We also use JXPath variables significantly, in combination with these 
 functions, 
 that often take a JXPath variable as an argument(s) to the function.
 We now rely heavily on the use of the ExpressionContext interface as the 
 first 
 argument to many of our functions.  The reason for this is that we need a
 convienient way to obtain access to 'original' object references within the
 context invoked by the function (as you would expect).
 However, we have also begun using a very useful combination of features, which
 the API supports in version 1.1, where the first argument always defines the
 ExpressionContext interface (which isn't really part of the method signature -
 from a caller perspective), and a 2nd argument as 'Object' type. Within body 
 of
 the function, we then cast the object of the 2nd argument as a NodeSet (or
 define the NodeSet type within the method signature - either appears to work),
 which provides us with access to the pointers for the object. 
 As previously mentioned, a jxpath variable is passed from the caller of the
 function (received via the 2nd argument in the method signature), which is
 automatically resolved, by jxpath, to the object itself.
 The benefit of casting the object to NodeSet (interface) enables us to 
 retrieve
 the first pointer in the NodeSet list. The first pointer concerns us, as it
 refers to the String value passed to the argument of the function which we 
 need
 access to.  The object reference itself is of little concern in this case, as
 once we have access to the variable name sent to the function, we can access 
 the
 object via the ExpressionContext.
 This all works fine in jxpath 1.1, however, in version 1.2 this functionality 
 is
 now broken, since our objects are no longer being cast to NodeSet (previously
 achieved via the internal implementation of jxpath NodeSet using a 
 SimpleNodeSet
 - as per inspecting jxpath 1.1 source code).
 Note on the use of ExpressionContext: For those methods that declare the
 ExpressionContext interface (which must be the first argument, if used), as 
 part
 of the argument list, the method signature from the caller perspective, 
 excludes
 it from the argument list, as it is implied by jxpath.  In other words, there
 will be one less argument from the caller when the interface is used.  In the
 case where this interface was the only argument, which is common, then the
 caller would be invoking a zero-argument method.  This is behaviour we expect.
 Here is a simplified example of one of our functions using the techniques
 discussed:-
 public static void deleteSomeObject(ExpressionContext expContext, Object obj) 
 {
  // create a local jxpath context to retrieve values for jxpath variables
  JXPathContext localContext = expContext.getJXPathContext();
  // Nodeset of the object passed to method
  NodeSet nodeset = (NodeSet)obj;
  // Retrieve variable name passed to function
  String declaredVariable = nodeset.getPointers().get(0).toString();
  Object objectToDelete = null;
 // If this method was passed the $obj1 var to delete, then retrieve 'Object 
 Type
 1' via $obj1 variable

[jira] Closed: (EMAIL-9) [email] Issue with host settings in a shared Server environment

2007-01-03 Thread Paul J DeCoursey (JIRA)


 [ 
https://issues.apache.org/jira/browse/EMAIL-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul J DeCoursey closed EMAIL-9.


Resolution: Fixed

I think this was fixed.  I thought that it got closed out already too. I 
discovered what the issue was a few days after I reported this, and then 
discovered that it had been fixed already, we just had an older jar.

 [email] Issue with host settings in a shared Server environment
 ---

 Key: EMAIL-9
 URL: https://issues.apache.org/jira/browse/EMAIL-9
 Project: Commons Email
  Issue Type: Bug
 Environment: Operating System: other
 Platform: All
Reporter: Paul J DeCoursey

 So the quick and dirty is I'm setting up an HTMLEmail and the server is in a
 shared environment, there is another site on the server using commons-email, 
 and
 I have no control over that site.  I set the hostname and the authentication 
 but
 after that it's taking the settings from the System.properies. Below is a snip
 from my code.
 org.apache.commons.mail.HtmlEmail email = new 
 org.apache.commons.mail.HtmlEmail();
 email.setHostName(server);
 email.setAuthentication(username, password);
 After that point I can get the session:
 Session sess = email.getMailSession();
 sess.getProperty(mail.smtp.host);
  and the result of the getProperty(mail.smtp.host) does not equal the 
 setting
 from the above server variable.  It is now set to the value from
 System.propeties, again, not my setting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-238) [lang] Add equals(type[]) to NumberUtils

2006-12-31 Thread Paul Benedict (JIRA)

[ 
http://issues.apache.org/jira/browse/LANG-238?page=comments#action_12461598 ] 

Paul Benedict commented on LANG-238:


I don't know if it is useful, but the float/double version could provide a 
precision field. Perhaps someone is interested if X values are equal only up to 
the Nth decimal point.

 [lang] Add equals(type[]) to NumberUtils
 

 Key: LANG-238
 URL: http://issues.apache.org/jira/browse/LANG-238
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: Other
Reporter: Paul Benedict
Priority: Minor
 Fix For: 3.0


 It would be useful to add an equals() method like the current min and max
 methods which take an array type and determine if all the values are equal.
 I have found myself in need of this often. I have to retrieve objects from
 multiple data sources in parallel to build an array of complex object. To 
 ensure
 validity, I always compare that my sub-retrievals returned the same number of
 objects as expected.

-- 
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-238) [lang] Add equals(type[]) to NumberUtils

2006-12-31 Thread Paul Benedict (JIRA)

[ 
http://issues.apache.org/jira/browse/LANG-238?page=comments#action_12461600 ] 

Paul Benedict commented on LANG-238:


In my opinon, you could also just name the method with equal (singlar): 
equal(), equalTrue(), equalFalse(), etc. I prefer that over allEquals.

 [lang] Add equals(type[]) to NumberUtils
 

 Key: LANG-238
 URL: http://issues.apache.org/jira/browse/LANG-238
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: Other
Reporter: Paul Benedict
Priority: Minor
 Fix For: 3.0


 It would be useful to add an equals() method like the current min and max
 methods which take an array type and determine if all the values are equal.
 I have found myself in need of this often. I have to retrieve objects from
 multiple data sources in parallel to build an array of complex object. To 
 ensure
 validity, I always compare that my sub-retrievals returned the same number of
 objects as expected.

-- 
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-238) [lang] Add equals(type[]) to NumberUtils

2006-12-29 Thread Paul Benedict (JIRA)

[ 
http://issues.apache.org/jira/browse/LANG-238?page=comments#action_12461475 ] 

Paul Benedict commented on LANG-238:


The rollback is correct, but that's because the implementation is wrong. The 
enhancement request is not to compare two arrays of whatever type, but to 
compare one array of values to make sure they contain the same value -- ala the 
max and min method signatures.

Not:
equals(int[], int[])

But:
equals(int[])

 [lang] Add equals(type[]) to NumberUtils
 

 Key: LANG-238
 URL: http://issues.apache.org/jira/browse/LANG-238
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: Other
Reporter: Paul Benedict
Priority: Minor
 Fix For: 2.3


 It would be useful to add an equals() method like the current min and max
 methods which take an array type and determine if all the values are equal.
 I have found myself in need of this often. I have to retrieve objects from
 multiple data sources in parallel to build an array of complex object. To 
 ensure
 validity, I always compare that my sub-retrievals returned the same number of
 objects as expected.

-- 
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Broken links in tag reference

2006-11-17 Thread Paul Libbrecht


Now... I'm still missing to understand how this tag-reference is produced!
I have finally found source xdocs for the handwritten ones but how are 
the very many others produced which are empty ? At least, one should 
correct these to the jelly doc output for the moment, or ?


thanks for enlightening me.

paul


Dion Gillard wrote:

On 7/25/06, Paul Libbrecht [EMAIL PROTECTED] wrote:

Dion Gillard wrote:
 The idea with the tag reference was to have a one stop place for all
 the documentation.
I thought this was what libs/index.html does.
It's generated before xdoc:transform


Not very well. It lists the tag libs, but doesn't provide anything
like ant's manual: http://ant.apache.org/manual/index.html ,
especially the tasks frameset.


 If we can do that with links and by improving the individual taglib
 documentation, I'm all for it.
So the correct way for working would be to enrich libs/index.html with a
link to examples... right? Anything else than unit-tests ??


If libs/index.html included an easy to navigate list of the tags
within the taglib, it'd be a lot better.


 The problem with the current taglib documentation is that
 a) it's autogenerated off inadequate source markup
What's that wrong ?? If the javadoc comments are inadequate, we need to
make them correct, I think the jellydoc takes precedence of 
javadoc... or ?


Lack of detail. Check out
http://jakarta.apache.org/commons/jelly/tag-reference/ant_fileScanner.html 


and compare it to
http://jakarta.apache.org/commons/jelly/libs/ant/tags.html#ant:fileScanner 




 b) It doesn't provide examples and usage info.
how would you document examples except with unit-tests ??


Snippets for the examples, and better usage info for badly documented
stuff like fileScanner as an example.

If we can merge this stuff into better done JellyDoc, I'd be happy
with that too.



paul

 On 7/25/06, Paul Libbrecht [EMAIL PROTECTED] wrote:
 It isn't easy as that, building the site does take a huge time 
because

 of the very many tag-libs depending on the maven version this may
 even turn out to impossible.

 This tag-reference page makes double usage with:
 http://jakarta.apache.org/commons/jelly/libs/index.html
 whose links are all correct... why keep it ?

 Rebuilding the site would probably fix it if replacing
 tag-reference/x.html with libs/x/tags.html
 but do we really need that ??

 paul



 Dennis Lundberg wrote:
  That might be so, but the links on the All tags page work. So 
it's
  just a matter of fixing some links. If I go ahead and do that 
would it

  be OK to redeploy the site?
 
  Dion Gillard wrote:
  I don't think the tag reference is complete.
 
  On 7/25/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
  Hi
 
  The links under Tag Reference are all broken. That is all
 except All
  tags.
 
http://jakarta.apache.org/commons/jelly/tag-reference/index.html

 

















smime.p7s
Description: S/MIME Cryptographic Signature

[fileupload] [Fwd: REX and File Upload published]

2006-10-23 Thread Paul Libbrecht

I just wanted to make sure that Commons-FileUpload's project's members 
are aware of this ongoing specification.


paul

 Original Message 
Subject:REX and File Upload published
Resent-Date:Sun, 22 Oct 2006 17:03:41 +
Resent-From:public-webapi@w3.org
Date:   Sun, 22 Oct 2006 19:03:31 +0200
From:   Charles McCathieNevile [EMAIL PROTECTED]
Organization:   Opera Software
To: Web API public public-webapi@w3.org
References: [EMAIL PROTECTED]



Hi folks, there is a new working draft of REX [1], and a first public  
working draft of file upload, for your delectation. We are hoping to take 
REX in this version to last call very shortly, and may then start on a  
version 2. So if you want to comment, please do so sooner rather than  
later (File Upload is not on such an aggressive schedule, but comments are  
also welcome of course).


[1] http://www.w3.org/TR/rex
[2] http://www.w3.org/TR/file-upload

Cheers

Chaals

--
 Charles McCathieNevile, Opera Software: Standards Group
 hablo español  -  je parle français  -  jeg lærer norsk
[EMAIL PROTECTED]  Try Opera 9 now! http://opera.com





smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Created: (VALIDATOR-200) validateCreditCard javascript could ignore whitespace and hyphens

2006-09-22 Thread Paul Devine (JIRA)

validateCreditCard javascript could ignore whitespace and hyphens
-

 Key: VALIDATOR-200
 URL: http://issues.apache.org/jira/browse/VALIDATOR-200
 Project: Commons Validator
  Issue Type: Improvement
  Components: JavaScript
Affects Versions: 1.3.0 Release
 Environment: -all-
Reporter: Paul Devine
Priority: Minor


the validateCreditCard javascript routine flags an input field as an invalid 
credit card number if the input field contains any non-numeric characters or 
whitespaces.  I currently modify the input field's value before validation to 
remove whitespaces and hyphens, like this:

$('paymentForm:cardNumber').value = $('paymentForm:cardNumber').value.replace(/ 
/g,'');
$('paymentForm:cardNumber').value = 
$('paymentForm:cardNumber').value.replace(/-/g,'');

It would be simple enough to have the validateCreditCard function handle this, 
but rather than modifying the input field value, it would modify the variable 
it is validating on, so the user does not see any `change` in what they have 
entered

-- 
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jelly] stream of XML fragments ?

2006-09-20 Thread Paul Libbrecht



Hello,

since  a while I'm considering the implementation of a reader for 
log-like file formats, that is, for files that are xml up to a header 
and footer. We use these in our ActiveMath system, typically, as log 
files, where each new log entry is output as a new element.


loglike:parse url=a.xml var=iterator
 loglike:header![CDATA[!DOCTYPE root SYSTEM ../dtd/xx.dtd
   root]]/loglike:header
 loglike:footer![CDATA[/root]]/loglike:footer
/loglike:parse

j:forEach items=${iterator} var=elt
 !-- do someting with ${elt} which would be a dom4j.Element probably --
/j:forEach

Would anyone else take advantage of such parsing tags ?
It has the strong advantage of being streamed (these log files are 
easily enormous) and still let jelly's ease of xml manipulations and 
filtering.


paul


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Commons JEXL 1.1

2006-09-05 Thread Paul Libbrecht

Just my 2p: if I remember well, there's a way checkstyle errors can 
produce a text-like report with filename:line-number:message which is 
exactly what most compilers would output to make errors clickable in, 
say, jEdit and Emacs to name a few... That helped me every time i was 
haunted by the checkstyle reports...


paul

Dion Gillard wrote:

Rahul,

I'll start looking at the checkstyle config and issues if you're happy
with that?

On 9/4/06, Phil Steitz [EMAIL PROTECTED] wrote:

Looks good to me.  +1 assuming build has been tested on 1.2, which is
what the jar manifest specifies.

One small nit, which you could do without another RC, IMO, or ignore:

The checkstyle report is not clean.  One real javadoc error is
flagged, some missing javadoc, missing package javadoc for a couple of
packages, and some bogus complaints. I would recommend either fixing
all of the errors, modifying checkstyle.xml, or dropping the report
from the doc included in the distribution.

Phil

On 8/31/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
 Ran the usual gamut of checks, looks good to me.

 snip/
  ---
  [X] +1  I support this release
  [ ] +0
  [ ] -0
  [ ] -1  I oppose this release because...
  
 
 snap/

 -Rahul

 -
 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]









smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jelly] Broken links in tag reference

2006-07-25 Thread Paul Libbrecht

It isn't easy as that, building the site does take a huge time because 
of the very many tag-libs depending on the maven version this may 
even turn out to impossible.


This tag-reference page makes double usage with:
   http://jakarta.apache.org/commons/jelly/libs/index.html
whose links are all correct... why keep it ?

Rebuilding the site would probably fix it if replacing 
tag-reference/x.html with libs/x/tags.html

but do we really need that ??

paul



Dennis Lundberg wrote:
That might be so, but the links on the All tags page work. So it's 
just a matter of fixing some links. If I go ahead and do that would it 
be OK to redeploy the site?


Dion Gillard wrote:

I don't think the tag reference is complete.

On 7/25/06, Dennis Lundberg [EMAIL PROTECTED] wrote:

Hi

The links under Tag Reference are all broken. That is all except All
tags.
   http://jakarta.apache.org/commons/jelly/tag-reference/index.html





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jelly] Broken links in tag reference

2006-07-25 Thread Paul Libbrecht


Dion Gillard wrote:

The idea with the tag reference was to have a one stop place for all
the documentation.

I thought this was what libs/index.html does.
It's generated before xdoc:transform

If we can do that with links and by improving the individual taglib
documentation, I'm all for it.
So the correct way for working would be to enrich libs/index.html with a 
link to examples... right? Anything else than unit-tests ??

The problem with the current taglib documentation is that
a) it's autogenerated off inadequate source markup
What's that wrong ?? If the javadoc comments are inadequate, we need to 
make them correct, I think the jellydoc takes precedence of javadoc... or ?

b) It doesn't provide examples and usage info.

how would you document examples except with unit-tests ??

paul


On 7/25/06, Paul Libbrecht [EMAIL PROTECTED] wrote:

It isn't easy as that, building the site does take a huge time because
of the very many tag-libs depending on the maven version this may
even turn out to impossible.

This tag-reference page makes double usage with:
http://jakarta.apache.org/commons/jelly/libs/index.html
whose links are all correct... why keep it ?

Rebuilding the site would probably fix it if replacing
tag-reference/x.html with libs/x/tags.html
but do we really need that ??

paul



Dennis Lundberg wrote:
 That might be so, but the links on the All tags page work. So it's
 just a matter of fixing some links. If I go ahead and do that would it
 be OK to redeploy the site?

 Dion Gillard wrote:
 I don't think the tag reference is complete.

 On 7/25/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
 Hi

 The links under Tag Reference are all broken. That is all 
except All

 tags.
http://jakarta.apache.org/commons/jelly/tag-reference/index.html












smime.p7s
Description: S/MIME Cryptographic Signature

[jelly] migrate faq to the faq plugin ?

2006-07-21 Thread Paul Libbrecht



hello jellyers,

the jelly faq would love to be enriched by the many questions asked on 
the list(s) but it is still a manually authored xdoc. Anything against 
me moving it to using the maven-1.1 faq plugin ?


thanks

paul


smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Created: (JXPATH-70) Javadoc missing from distribution

2006-07-14 Thread Paul Copeland (JIRA)

Javadoc missing from distribution
-

 Key: JXPATH-70
 URL: http://issues.apache.org/jira/browse/JXPATH-70
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: 1.2 Final
Reporter: Paul Copeland
Priority: Minor


The javadoc is missing from the 1.2 zip file.  Broken links in the user guide 
and elsewhere in the documentation reference the missing directory at 
docs/apidocs where the javadoc should be.

-- 
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (JELLY-232) Some ant objects throw NPE at toString

2006-06-26 Thread Paul Libbrecht (JIRA)

Some ant objects throw NPE at toString
--

 Key: JELLY-232
 URL: http://issues.apache.org/jira/browse/JELLY-232
 Project: Commons Jelly
Type: Bug

  Components: taglib.ant  
Versions: 1.1
 Environment: (MacOSX 10.3.9)
Reporter: Paul Libbrecht
 Assigned to: Paul Libbrecht 


When setting the debug mode, a lot of the creation of the ant tags are reported 
about and this invokes the toString method of the tags.
This fails for some objects such as the fileset tag... a method to call 
toString safely is needed in, at least, AntTag!
paul

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (JELLY-228) AntTag.createDataType() throws ClassCastException

2006-06-26 Thread Paul Libbrecht (JIRA)

 [ http://issues.apache.org/jira/browse/JELLY-228?page=all ]
 
Paul Libbrecht resolved JELLY-228:
--

Resolution: Fixed

Have applied the patch.
Please check and reopen if need be.
paul

 AntTag.createDataType() throws ClassCastException
 -

  Key: JELLY-228
  URL: http://issues.apache.org/jira/browse/JELLY-228
  Project: Commons Jelly
 Type: Bug

   Components: taglib.ant
  Environment: jdk1.5.0_02
 Reporter: Hang Sun
 Priority: Minor
  Attachments: JELLY-228.patch

 In my Maven 1.0.2 beta 2 env., I wrote following line:
   ant:typedef 
 file=${agitar.eclipse.site.dir}/plugins/com.agitar.agitator_${agitar.build}/types.properties
   
 classpath=${agitar.eclipse.site.dir}/plugins/com.agitar.agitator_${agitar.build}/ant-task/agitator-tasks.jar
   loaderRef=agitarjar/
 where types.properties includes 1 line:
dashboard-config=com.agitar.ant.SharedAntConfig
 SharedAntConfig is a POJO and this seems to cause problem with the AntTag 
 class, whose createDataType() method expects the data type be subclass of 
 org.apache.tools.ant.types.DataType.
 It seems to me that AntTag class should not make this assumption.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (JELLY-232) Some ant objects throw NPE at toString

2006-06-26 Thread Paul Libbrecht (JIRA)

 [ http://issues.apache.org/jira/browse/JELLY-232?page=all ]
 
Paul Libbrecht closed JELLY-232:


Resolution: Fixed

Fixed with AntTag and AntJellyContext.
paul

 Some ant objects throw NPE at toString
 --

  Key: JELLY-232
  URL: http://issues.apache.org/jira/browse/JELLY-232
  Project: Commons Jelly
 Type: Bug

   Components: taglib.ant
 Versions: 1.1
  Environment: (MacOSX 10.3.9)
 Reporter: Paul Libbrecht
 Assignee: Paul Libbrecht


 When setting the debug mode, a lot of the creation of the ant tags are 
 reported about and this invokes the toString method of the tags.
 This fails for some objects such as the fileset tag... a method to call 
 toString safely is needed in, at least, AntTag!
 paul

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release commons-jelly-tags-interaction 1.1


Maybe... I'll work on this tonight local time (in about 14 hours).
The problem is that maven dist calls the maven dist of jelly which is 
quite wrong, I think... and I did not want to touch this yet.
If it sounds appropriate and someone can check my candidate sources I 
could try this tonight before tagging it would only affect, 
probably, the maven.xml in jelly/jelly-tags.


paul


Dion Gillard wrote:

Paul can we post the source/binary distribution release after getting
the jar out?

On 6/20/06, Paul Libbrecht [EMAIL PROTECTED] wrote:

Rahul Akolkar wrote:
 Regardless of what Jelly has been doing in the past, IMO its a good
 idea to have source distributions for any release, given which one
 would be able to (atleast after meeting certain pre-requisites)
 effectively reproduce the release binaries. Why don't Jelly taglibs
 have accompanying source distros?
As a general wish, I only agree.
In this case both limit in time and the fact that this tag-library is
exactly made of one class tend me to not do so.
 Note we had a similar situation in Jakarta Taglibs which AFAICT has
 since been remedied. Also, a gentle reminder to please tag SVN (as
 previous Jelly releases have done).
Of course tagging was planned. Do you mean I should tag RC1 as well ?
 Since I've not participated in the discussion so far, and wasn't
 around to bring this up earlier for the last three days when the plan
 (below) was posted, I will vote 0. I will also encourage you to leave
 votes open for atleast 72 hours (instead of 36).
The fact that I sent this wish already long ago, with less clarity
indeed, pushes me here. And also, the fact that maven plugin release is
waiting.

paul

 Thank you for your time towards this release.
 -Rahul


 thank you in advance.

 paul

 Paul Libbrecht wrote:
  Here's the plan:
  - all issues with this tag-libs are cleared
  - no further changes are needed for the release... and almost no 
risk

  of concurrent change exist (hence no branch is needed).
  - the release shall, as with most jelly-tag-libraries, only produce
  jar files to be consumed from the maven repo at ibiblio and the 
repo

  at apache. No source or binary distribution will be made.
  - once the vote passed, I will simply update changes.xml and
  project.xml, tag the files, upload the jar to the Apache, submit 
a jar

  upload to iblio's repo.
 
  I have assembled the following release candidates...
  - a site with RC1 version tag:
  http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/
  - a jar which is the sole outcome of this subproject:
 
 
http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar 



 
















smime.p7s
Description: S/MIME Cryptographic Signature

Re: [vote] Release commons-jelly-tags-interaction 1.1


The vote result is as follows:
+1 Paul
+0 Rahul
+1 Dion
+1 Stephen
Result: +1

I tried to follow the procedure in order to see the impact of a binary 
and source releases and have to say that I feat it'll move lots of 
stuffs around. In particular, how would the mirrorred download look like 
with several flavours of dists (both binary and sources) ? I have given 
it up for now. I find it ok to have a single binary and source 
distribution of the whole jelly project (yes, I know, it should be 
released more often!).

We may consider the maven sources plugin at some point...

I am now setting things up for a proper signing and hashing then will 
achieve the jar-oriented tasks of the release guide. And send an 
announcement here and on commons-users.


paul

Paul Libbrecht wrote:
I hereby request to vote about the release of the jelly subproject 
interaction tag library.

The details of the release plan are below.
I would like to please request a vote for 36 hours, ie. till Wednesday 
14:00 GMT.

+1 [ ] yes, let's do it
0 [ ] let it happen... but I can't really check
-1 [ ] don't do it because...

thank you in advance.

paul

Paul Libbrecht wrote:

Here's the plan:
- all issues with this tag-libs are cleared
- no further changes are needed for the release... and almost no risk 
of concurrent change exist (hence no branch is needed).
- the release shall, as with most jelly-tag-libraries, only produce 
jar files to be consumed from the maven repo at ibiblio and the repo 
at apache. No source or binary distribution will be made.
- once the vote passed, I will simply update changes.xml and 
project.xml, tag the files, upload the jar to the Apache, submit a 
jar upload to iblio's repo.


I have assembled the following release candidates...
- a site with RC1 version tag:
http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/
- a jar which is the sole outcome of this subproject: 
http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar 







smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r416153 - /jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/


Dion Gillard wrote:

Don't we have tags at the taglib level for Jelly?

Nope... but that's quite ok or ?

That seems a whole lot of stuff for a single taglib.

What do you mean ?
svn cp is the only way to tag so I cp the whole project. It only 
consumes my (temp) directory space, not even the server which stores as 
deltas anyways.


paul

On 6/22/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Author: polx
Date: Wed Jun 21 15:59:04 2006
New Revision: 416153

URL: http://svn.apache.org/viewvc?rev=416153view=rev
Log:
Tag for the release 1.1 of Jelly-Tags-Interaction.
paul

Added:
jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/
  - copied from r416152, 
jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]









smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r416153 - /jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/


thanks, fixed!
paul


Lukas Theussl wrote:

Another remark: is the SNAPSHOT dependency on commons-jexl necessary?

-Lukas


Paul Libbrecht wrote:

Dion Gillard wrote:


Don't we have tags at the taglib level for Jelly?


Nope... but that's quite ok or ?


That seems a whole lot of stuff for a single taglib.


What do you mean ?
svn cp is the only way to tag so I cp the whole project. It only 
consumes my (temp) directory space, not even the server which stores 
as deltas anyways.


paul


On 6/22/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


Author: polx
Date: Wed Jun 21 15:59:04 2006
New Revision: 416153

URL: http://svn.apache.org/viewvc?rev=416153view=rev
Log:
Tag for the release 1.1 of Jelly-Tags-Interaction.
paul

Added:
jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/
  - copied from r416152, 
jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/







smime.p7s
Description: S/MIME Cryptographic Signature

[ANNOUNCE] release of commons-jelly-tags-interaction version 1.1



The jakarta commons jelly developers are happy to announce the release 
1.1 of the interaction tag-library.
This tag-library allows jelly scripts to interact with the user through 
the console.
The version 1.1 comes with the usage of the jline library which provides 
a comfortable command-line interface with auto-completion and history.


Get the jar from a maven repository near you or from:
 http://www.apache.org/dist/java-repository/commons-jelly/jars/
Get the source from the subversion repository:
http://svn.apache.org/repos/asf/jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/

Enjoy!
paul libbrecht


smime.p7s
Description: S/MIME Cryptographic Signature

[vote] Release commons-jelly-tags-interaction 1.1

2006-06-19 Thread Paul Libbrecht

I hereby request to vote about the release of the jelly subproject 
interaction tag library.

The details of the release plan are below.
I would like to please request a vote for 36 hours, ie. till Wednesday 
14:00 GMT.

+1 [ ] yes, let's do it
0 [ ] let it happen... but I can't really check
-1 [ ] don't do it because...

thank you in advance.

paul

Paul Libbrecht wrote:

Here's the plan:
- all issues with this tag-libs are cleared
- no further changes are needed for the release... and almost no risk 
of concurrent change exist (hence no branch is needed).
- the release shall, as with most jelly-tag-libraries, only produce 
jar files to be consumed from the maven repo at ibiblio and the repo 
at apache. No source or binary distribution will be made.
- once the vote passed, I will simply update changes.xml and 
project.xml, tag the files, upload the jar to the Apache, submit a jar 
upload to iblio's repo.


I have assembled the following release candidates...
- a site with RC1 version tag:
http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/
- a jar which is the sole outcome of this subproject: 
http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar 





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [vote] Release commons-jelly-tags-interaction 1.1

2006-06-19 Thread Paul Libbrecht


Rahul Akolkar wrote:

Regardless of what Jelly has been doing in the past, IMO its a good
idea to have source distributions for any release, given which one
would be able to (atleast after meeting certain pre-requisites)
effectively reproduce the release binaries. Why don't Jelly taglibs
have accompanying source distros?

As a general wish, I only agree.
In this case both limit in time and the fact that this tag-library is 
exactly made of one class tend me to not do so.

Note we had a similar situation in Jakarta Taglibs which AFAICT has
since been remedied. Also, a gentle reminder to please tag SVN (as
previous Jelly releases have done).

Of course tagging was planned. Do you mean I should tag RC1 as well ?

Since I've not participated in the discussion so far, and wasn't
around to bring this up earlier for the last three days when the plan
(below) was posted, I will vote 0. I will also encourage you to leave
votes open for atleast 72 hours (instead of 36).
The fact that I sent this wish already long ago, with less clarity 
indeed, pushes me here. And also, the fact that maven plugin release is 
waiting.


paul


Thank you for your time towards this release.
-Rahul



thank you in advance.

paul

Paul Libbrecht wrote:
 Here's the plan:
 - all issues with this tag-libs are cleared
 - no further changes are needed for the release... and almost no risk
 of concurrent change exist (hence no branch is needed).
 - the release shall, as with most jelly-tag-libraries, only produce
 jar files to be consumed from the maven repo at ibiblio and the repo
 at apache. No source or binary distribution will be made.
 - once the vote passed, I will simply update changes.xml and
 project.xml, tag the files, upload the jar to the Apache, submit a jar
 upload to iblio's repo.

 I have assembled the following release candidates...
 - a site with RC1 version tag:
 http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/
 - a jar which is the sole outcome of this subproject:
 
http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar 













smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jelly] [vote] Release commons-jelly-tags-interaction 1.1

2006-06-18 Thread Paul Libbrecht


Dion Gillard wrote:

I have assembled the following release candidates...
- a site with RC1 version tag:
 http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/
- a jar which is the sole outcome of this subproject:
http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar 


I think we need to include a NOTICE file into the jar, right? The
license by itself isn't enough, from memory.

Thanks to remind this. Indeed, this is needed according to:
 http://www.apache.org/dev/apply-license.html
and is now fixed int he linked jar above.
Without more comments, I'll request a vote tomorrow morning.

paul


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [all] jar signing with jarsigner

2006-06-16 Thread Paul Libbrecht


This thread is somewhat old but I have a new information...
I have just been pointed to the following FAQ by a friend:
 http://www.dallaway.com/acad/webstart/
Several good things in there... but one that is particularly worth it is 
about the usage of *different certificates* for different jars. The bit 
is called A note on third party JAR files and indicates that it is 
possible to use different certificates for different jars as long as you 
use the extension mechanism.
This means that signed Apache jars could make sense, even copied in 
another location. It would be distributed with an extension JNLP aside.

Only issue: the user may have to say agree on several certificates!

How safe would it be to consider creating a certificate and store it 
centrally on people.apache.org ? And request only, say, PMC members, to 
actually have the password of the keystore and sign the jars?


thanks

paul



Sandy McArthur wrote:

On 3/3/06, Paul Libbrecht [EMAIL PROTECTED] wrote:
  

As far as I could see such a thing... jar signing would need to happen
on Apache server... using some Apache private key... right ?
Maybe this is a first issue ?
How would you go to ensure that such a private key is not hacked or copied ?
Let infrastructure team do the signing ?



There is the problem of getting the cert (or root cert) into the JVM's
keystore. Unless Apache was able to persuade a well known SSL cert
issuer to donate code signing certs (which tend to be more expensive
than common ssl certs), Apache would probably just have to create it's
own root cert which would be used to issue certs to Apache members
needing to sign releases. Then, as I see it, trusting these issued
certs would be no different than trusting the PGP keys release
managers are expected to keep protected. For end users the root Apache
cert would need to be added to the JVM's keystore to be able to verify
signed jars.

  

I suppose that, with Java Web Start, the jar-signing mechanism may
request at least one authorization for each signing key...



I don't know how that would work.

--
Sandy McArthur

He who dares not offend cannot be honest.
- Thomas Paine

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jelly] [vote] Release commons-jelly-tags-interaction 1.1

2006-06-16 Thread Paul Libbrecht

robert burrell donkin wrote:

On Tue, 2006-05-09 at 23:07 +0200, Paul Libbrecht wrote:

The story seems quite simple so I thought I'd just ask for a vote sorry if too
stressed.
The interaction jelly tag-library is now ready for release 1.1.
It has been recently boosted with a finer control on auto-completion, and maven console plugin is using it successfully. Thanks to give it a try* and provide a vote.
is this a vote on the idea of releasing (in other words, a release plan) or on actually cutting a release?

if it's an actual release vote then i'd like to be able to check a
release candidate before casting a vote...

I'm trying to return to this... but am getting drowned in time.
I would like to request votes to release jelly-tags-interaction.
I have followed Preparations to release and can judge the following steps:
- I'm nominated as release manager for this (because of last votes at least)
- I am proposing a release plan (below)

Here's the plan:
- all issues with this tag-libs are cleared
- no further changes are needed for the release... and almost no risk of
concurrent change exist (hence no branch is needed).
- the release shall, as with most jelly-tag-libraries, only produce jar
files to be consumed from the maven repo at ibiblio and the repo at
apache. No source or binary distribution will be made.
- once the vote passed, I will simply update changes.xml and
project.xml, tag the files, upload the jar to the Apache, submit a jar
upload to iblio's repo.

I have assembled the following release candidates...
- a site with RC1 version tag:
http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/
- a jar which is the sole outcome of this subproject:
http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar

Please tell me if that's enough to request a vote.

thanks

paul

smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Commented: (JELLY-230) Problem with default namespace in imported scripts

2006-06-14 Thread Paul Libbrecht (JIRA)

[ 
http://issues.apache.org/jira/browse/JELLY-230?page=comments#action_12416139 ] 

Paul Libbrecht commented on JELLY-230:
--

Lukas... replacenamespace is working fine for me.

The following:

?xml version=1.0 encoding=UTF-8?
j:jelly xmlns:j=jelly:core
  xmlns:x=jelly:xmlx:replaceNamespace xmlns:x=jelly:xml toURI= 
fromURI=dummy 

project xmlns=dummy default=jar basedir=. name=test-maven-ant-plugin 
glup/
/project

/x:replaceNamespace/j:jelly

creates me:

project default=jar name=test-maven-ant-plugin 
basedir=.glup/glup/project 

as I expect.

If you get this re-output verbatim, your xml taglib version is wrong... the 
replaceNamespace tag is missing.

Tell us if it helps... I am a bit reluctant to insert back the implicit 
replaceNamespace as it is a normal purist approach to consider it a bug (and 
there's no way to get rid of it).
Would it be too many changes on the maven side ??

paul

 Problem with default namespace in imported scripts
 --

  Key: JELLY-230
  URL: http://issues.apache.org/jira/browse/JELLY-230
  Project: Commons Jelly
 Type: Bug

   Components: core / taglib.core
 Versions: 1.1
  Environment: jelly-1.1-SNAPSHOT
 Reporter: Lukas Theussl
 Assignee: james strachan
 Priority: Critical


 I am trying to build Maven with jelly-1.1-SNAPSHOT from svn trunk because it 
 contains a fix for a regression that has blocked us for a long time, see
 http://jira.codehaus.org/browse/MAVEN-1691 (gee, I wish I'd checked the svn 
 archives earlier!).
 However, even though jelly-1.1-SNAPSHOT solves the above issue, it also leads 
 to a whole bunch of test failures in several of our plugins.
 After some investigation I found that they all turn out to be due to the same 
 cause, an apparent backwards incompatibility introduced in the fix for 
 JELLY-213.
 I am not sure actually if this is a bug or the intended behavior, but it 
 certainly breaks backwards compatibility.
 To illustrate the problem: in the ant plugin we use the following snippet to 
 generate an ant build.xml file from a template:
 j:file name=build.xml prettyPrint=true
   j:import file=templates/build.jelly inherit=true/
 /j:file
 where the template file build.jelly looks like this (simplified):
 j:jelly
   xmlns:ant=jelly:ant
   xmlns:j=jelly:core 
   xmlns=dummy
   project name=${pom.artifactId} default=jar basedir=.
   target name=clean description=Clean up
 delete dir=$${defaulttargetdir}/
 delete dir=$${distdir}/
   /target
   /project
 /j:jelly
 Note the xmlns=dummy namespace declaration which is necessary to 
 distinguish the default namespace of the template script from Maven's default 
 namespace. Now with jelly-1.0, this works as expected, but with the current 
 jelly-1.1-SNAPSHOT, I get:
 project xmlns=dummy name=test-maven-ant-plugin default=jar basedir=.
   target description=Clean up name=clean
 delete dir=${defaulttargetdir}
 /delete
 delete dir=${distdir}
 /delete
   /target
 project
 ie the dummy namespace declaration makes it into the top-level element of the 
 generated file. This makes ant very unhappy when invoked on this build file...

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JELLY-226) Upgrade dom4j and jaxen

2006-06-08 Thread Paul Libbrecht (JIRA)

[ 
http://issues.apache.org/jira/browse/JELLY-226?page=comments#action_12415443 ] 

Paul Libbrecht commented on JELLY-226:
--

Is now committed... looks like i need to wait to see gump take it up.

 Upgrade dom4j and jaxen
 ---

  Key: JELLY-226
  URL: http://issues.apache.org/jira/browse/JELLY-226
  Project: Commons Jelly
 Type: Wish

   Components: core / taglib.core, taglib.jsl, taglib.xml
 Reporter: Lukas Theussl


 I am struggling with upgrading dom4j and jaxen for our upcoming maven-1.1 
 release (see http://jira.codehaus.org/browse/MAVEN-1345 and 
 http://jira.codehaus.org/browse/JAXEN-67 for some chunks of discussion). Part 
 of the problem seems to be some kind of binary incompatibility in project 
 dependencies of jelly. I tried to rebuild jelly with the latest dom4j-1.6.1 
 and jaxen-1.1-beta-8 but failed due to several broken test cases, in 
 particular in the jsl tag library. It would be nice if we had a jelly release 
 with unified dependencies, even though I am not sure it will solve our 
 problem of dropped CDATA sections that I described in JAXEN-67.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (JELLY-231) x:foreach's sort option breaks if empty result

2006-06-08 Thread Paul Libbrecht (JIRA)

x:foreach's sort option breaks if empty result
--

 Key: JELLY-231
 URL: http://issues.apache.org/jira/browse/JELLY-231
 Project: Commons Jelly
Type: Bug

  Components: taglib.xml  
Versions: 1.1
Reporter: Paul Libbrecht


as it says... if you invoke x:foreach with a sort attribute. An 
ArrayIndexOutOfBounds is thrown is the result-set is empty.
This should not be.
paul

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed

2006-06-07 Thread Paul Libbrecht


Gump experts,

Failures in these three tests are due, I think, to old jaxen, indeed 
jaxen 1.1-beta-4 is referenced in many places in

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html
and the other failing gump reports. Explanation for this is the gump 
metadata to be found at:

http://svn.apache.org/repos/asf/gump/metadata/project/jakarta-commons-jelly.xml
which indeed states explicitly jaxen 1.1-beta-8.

Is this gump descriptor automatically generated ?
Using a manually triggered process or every nights ? (it appears the 
first must be true since jaxen 1.1-beta-8 is in the project.xml since 
yesterday).


I've tried:
 maven generate-gump -Dmaven.gump.svn.dir=commons/proper/jelly/trunk
should I upload the result somewhere ?

thanks

paul


development wrote:

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]


Project commons-jelly-tags-html has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-html :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-html-07062006.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html
Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build)
Work ended in a state of : Failed
Elapsed: 13 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html]

CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-0706200
 
6.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1):	Caused an ERROR

[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run

Re: vmbuild.apache.org now available

2006-06-05 Thread Paul Libbrecht


Would that run visual unit tests ??
paul

Brett Porter wrote:

Hi,

Berin has setup a VMWare machine for general build stuff. I have setup 
httpd, java, continuum and maven 2 on there.


Who was interested on working on nightly builds/CI for commons-*?

- Brett




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] [vote] Release commons-jelly-tags-interaction 1.1

2006-06-02 Thread Paul Libbrecht


Well,
Lukas who requested this indicated that anyways he wanted some other 
releases (including the core).
There was one request to get a packed version to chew at before 
voting... which I did not have the time to do. Votes were, otherwise, 
positive.


So, it's not done yet and I'll need till middle of next week at least 
for this.

How does it sound ?

paul

PS: I would prefer, if possible, to update the dom4j dependency (see 
other question).




Arnaud HERITIER wrote:

Hi guys,

 Will you release it ?

Arnaud

On 5/17/06, peter royal [EMAIL PROTECTED] wrote:


 The story seems quite simple so I thought I'd just ask for a vote
 sorry
 if too stressed.
 The interaction jelly tag-library is now ready for release 1.1.
 It has been recently boosted with a finer control on auto-completion,
 and maven console plugin is using it successfully.
 Thanks to give it a try* and provide a vote.
 This vote will last till Friday 12:00 GMT.

 [ ] +1 yes let's release it
 [X] +0 maybe
 [ ] -0 seems not ready
 [ ] -1 no, don't!

I support the release, but don't have time to actually test it.
-pete

--
[EMAIL PROTECTED] - http://fotap.org/~osi




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Upgrade to dom4j 1.6.1 ?

2006-06-02 Thread Paul Libbrecht

I please beg another round of review... or I'll interprete the silence 
as no bother and will do...


paul

Hans Gilde wrote:

+0

If the unit tests pass, I'm inclined to say that the latest version should
be used. But I have not tried it.

-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED] 
Sent: Saturday, May 13, 2006 5:06 PM

To: Jakarta Commons Developers List
Subject: [jelly] Upgrade to dom4j 1.6.1 ?

Hello Jellyers,

After my two test fixes, which had almost nothing to do with dom4j...
I seem to be happily running everything with dom4j 1.6.1.
Can anyone confirm me this ? It's quite radical but it'd help in many  other 
places.
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DONE] Re: Bugzilla-Jira migration

2006-05-16 Thread Paul Libbrecht



Henri Yandell wrote:
Migration is complete; Commons has successfully invaded 
issues.apache.org/jira.


Next up - reflect the change on the website.
Just for your information, it is possible to have readable URLs to Jira 
even though Jira itself doesn't give them.

Among others, a project page is:
   http://issues.apache.org/jira/browse/projectKey
(e.g. http://issues.apache.org/jira/browse/JELLY or 
http://issues.apache.org/jira/browse/IO)

Better use this than the number based things.
Probably there's more such URLs which I think are important if they 
exchanged and presented.


paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Jira projects

2006-05-15 Thread Paul Libbrecht


Sorry Henry,
I suppose this was later than your deletion which I didn't notice...
Note that Jelly doesn't use Bugzilla since ages so the only advantage of 
such an import would be to merge these lost contributions, several of 
which are actually duplicated, all of which are resolved.
The best thing would be to keep it for archive purposes in Bugzilla, I 
think.


paul


Paul Libbrecht wrote:

Henri Yandell wrote:

There are now two projects in Jira, Jelly and Commons JellyImported.
If someone has a moment, it'd be a real help if they could take a look
at the two of these and let me know if JellyImported can be deleted or
if it should have its issues moved into Jelly.

I just didn't find JellyImported.
It's not findable in:
http://issues.apache.org/jira/secure/BrowseProject.jspa

and both:
   http://issues.apache.org/jira/browse/JELLYIMPORTED
   http://issues.apache.org/jira/browse/JellyImported
are not found...
can you maybe give a URL ?

I'll be renaming Jelly to Commons Jelly in a bit.
Project names in Jira are in capital... so renaming to COMMONS-JELLY 
or so would be pretty ugly... and would break all current URLs... but 
if you have to...

Also jakarta only appears once in the project list... why?

paul

-
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-230) Problem with default namespace in imported scripts

2006-05-15 Thread Paul Libbrecht (JIRA)

[ 
http://issues.apache.org/jira/browse/JELLY-230?page=comments#action_12402290 ] 

Paul Libbrecht commented on JELLY-230:
--

I fear that the problem is considered to be backwards compatibility even 
though a normal perspective would be call to it a bug-fix.

Lukas, does the solution replaceNamespace sound doable for you ?
Alternatively, what about having a flag at XMLOutput (which is probably 
instantiated by Maven anyways) to do this?
(it seems pretty equivalent, actually)

As far as I know this has nothing to do with import... or I'd need an extra 
explanation

paul

 Problem with default namespace in imported scripts
 --

  Key: JELLY-230
  URL: http://issues.apache.org/jira/browse/JELLY-230
  Project: Jelly
 Type: Bug

   Components: core / taglib.core
 Versions: 1.1
  Environment: jelly-1.1-SNAPSHOT
 Reporter: Lukas Theussl
 Assignee: james strachan
 Priority: Critical


 I am trying to build Maven with jelly-1.1-SNAPSHOT from svn trunk because it 
 contains a fix for a regression that has blocked us for a long time, see
 http://jira.codehaus.org/browse/MAVEN-1691 (gee, I wish I'd checked the svn 
 archives earlier!).
 However, even though jelly-1.1-SNAPSHOT solves the above issue, it also leads 
 to a whole bunch of test failures in several of our plugins.
 After some investigation I found that they all turn out to be due to the same 
 cause, an apparent backwards incompatibility introduced in the fix for 
 JELLY-213.
 I am not sure actually if this is a bug or the intended behavior, but it 
 certainly breaks backwards compatibility.
 To illustrate the problem: in the ant plugin we use the following snippet to 
 generate an ant build.xml file from a template:
 j:file name=build.xml prettyPrint=true
   j:import file=templates/build.jelly inherit=true/
 /j:file
 where the template file build.jelly looks like this (simplified):
 j:jelly
   xmlns:ant=jelly:ant
   xmlns:j=jelly:core 
   xmlns=dummy
   project name=${pom.artifactId} default=jar basedir=.
   target name=clean description=Clean up
 delete dir=$${defaulttargetdir}/
 delete dir=$${distdir}/
   /target
   /project
 /j:jelly
 Note the xmlns=dummy namespace declaration which is necessary to 
 distinguish the default namespace of the template script from Maven's default 
 namespace. Now with jelly-1.0, this works as expected, but with the current 
 jelly-1.1-SNAPSHOT, I get:
 project xmlns=dummy name=test-maven-ant-plugin default=jar basedir=.
   target description=Clean up name=clean
 delete dir=${defaulttargetdir}
 /delete
 delete dir=${distdir}
 /delete
   /target
 project
 ie the dummy namespace declaration makes it into the top-level element of the 
 generated file. This makes ant very unhappy when invoked on this build file...

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r406083 - /jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly

2006-05-14 Thread Paul Libbrecht

It's a nice question, I don't think it really is and it may be we need a 
layer between Jaxen expressions in jelly and other objects in the context.
Jexl's new version now does more integer types (right?) which happened 
to break a jexl comparison which could not happen against an integer. 
Adding the toString() was the trick...
Maybe we should have jaxen convert more to strings now... or we just let 
people be surprised and add the toString() (as need be, 
integer.toString() is known to be locale dependent so it's a good thing 
for it not to be automatic).


paul

Dion Gillard wrote:

Paul,

if this really is a problem with Jexl, let me know what the issue is and
we'll try to get it fixed.

On 5/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


Author: polx
Date: Sat May 13 05:19:38 2006
New Revision: 406083

URL: http://svn.apache.org/viewcvs?rev=406083view=rev
Log:
Fixed the evil error which had nothing to do with jaxen
but with jexl... the i variable was an integer which
jaxen cannot compare to an attribute value... fixed
by using i = i.toString().
paul

Modified:


jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly 



Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly 


URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly?rev=406083r1=406082r2=406083view=diff 



== 


---
jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly 


(original)
+++
jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly 


Sat May 13 05:19:38 2006
@@ -129,7 +129,8 @@

 test:assert xpath=[EMAIL PROTECTED] = '1']/

-test:assert xpath=@id = $i/
+
j:set var=i value=${i.toString()}/
+
test:assert xpath=@id = $i/

 jsl:applyTemplates/
 /jsl:template



-
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] Jira projects

2006-05-14 Thread Paul Libbrecht


Henri Yandell wrote:

There are now two projects in Jira, Jelly and Commons JellyImported.
If someone has a moment, it'd be a real help if they could take a look
at the two of these and let me know if JellyImported can be deleted or
if it should have its issues moved into Jelly.

I just didn't find JellyImported.
It's not findable in:
http://issues.apache.org/jira/secure/BrowseProject.jspa

and both:
   http://issues.apache.org/jira/browse/JELLYIMPORTED
   http://issues.apache.org/jira/browse/JellyImported
are not found...
can you maybe give a URL ?

I'll be renaming Jelly to Commons Jelly in a bit.
Project names in Jira are in capital... so renaming to COMMONS-JELLY or 
so would be pretty ugly... and would break all current URLs... but if 
you have to...

Also jakarta only appears once in the project list... why?

paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JELLY-230) Problem with default namespace in imported scripts

2006-05-14 Thread Paul Libbrecht (JIRA)

[ 
http://issues.apache.org/jira/browse/JELLY-230?page=comments#action_12402265 ] 

Paul Libbrecht commented on JELLY-230:
--

Gee!! I certainly hope that Jelly acts like this as this is normal XML!

What I realize is that this dummy namespace has had a special treatment for 
maven or within maven and that special treatment means... be renamed to the 
no-namespace, correct ?

I cannot see this without an environment observation of seeing maven around 
in order to decide that such a renaming should happen... or do you ?

paul

 Problem with default namespace in imported scripts
 --

  Key: JELLY-230
  URL: http://issues.apache.org/jira/browse/JELLY-230
  Project: Jelly
 Type: Bug

   Components: core / taglib.core
 Versions: 1.1
  Environment: jelly-1.1-SNAPSHOT
 Reporter: Lukas Theussl
 Assignee: james strachan
 Priority: Critical


 I am trying to build Maven with jelly-1.1-SNAPSHOT from svn trunk because it 
 contains a fix for a regression that has blocked us for a long time, see
 http://jira.codehaus.org/browse/MAVEN-1691 (gee, I wish I'd checked the svn 
 archives earlier!).
 However, even though jelly-1.1-SNAPSHOT solves the above issue, it also leads 
 to a whole bunch of test failures in several of our plugins.
 After some investigation I found that they all turn out to be due to the same 
 cause, an apparent backwards incompatibility introduced in the fix for 
 JELLY-213.
 I am not sure actually if this is a bug or the intended behavior, but it 
 certainly breaks backwards compatibility.
 To illustrate the problem: in the ant plugin we use the following snippet to 
 generate an ant build.xml file from a template:
 j:file name=build.xml prettyPrint=true
   j:import file=templates/build.jelly inherit=true/
 /j:file
 where the template file build.jelly looks like this (simplified):
 j:jelly
   xmlns:ant=jelly:ant
   xmlns:j=jelly:core 
   xmlns=dummy
   project name=${pom.artifactId} default=jar basedir=.
   target name=clean description=Clean up
 delete dir=$${defaulttargetdir}/
 delete dir=$${distdir}/
   /target
   /project
 /j:jelly
 Note the xmlns=dummy namespace declaration which is necessary to 
 distinguish the default namespace of the template script from Maven's default 
 namespace. Now with jelly-1.0, this works as expected, but with the current 
 jelly-1.1-SNAPSHOT, I get:
 project xmlns=dummy name=test-maven-ant-plugin default=jar basedir=.
   target description=Clean up name=clean
 delete dir=${defaulttargetdir}
 /delete
 delete dir=${distdir}
 /delete
   /target
 project
 ie the dummy namespace declaration makes it into the top-level element of the 
 generated file. This makes ant very unhappy when invoked on this build file...

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jelly] Upgrade to dom4j 1.6.1 ?

2006-05-13 Thread Paul Libbrecht


Hello Jellyers,

After my two test fixes, which had almost nothing to do with dom4j...
I seem to be happily running everything with dom4j 1.6.1.
Can anyone confirm me this ? It's quite radical but it'd help in many 
other places.


paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JELLY-187) Wrong composite expression evaluation

2006-05-13 Thread Paul Libbrecht (JIRA)

[ 
http://issues.apache.org/jira/browse/JELLY-187?page=comments#action_12383406 ] 

Paul Libbrecht commented on JELLY-187:
--

I have an issue with this patch... Namely the undocumented following usage:

  $${a.b.c} does output ${a.b.c}

at least I use this to generate ant files and I just saw this is used by the 
ant maven plugin, so presumably by others as well.
I''ve added such a test in TestExpressions.

Any better solution here ?

paul

 Wrong composite expression evaluation
 -

  Key: JELLY-187
  URL: http://issues.apache.org/jira/browse/JELLY-187
  Project: Jelly
 Type: Bug

   Components: core / taglib.core
 Versions: 1.0-RC1, 1.0, 1.0-RC2
 Reporter: dion gillard
  Fix For: 1.0.1
  Attachments: JELLY-187.patch

 I have tried to add the following test consdtion in method testExpresssions()
 from org.apache.commons.jelly.expression.TestExpressions.java:
 assertExpression($type${topping}, $typecheese);
 but it fails saying that it should be:
 assertExpression($type${topping}, typecheese);

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (JELLY-218) Output is lost when using text attribute of core:parse tag

2006-05-13 Thread Paul Libbrecht (JIRA)

 [ http://issues.apache.org/jira/browse/JELLY-218?page=all ]
 
Paul Libbrecht resolved JELLY-218:
--

Fix Version: 1.1
 Resolution: Fixed
  Assign To: Paul Libbrecht

Fixed in subversion, please test.
If you have some time for a contribution, please submit a unit-test with this, 
at least, as test-case. thanks

paul

 Output is lost when using text attribute of core:parse tag
 --

  Key: JELLY-218
  URL: http://issues.apache.org/jira/browse/JELLY-218
  Project: Jelly
 Type: Bug

   Components: core / taglib.core
 Versions: 1.0-beta-4, 1.1-beta-1, 1.0-beta-5
  Environment: Windows XP, JDK1.5, Ant 1.6.5
 Reporter: Tony Robertson
 Assignee: Paul Libbrecht
  Fix For: 1.1


 When using the text attribute of the core:parse tag, the text is parsed but 
 then the result is lost. If a var attribute is also used, it gets a null 
 value. Otherwise a null pointer exception is thrown when the doTag method 
 trys to invoke the script.
 (note, the equivalent problem when using the tag body as the XML source was 
 fixed by polx at revision 135985, but not using the text attribute).

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jelly] Trying to understand TestJSL.testExample1

2006-05-11 Thread Paul Libbrecht


Hi,

in the efforts of upgrading to dom4j-1.6, I've bumped into the following 
weird behaviour which may be my too small knowledge of JSL:


TestJSL.testExample1 tests the output of the jelly file:
   src/test/org/apache/commons/jelly/jsl/example.jelly
and then tries to assert that the first resulting small element should 
start with James Elson which is only contained in an attribute in the 
source document whereas small elements, in this jsl stylesheet are 
output with the template:

 jsl:template match=*
   smalljsl:applyTemplates//small
 /jsl:template
i.e. only matching elements, not any node...
Can someone tell me whether this test is reasonable ?

The test is running with dom4j 1.5.2 (that tastes like a bug!)
This assert is the only breakage I have in jsl with dom4j 1.6.1.

thanks for hints

paul

PS: I managed already with dom4j-1.5.2...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] taglibs lead distribution ?

2006-05-11 Thread Paul Libbrecht


Hans,

I think the idea of a lead is to put a name on components in jira. It's 
not about doing a release soon or anything such. Having a (living 
person) name on components makes it a bit easier to distribute 
responsibility. Currently, there are many unassigned issues, or issues 
assigned to James, which is the same, it would be easier that a single 
person, per component, living on the list, would feel concerned by 
received such a bug and indicate when, whether he/she could fix it, or 
whether it should be delegated.


paul

Hans Gilde wrote:

I can do bug fixes and such and I'm definitely in favor of cleaning up the Jira 
assignments. If you'd like to assign me some stuff, I'll fix it. But I'm not in 
a position to really lead anything at the moment.

-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 10, 2006 4:17 AM

To: Jakarta Commons Developers List
Subject: [jelly] taglibs lead distribution ?


Hi,


I was fiddling with Jira jelly project administration because 
interaction didn't have a component and realized that some components 
have been assigned to dion... which is good.
I'd like it if we could distribute the lead of all components, also so 
that James Strachan is not anymore the default assignee!!


I'd be willing to take over xml and swing tag-libs... maybe some others.
Would anyone wish those ? Would anyone be ready to take over others ?
Some taglibs are not in urgent need but some really have a need and this 
way we could react better to requests which keep coming as jelly, even 
though it tastes unfinished, still has a good attraction, I feel.


paul
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JELLY-226) Upgrade dom4j and jaxen

2006-05-11 Thread Paul Libbrecht (JIRA)

[ 
http://issues.apache.org/jira/browse/JELLY-226?page=comments#action_12379153 ] 

Paul Libbrecht commented on JELLY-226:
--

Well... I have now made a few tests and, up to two lines of fixes in 
jelly-tags-jsl, I seem to be running fine all tag-libs with dom4j-1.6.1... 
I would be ready to consider upgrade to dom4j 1.6.1.
paul

 Upgrade dom4j and jaxen
 ---

  Key: JELLY-226
  URL: http://issues.apache.org/jira/browse/JELLY-226
  Project: Jelly
 Type: Wish

   Components: core / taglib.core, taglib.jsl, taglib.xml
 Reporter: Lukas Theussl


 I am struggling with upgrading dom4j and jaxen for our upcoming maven-1.1 
 release (see http://jira.codehaus.org/browse/MAVEN-1345 and 
 http://jira.codehaus.org/browse/JAXEN-67 for some chunks of discussion). Part 
 of the problem seems to be some kind of binary incompatibility in project 
 dependencies of jelly. I tried to rebuild jelly with the latest dom4j-1.6.1 
 and jaxen-1.1-beta-8 but failed due to several broken test cases, in 
 particular in the jsl tag library. It would be nice if we had a jelly release 
 with unified dependencies, even though I am not sure it will solve our 
 problem of dropped CDATA sections that I described in JAXEN-67.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JELLY-175) patch for jelly-tags-interaction

 [ http://issues.apache.org/jira/browse/JELLY-175?page=all ]

Paul Libbrecht updated JELLY-175:
-

  Component: taglib.interaction
Fix Version: 1.1
Version: 1.0
  Assign To: Paul Libbrecht

Fixed versions component.

 patch for jelly-tags-interaction
 

  Key: JELLY-175
  URL: http://issues.apache.org/jira/browse/JELLY-175
  Project: Jelly
 Type: Improvement

   Components: taglib.interaction
 Versions: 1.0
  Environment: I've tested this in windows with and without cygwin.
 Reporter: Ryan Christanson
 Assignee: Paul Libbrecht
 Priority: Minor
  Fix For: 1.1
  Attachments: interaction.patch, patch.txt

 I've attached a patch to the commons-jelly-tags-interaction jar. This
 patch makes it so the interaction task will try to use jline:
 http://jline.sourceforge.net/
 Jline makes it so a java console will have tab completion, and
 history, and other goodies.
 This is great, because the maven-console plugin uses the
 commons-jelly-tags-interaction jar. So if you update the
 commons-jelly-tags-interaction jar, and then tell the maven console
 plugin to use the new jar, then your maven console will have history,
 and tab completion.
 I've set it up to remember all of the commands typed in any console,
 further it uses that history as the tab completion source - so you can
 tab complete past commands.
 I've tested this in windows and it works great, but in windows with
 cygwin, it doesn't do the fancy completion, but still works.
 By the way, in windows, jline's lib doesn't support arrows for
 history, so use CONTROL+P and CONTROL+N.
 Its possible that there might be a better way to integrate jline into
 this lib, i've just done what looked like the quickest way to get it
 working so my maven console would have history and tab completion.
 Maybe this feature could be enabled with a tag attribute?

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JELLY-229) Add list of possible completions to jelly-tags-interaction

 [ http://issues.apache.org/jira/browse/JELLY-229?page=all ]

Paul Libbrecht updated JELLY-229:
-

  Component: taglib.interaction
Fix Version: 1.1
 (was: 1.1-beta-1)
Version: 1.0

Fixed components and versions.

 Add list of possible completions to jelly-tags-interaction
 --

  Key: JELLY-229
  URL: http://issues.apache.org/jira/browse/JELLY-229
  Project: Jelly
 Type: New Feature

   Components: taglib.interaction
 Versions: 1.0
  Environment: Linux FC3, jdk-14.2_10, Maven-1.1-beta-3-SNAPSHOT
 Reporter: Lukas Theussl
 Assignee: Paul Libbrecht
  Fix For: 1.1
  Attachments: JELLY-229.patch

 This is a follow-up of JELLY-175. I added a method setCompletor(list) 
 allowing to set a list of strings that is used by jline for tab completion. 
 Use it like: i:ask completor=${list} answer=a/. The list of 
 tab-completion strings is added to the history list, ie new goals typed in 
 console mode will always be tab-completed afterwards.
 Please note that I have bumped the jline dependency to the latest 0.9.5. This 
 is not on ibiblio yet, I have created an upload request ( 
 http://jira.codehaus.org/browse/MAVENUPLOAD-883 ), if it is not found, you 
 will have to put the jline-0.9.5.jar into your local repo by hand.
 To test it: I have deployed a snapshot of the maven 1 console plugin:
 maven plugin:download 
 -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
  -DgroupId=maven -DartifactId=maven-console-plugin -Dversion=1.2-SNAPSHOT
 The default value for the completor list is 
 clean,java:compile,jar,test,xdoc,site,quit,help, but you can define your 
 own custom list using the maven.console.completor.goals property.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (JELLY-175) patch for jelly-tags-interaction

 [ http://issues.apache.org/jira/browse/JELLY-175?page=all ]
 
Paul Libbrecht resolved JELLY-175:
--

Resolution: Fixed

This in the current version about to be released (I think).
paul

 patch for jelly-tags-interaction
 

  Key: JELLY-175
  URL: http://issues.apache.org/jira/browse/JELLY-175
  Project: Jelly
 Type: Improvement

   Components: taglib.interaction
 Versions: 1.0
  Environment: I've tested this in windows with and without cygwin.
 Reporter: Ryan Christanson
 Assignee: Paul Libbrecht
 Priority: Minor
  Fix For: 1.1
  Attachments: interaction.patch, patch.txt

 I've attached a patch to the commons-jelly-tags-interaction jar. This
 patch makes it so the interaction task will try to use jline:
 http://jline.sourceforge.net/
 Jline makes it so a java console will have tab completion, and
 history, and other goodies.
 This is great, because the maven-console plugin uses the
 commons-jelly-tags-interaction jar. So if you update the
 commons-jelly-tags-interaction jar, and then tell the maven console
 plugin to use the new jar, then your maven console will have history,
 and tab completion.
 I've set it up to remember all of the commands typed in any console,
 further it uses that history as the tab completion source - so you can
 tab complete past commands.
 I've tested this in windows and it works great, but in windows with
 cygwin, it doesn't do the fancy completion, but still works.
 By the way, in windows, jline's lib doesn't support arrows for
 history, so use CONTROL+P and CONTROL+N.
 Its possible that there might be a better way to integrate jline into
 this lib, i've just done what looked like the quickest way to get it
 working so my maven console would have history and tab completion.
 Maybe this feature could be enabled with a tag attribute?

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JELLY-229) Add list of possible completions to jelly-tags-interaction

[ 
http://issues.apache.org/jira/browse/JELLY-229?page=comments#action_12378850 ] 

Paul Libbrecht commented on JELLY-229:
--

I changed the question to born before the 20th century ;-).

For release to happen is just to get a vote on commons-dev which I opened 
yesterday and expect to close on Friday 12:00 GMT.
Is that ok for you ?
paul

 Add list of possible completions to jelly-tags-interaction
 --

  Key: JELLY-229
  URL: http://issues.apache.org/jira/browse/JELLY-229
  Project: Jelly
 Type: New Feature

   Components: taglib.interaction
 Versions: 1.0
  Environment: Linux FC3, jdk-14.2_10, Maven-1.1-beta-3-SNAPSHOT
 Reporter: Lukas Theussl
 Assignee: Paul Libbrecht
  Fix For: 1.1
  Attachments: JELLY-229.patch

 This is a follow-up of JELLY-175. I added a method setCompletor(list) 
 allowing to set a list of strings that is used by jline for tab completion. 
 Use it like: i:ask completor=${list} answer=a/. The list of 
 tab-completion strings is added to the history list, ie new goals typed in 
 console mode will always be tab-completed afterwards.
 Please note that I have bumped the jline dependency to the latest 0.9.5. This 
 is not on ibiblio yet, I have created an upload request ( 
 http://jira.codehaus.org/browse/MAVENUPLOAD-883 ), if it is not found, you 
 will have to put the jline-0.9.5.jar into your local repo by hand.
 To test it: I have deployed a snapshot of the maven 1 console plugin:
 maven plugin:download 
 -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
  -DgroupId=maven -DartifactId=maven-console-plugin -Dversion=1.2-SNAPSHOT
 The default value for the completor list is 
 clean,java:compile,jar,test,xdoc,site,quit,help, but you can define your 
 own custom list using the maven.console.completor.goals property.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JELLY-226) Upgrade dom4j and jaxen