Re: Jakarta Commons Structure rehashed

[Mark R. Diggory]

I tend to agree. I only work with a few commons components at a time. 
And when using something like Eclipse one can checkout multiple projects 
 by selecting them all. its not that big a deal. Plus from a management 
standpoint, the component is the atomic unit of the commons, organizing 
around that is logical.

+1 on A
-Mark
David Graham wrote:
Option B doesn't make a whole lot of sense to me.  Most people are
interested in only a few commons projects so each having their own trunk,
tags, and branches makes sense.  Struts lays out its subprojects using
Option A:
http://svn.apache.org/viewcvs.cgi/struts/
David
--- Tim O'Brien <[EMAIL PROTECTED]> wrote:

I don't think we ever settled this question. 

Which SVN structure are we interested in?
** Option A:
jakarta/
   commons/
   digester/
   trunk/
   tags/
   branches/
   beanutils/
   trunk/
   tags/
   branches/
OR 

** Option B:
jakarta/
   commons/
   trunk/
   digester/
   beanutils/
   tags/
   digester/
   beanutils/
   branches/
   digester/
   beanutils/


		
__ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32625] - [lang] Can't subclass EqualsBuilder because isEquals is private

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32625


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-18 04:45 ---
In CVS, so fixed.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Commons Mapper: scope/roadmap?

[Max Rudman]

On Dec 17, 2004, at 8:52 PM, David Graham wrote:
There aren't any reusable implementations that I can think of.  What do
you picture the Hibernate mapper implementation looking like?
Well, I am not too familiar with other O/R implementations but at least 
in Hibernate you don't need a separate Data Access Object (DAO) 
implementation for each value object. Everything needed to persist and 
load Person is captured in Person.hbm.xml mapping file.

What I have in mind for Hibernate implementation is HibernateMapper 
class which will hold on to Hibernate Session object and Class of the 
entity being persisted. HibernateMapperFactory then would simply pass 
through entity class to the Mapper so it can in turn use it in its 
calls to Hibernate Session. It would look something like this:

public class HibernateMapper implements Mapper {
  private net.sf.hibernate.Session session;
  private Class type;
  public HibernateMapper(Session session, Class type) {
this.session = session;
this.type = type;
  }
  public Object findByUniqueId(Object id) {
return session.get(type, id);
  }
  .
}
This is probably very oversimplified and there is a fair amount of 
"housekeeping" code; hence, the value of providing an implementation as 
part of the Mapper project instead of forcing users to re-invent the 
wheel so to speak.

In addition, we could provide an implementation which works with Spring 
Framework, for example, which is an IoC container I am very fond of. 
That way, the whole MapperFactory configuration can be done out of XML 
config files and provided to business logic classes in the "Injection 
of Dependency" manner. As a bonus, Spring integrates with Hibernate to 
provide automatic transaction management and such.

I imagine something similar can be done for other O/R frameworks; I am 
just not familiar enough with them to give you more details.

Mapper really saved me on one project where we designed a new db schema
and wrote a bunch of code to access it and then mgmt. decided to use 
the
old schema at the last minute.  All I had to do was implement the 
mappers
differently and the rest of the app. never changed.
I agree, O/R tools are great but being able to switch to a different DB 
schema is a virtue of the O/R mapping tool itself not the abstraction 
API like Mapper. In other words, it seems to me I could have achieved 
the same result by using Hibernate directly as opposed to hard-coding 
DB schema in JDBC calls. If I understood the project's goal correctly, 
it is to abstract various O/R implementations in a manner similar to 
how Commons Logging abstracts various Logging implementations.

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

RE: [lang] 2.1...

[Gary Gregory]

"Sorry for the silence from me. As I've probably said a million times,
baby happened."

Congratulations!

"Gary seems to have taken care of
http://issues.apache.org/bugzilla/show_bug.cgi?id=32625. Is it ready
for closure Gary? Despite Matt Blum's comment on a work-around, it
still sounds like a fine change to the library."

The change has been in CVS for a while, so we are good on that one.

Gary

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

[lang] 2.1...

[Henri Yandell]

Sorry for the silence from me. As I've probably said a million times,
baby happened.

I'm full of coding energy, or perhaps the need to 'have coded' that
leads to coding happening and looking to direct some of it to Lang
2.1.

Looking at the wiki and bugzilla, we were nearly there as far as I
recall. Not a lot has cropped up in the 2 months or so that have
passed, couple of bugs I've easily closed out and a couple of trickier
ones.

Gary seems to have taken care of
http://issues.apache.org/bugzilla/show_bug.cgi?id=32625. Is it ready
for closure Gary? Despite Matt Blum's comment on a work-around, it
still sounds like a fine change to the library.

The only other new bug is a note on incorrect javadoc and should be an
easy one: http://issues.apache.org/bugzilla/show_bug.cgi?id=32619.

Stephen listed the following as smelling:

---
1)
- ArrayUtils.lastIndex()
Gets the last valid index of an array. Surely users would just call
getLength() - 1?

2)
- ClassUtils.CLASS_NAME_COMPARATOR
- ClassUtils.PACKAGE_NAME_COMPARATOR
Although potentially useful, they seem quite specific. What about comparing
packages using Class objects? (I've never used a Package object in my work)
Or comparing just the short name of a class?

3)
- NotImplementedException
This now implements Nestable, with a lot of extra methods. None of the other
exception classes in the main package have been changed. We should revert
this change, or find a lighter weight solution that works with
ExceptionUtils.

4)
- Validate.allElementsOfClass
Should rename to allElementsOfType, and use instanceof style check, not
class equals style check

Still TODO:
5)
- WordUtils
Capitalize with separator methods need to define null handling for delimiter
list, and better javadoc for two of the three methods

6)
- time.DurationFormatUtils (complete?)
7)
- time.StopWatch (complete?)
8)
- text subpackage (not in 2.1)
-

I think we were all agreed on 8. 6+7 I'm open to ideas on
improvements, I think they were complete but need to look again to
convince myself.

3, 4 and 5 all look to be quite agreeable and so just need to be done.

1 and 2 look to be "justify thy existence" questions to the relevant
features. So we need to decide whether we think they should go or not.

1 seems to be a classic "it's semantically better" argument, whereas 2
seems to be a "it's not generic enough". Usually we keep code with
semantically better arguments and drop not-generic enough code I
think, so 1 would stay and 2 would be rm'd. I'm not tied to either
though, so ymmv.

I've clovered and uploaded to: 
http://www.apache.org/~bayard/commons-lang-2.1/clover/

Thoughts?

Hen

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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

Paulo Gaspar wrote:

> I don't think we are discounting the value of the original proposal but
> simply questioning if it should be implemented exactly as proposed - a
> process you should be familiar with since it is quite common about
> proposals presented at Apache projects.

David Graham wrote:

> What you're seeing is the natural result of design conversations held
> outside of the mailing list.  No one here had the benefit of participating
> in the localized logging design so naturally we're asking questions and
> making suggestions.

robert burrell donkin wrote:


> i'd much rather that people speak up and voice their concerns now when
> we can actually acknowledge them and (at the very least) document
> reasons for rejecting.

As I said to Simon, I have no issue with any of the constructive debate
surrounding the proposal.  I firmly believe that the best solutions come
from constructive pushing within the solution space to satisfy competing
interests, and are a synthesis derived from the creative input of multiple
people.

However, I also saw some comments that came across to me as unnecessarily
negative, and I don't want to discourage people from trying to innovate
here.

Putting this another way: let's have the debates, but at the same time, make
sure that we encourage participation in the process while we do so.  Not
everyone will have what appears to be Richard's excellent attitude.

--- Noel


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

Simon Kitching wrote:

> Noel J. Bergman wrote:
> > It disturbs me that what seems to me to be a reasonable and small set of
> > requirements --- along with what appears to have been considerable
> > forethought based upon real world issues, and experiences supporting
many
> > developers --- appears to be discounted a bit too out of hand.  I hope
my
> > perception is wrong.

> The question is whether the implementation of those requirements is a
> good fit for commons-logging or not. Commons-logging is used in many
> environments that the Websphere team may *not* be interested in.

Agreed.  And I have absolutely no issue with any of the constructive debate
that has occured.  But I also saw some comments that came across to me as
dismissive, and I don't want to discourage people from trying to innovate
here.

> I will dispute localisation of log messages if this:

My thought is to have this new layer use a factory pattern to manufacture
the logging string from the parameters.  That would introduce capability and
flexibility without mandating any particular mechanism or overhead, and
would remove the need to impose an i18n requirement on the underlying
logging implementation.

> I've been convinced by the arguments put forward in this thread that
> explicit enter/exit methods taking class+method strings should not
> be encouraged

Actually, I agree.  I'd prefer to see that semantic state encoded in the log
message, which I feel is much cleaner.

--- Noel


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

> Aspect oriented tools obsolete the need for this kind of logging method.

We've been able to implement this sort of thing for years using "OpenJava".
You're all using the OpenJava pre-processor, right?  ;-)

Translation: I'll accept this reasoning when AOP tools are part of every
JDK.  Which should be 3-5 years after it is released by Sun.

--- Noel


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

Richard Sitze wrote:

> As a real example, the axis community uses globalized messages.

A lot of products do, as I see on a regular basis, so I definitely support
your interest in this feature.

However, I view logging as separate from content generation.  I'd like to
see the mechanism pluggable.  That could be done by providing a message
factory to the logging layer, so that it does the lookup rather than your
example:

> log.error(Message.getMessage("MSGID", new String { arg1, ..., argN }));

Doing so would still permit your facade:

  log.error(this.getClass(), "thisMethodName", "MSGID", new String {...});

but the factory that the logger uses to construct the message would be
pluggable and distinct from the role of bridging to an underlying log
mechanism.

And I'd like to see a Java 5 versiion of this interface that takes advantage
of variable argument lists, rather than the String[].

--- Noel


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

cvs commit: jakarta-commons/lang project.properties

[bayard]

bayard  2004/12/17 19:06:35

  Modified:lang project.properties
  Log:
  override so it uses the latest clover
  
  Revision  ChangesPath
  1.14  +5 -2  jakarta-commons/lang/project.properties
  
  Index: project.properties
  ===
  RCS file: /home/cvs/jakarta-commons/lang/project.properties,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- project.properties21 Oct 2004 00:36:37 -  1.13
  +++ project.properties18 Dec 2004 03:06:35 -  1.14
  @@ -43,4 +43,7 @@
   # Specifies the source version for the Java compiler.
   # Corresponds to the source attribute for the ant javac task. 
   # Valid values are 1.3, 1.4, 1.5. 
  -maven.compile.source = 1.3
  \ No newline at end of file
  +maven.compile.source = 1.3
  +
  +maven.jar.override=on
  +maven.jar.clover=1.3.2
  
  
  

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

[Jakarta Commons Wiki] Updated: Lang

[commons-dev]

   Date: 2004-12-17T18:58:39
   Editor: HenriYandell <[EMAIL PROTECTED]>
   Wiki: Jakarta Commons Wiki
   Page: Lang
   URL: http://wiki.apache.org/jakarta-commons/Lang

   no comment

Change Log:

--
@@ -15,6 +15,7 @@
  Development plan for 2.1 
 
  1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=30855 30855] Extra 
constructor for EqualsBuilder.
+ 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=32625 32625][lang] 
Can't subclass EqualsBuilder because isEquals is private - '''DONE?'''
 
  Seeking opinions 
 
@@ -69,3 +70,4 @@
  1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=22489 22489]
[lang]patch] StringUtils.isAsciiPrintable() - '''DONE'''
  1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=26646 26646][lang] 
FastDateFormat.getDateInstance(int, Locale) always uses the pattern from the 
first invocation - '''DONE'''
  1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=31181 31181]  
FastDateFormat year bug - '''DONE'''
+ 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=32198 32198]
[lang] Error in JavaDoc for StringUtils.chomp(String, String) - '''DONE'''

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

DO NOT REPLY [Bug 32364] - [lang] HashCodeBuilder failed to generate unique hashcode

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32364


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2004-12-18 03:51 ---
Stephen's point seems to nullify this as being a bug. Marking as INVALID (sorry
it's such a cold term Bruce).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Commons Mapper: scope/roadmap?

[Max Rudman]

Specifically, I'm not exactly planning on a Query-by-Example API, but 
rather a dynamic SQL statement builder API (also insert, update, 
delete, etc.).  I run into this problem all the time where the user is 
specifying what they'd like to search for, and so you need to build a 
SQL statement on-the-fly.
Yes, dynamic SQL/OQL generation is exactly what I am talking about. 
Perhaps I chose Query-By-Example terminology poorly in that it's not 
QBE itself but rather the API that enables QBE-type functionality.


If you're curious, take a look at the DynamicSqlSelectStatment 
interface.
I looked at your code (DynamicSqlSelectStatement) and it looks very 
much like something I had built (I call it QueryBuilder). Do you plan 
support for functions, GROUP BY and ORDER BY clauses? You might have 
that in the rest of your API as I didn't look thoroughly.

Let me know if you have any comments, questions, etc!
So, are you planning a persistence (O/R mapping) layer like Apache 
ObjectBridge and Hibernate or an abstraction API like Mapper?

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

DO NOT REPLY [Bug 32198] - [lang] Error in JavaDoc for StringUtils.chomp(String, String)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32198


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-18 03:48 ---
Yep, unit test has it correctly, so just a bug in the javadoc. Fixed.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java

[bayard]

bayard  2004/12/17 18:48:01

  Modified:lang/src/java/org/apache/commons/lang StringUtils.java
  Log:
  Bug in javadoc example as described in Bugzilla entry 32198.
  
  PR: 32198
  Submitted by: Ronald Wildenberg
  
  Revision  ChangesPath
  1.137 +2 -2  
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
  
  Index: StringUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
  retrieving revision 1.136
  retrieving revision 1.137
  diff -u -r1.136 -r1.137
  --- StringUtils.java  8 Oct 2004 00:11:22 -   1.136
  +++ StringUtils.java  18 Dec 2004 02:48:01 -  1.137
  @@ -3233,7 +3233,7 @@
* StringUtils.chomp("foobar", "bar") = "foo"
* StringUtils.chomp("foobar", "baz") = "foobar"
* StringUtils.chomp("foo", "foo")= ""
  - * StringUtils.chomp("foo ", "foo")   = "foo"
  + * StringUtils.chomp("foo ", "foo")   = "foo "
* StringUtils.chomp(" foo", "foo")   = " "
* StringUtils.chomp("foo", "f")  = "foo"
* StringUtils.chomp("foo", "")   = "foo"
  
  
  

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

Re: Commons Mapper: scope/roadmap?

[David Graham]

There aren't any reusable implementations that I can think of.  What do
you picture the Hibernate mapper implementation looking like?

The idea is that your app talks to the Mapper API which is implemented as
sql, hibernate, etc.  However, each implementation will be very specific
to your app.  For example you might have a SqlPersonMapper that knows how
to work with your Person db table using JDBC and then switch to using an
HqlPersonMapper without the app. knowing because it uses the Mapper
interface (or an extended PersonMapper sub-interface).

Mapper really saved me on one project where we designed a new db schema
and wrote a bunch of code to access it and then mgmt. decided to use the
old schema at the last minute.  All I had to do was implement the mappers
differently and the rest of the app. never changed.

David

--- Max Rudman <[EMAIL PROTECTED]> wrote:

> I've just discovered Commons Mapper project and would like to 
> contribute. I built my own abstraction layer for Hibernate but would 
> love to move to Mapper instead. I looked through current documentation 
> and have a couple of questions.
> 
> 1) Are specific implementations within the scope of this project? You 
> mention several data mapping technologies (such as Hibernate, iBATIS, 
> etc.) in project overview but I saw no specific implementations in the 
> JavaDocs API. As I said, I have experience with Hibernate and would 
> like to contribute in providing Hibernate Mapper implementation (if 
> this is something that needs to be done).
> 
> 2) Is query API something you envision being part of this package? 
> Specifically, a Query-By-Example API which I found to be very useful in 
> enterprise application development where one often needs to have the 
> ability to search for records with flexible (dynamic) WHERE clause. 
> Hibernate package provides such an API but obviously it is specific to 
> their implementation and it would be nice to have the abstraction layer 
> against that functionality as well.
> 
> This is my first time inquiring about contributing to Jakarta Commons 
> so I apologize in advance if I am doing something inappropriate. I did 
> search through both user and dev mailing list archives but couldn't 
> find any information on the topics above.
> 
> Thanks in advance,
> 
> Max
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 




__ 
Do you Yahoo!? 
Send a seasonal email greeting and help others. Do good. 
http://celebrity.mail.yahoo.com

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

Re: AW: AW: [proposal] avoiding jar version nightmares

[Martin Cooper]

On Sat, 18 Dec 2004 00:15:28 +0100, Oliver Zeigermann
<[EMAIL PROTECTED]> wrote:
> On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> > This would be really a funny thing, but how could we replace the classloader
> > of a given application with a custom one?
> 
> Right. Impossible :(
> 
> > But what about a tool that decompiles all the product jars, changes the
> > package structure and the import statements and repacks this into a new jar?
> > ;-)
> > Might be a megaseller...
> 
> No need to decompile. Libs like BCEL or ASM can do this for us. Other
> than that cool stuff :)
> 
> This would need information which part of the software want which version!
> However, it would be very hard to debug if the tool had any bugs in
> it. But of course it would not ;)
> 
> When is founding time for the company?

I think you're too late:

http://forehead.werken.com/

--
Martin Cooper


> Oliver
> 
> -
> 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: Commons Mapper: scope/roadmap?

[Matt Sgarlata]

I never noticed Mapper before... interesting.  Actually I will be 
tackling some of the same problems once I get Morph out the door 
(morph.sourceforge.net).  It will be a separate project focused on DB 
interaction but I haven't thought of a name yet (I'm calling it 
"Persistence" for now, but that's too generic).

Specifically, I'm not exactly planning on a Query-by-Example API, but 
rather a dynamic SQL statement builder API (also insert, update, delete, 
etc.).  I run into this problem all the time where the user is 
specifying what they'd like to search for, and so you need to build a 
SQL statement on-the-fly.  I think we can do better than straight String 
concatenation :)  I already wrote something similar at my old firm (it 
supported both SQL and HQL) that worked great in production systems, but 
it is not open source.  So I'm starting again, this time open source, 
and whatever I come up with will be almost like a version 2.0 once its 
version 1.0 comes out.

You can download the source I've written so far from here:
http://www.crystalcognition.com/sgarlatm/persistence.zip
If you're curious, take a look at the DynamicSqlSelectStatment interface.
Let me know if you have any comments, questions, etc!
Matt
Max Rudman wrote:
I've just discovered Commons Mapper project and would like to 
contribute. I built my own abstraction layer for Hibernate but would 
love to move to Mapper instead. I looked through current documentation 
and have a couple of questions.

1) Are specific implementations within the scope of this project? You 
mention several data mapping technologies (such as Hibernate, iBATIS, 
etc.) in project overview but I saw no specific implementations in the 
JavaDocs API. As I said, I have experience with Hibernate and would like 
to contribute in providing Hibernate Mapper implementation (if this is 
something that needs to be done).

2) Is query API something you envision being part of this package? 
Specifically, a Query-By-Example API which I found to be very useful in 
enterprise application development where one often needs to have the 
ability to search for records with flexible (dynamic) WHERE clause. 
Hibernate package provides such an API but obviously it is specific to 
their implementation and it would be nice to have the abstraction layer 
against that functionality as well.

This is my first time inquiring about contributing to Jakarta Commons so 
I apologize in advance if I am doing something inappropriate. I did 
search through both user and dev mailing list archives but couldn't find 
any information on the topics above.

Thanks in advance,
Max

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

DO NOT REPLY [Bug 31614] - [daemon][PATCH] Make jsvc delete pid file on daemon exit

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31614





--- Additional Comments From [EMAIL PROTECTED]  2004-12-18 01:16 ---
Is there any hope of getting this patch integrated?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 31613] - [daemon][PATCH] Update Mac support in jsvc

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31613





--- Additional Comments From [EMAIL PROTECTED]  2004-12-18 01:15 ---
Is there any hope of getting this patch integrated?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: AW: AW: [proposal] avoiding jar version nightmares

[Matt Sgarlata]

This may work, but does BCEL require the use of its own custom 
classloader also?

This seems to me that this isn't just a problem with commons; it is a 
problem with Java itself that .NET already has a very nice solution for. 
 I'm wondering if this isn't something that should be taken care of at 
the JVM level i.e. - in Java 1.6.  The obvious solution seems to be that 
we need to fix classloaders.  They're already a huge nightmare in EJB 
containers.

How do we go about petitioning Sun for something like this?
Matt
Oliver Zeigermann wrote:
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
This would be really a funny thing, but how could we replace the classloader
of a given application with a custom one?

Right. Impossible :(

But what about a tool that decompiles all the product jars, changes the
package structure and the import statements and repacks this into a new jar?
;-)
Might be a megaseller...

No need to decompile. Libs like BCEL or ASM can do this for us. Other
than that cool stuff :)
This would need information which part of the software want which version! 
However, it would be very hard to debug if the tool had any bugs in
it. But of course it would not ;)

When is founding time for the company?
Oliver

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

DO NOT REPLY [Bug 32761] New: - [IO] FilenameFilter that uses regular expressions (upload)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32761

   Summary: [IO] FilenameFilter that uses regular expressions
(upload)
   Product: Commons
   Version: unspecified
  Platform: All
OS/Version: Windows XP
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: IO
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I was in need of a FilenameFilter that observed case-sensetivity and couldn't
find anything in the existing commons-io library to meet this requirement. So,
I've thrown together RegexFileFilter and an accompanying unit test to fill the
void. Please add/apply to commons-io as necessary.

-sp

I don't see a way to attach files so heres the cut-n-paste:


/*
 * Copyright 2002-2004 The Apache Software Foundation.
 * 
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * 
 *  http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.apache.commons.io.filefilter;

import java.io.File;
import java.io.IOException;

import org.apache.commons.io.filefilter.AbstractFileFilter;
import org.apache.regexp.RE;
import org.apache.regexp.RESyntaxException;

/**
 * Filters files based on a regular expression that is matched against the 
 * entire filename (including drive, path, and name). Of particular note about
 * this filter is the ability to express case-sensetivity. 
 *  
 * 
 * For example, to retrieve and print all files that contain the string
 * "xyz" in the current directory, the regular expression 
 * ".*xyz.*" can be used:
 *
 * 
 * File dir = new File(".");
 * String[] files = dir.list(new RegexFileFilter(".*xyz.*", true));
 * for (int i = 0; i < files.length; i++) {
 * System.out.println(files[i]);
 * }
 * 
 * 
 * To match using case-insensetivity, 
 * new RegexFileFilter(".*xyz.*", false) would be appropriate.
 * 
 * @author Semir Patel
 */
public class RegexFileFilter extends AbstractFileFilter {

//--
// Fields
//--

/** 
 * Regular expression matcher. 
 */
private RE regExp;

//--
// Constructors
//--

/**
 * Creates a file filter that applies a regular expression to the entire
 * path + name of a file's absolute location.
 * 
 * @param regExp Regular expression to match.
 * @param matchCase Set to true to match using case sensetivity, false 
 *otherwise.
 * @throws RESyntaxException if the regular expression is invalid.
 */
public RegexFileFilter(String regExp, boolean matchCase)
throws RESyntaxException {

this.regExp = new RE(regExp, 
matchCase ? RE.MATCH_NORMAL: RE.MATCH_CASEINDEPENDENT);
}

//--
// Overrides AbstractFileFilter
//--

/**
 * Accepts by matching the filename against a regular expression.
 * 
 * @throws RuntimeException if an IOException occurs.
 * @see org.apache.commons.io.filefilter.AbstractFileFilter#accept(
 *  java.io.File)
 */
public boolean accept(File file) {

try {
return regExp.match(file.getCanonicalPath());
}
catch (IOException e) {

// TODO: Follow commons-io existing practice...
throw new RuntimeException(e);
}
}
}

==
/*
 * Copyright 2002-2004 The Apache Software Foundation.
 * 
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * 
 *  http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in 

Commons Mapper: scope/roadmap?

[Max Rudman]

I've just discovered Commons Mapper project and would like to 
contribute. I built my own abstraction layer for Hibernate but would 
love to move to Mapper instead. I looked through current documentation 
and have a couple of questions.

1) Are specific implementations within the scope of this project? You 
mention several data mapping technologies (such as Hibernate, iBATIS, 
etc.) in project overview but I saw no specific implementations in the 
JavaDocs API. As I said, I have experience with Hibernate and would 
like to contribute in providing Hibernate Mapper implementation (if 
this is something that needs to be done).

2) Is query API something you envision being part of this package? 
Specifically, a Query-By-Example API which I found to be very useful in 
enterprise application development where one often needs to have the 
ability to search for records with flexible (dynamic) WHERE clause. 
Hibernate package provides such an API but obviously it is specific to 
their implementation and it would be nice to have the abstraction layer 
against that functionality as well.

This is my first time inquiring about contributing to Jakarta Commons 
so I apologize in advance if I am doing something inappropriate. I did 
search through both user and dev mailing list archives but couldn't 
find any information on the topics above.

Thanks in advance,
Max
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: [proposal] avoiding jar version nightmares

[Oliver Zeigermann]

Sounds pretty good. However, I guess the problem is you can not change
the class loader implementation of WebSphere or other commercial stuff
:(

Oliver


On Fri, 17 Dec 2004 23:16:42 +, Chris Lambrou <[EMAIL PROTECTED]> wrote:
> 
> > Correct me if I'm wrong, but didn't Microsoft come up with some type
> > of solution to DLL hell in Windows 2000 or XP?  I seem to recall
> > reading that a long time ago, but I'm not a Windows programmer, so I
> > have no idea.  Does anyone else know?
> 
> 
> The .NET equivalent of a jar file is called an assembly. For libraries,
> this is basically a DLL. Every time the code is compiled, the DLL is
> automatically allocated a unique version number. When you compile your
> code that refers to code in a library assembly, your assembly has an
> explicit dependency on that library assembly. At runtime, when your code
> tries to invoke the library code, an exception will be raised if the
> exact version of the library assembly is not available.
> 
> It would appear that if there are bug fixes or other improvements to the
> library, and a recompiled assembly DLL is substituted for the one you
> originally compiled against, then your code will break. At runtime, your
> code will fail to link to the library code, since the version number no
> longer matches. Obviously, a maintenance release of a library component
> shouldn't require a recompilation and redeployment of all software that
> uses the library, so .NET provides a mechanism for you to explicitly
> define a version number. This allows you to provide updated library
> components to users without requiring them to recompile. However, this
> only works if you don't break backwards compatibility.
> 
> If you break backwards compatibility in a library, then you have to
> change the version number. However, .NET still allows you to deploy
> different, incompatible versions of the same DLL. When you deploy the
> application, your installer has to register both versions of the DLL
> with the GAC - the Global Assembly Cache. In this way, if you have a
> complex application that contains two components that rely on
> incompatible versions of the same library DLL, the VM instantiates two
> separate versions of the library DLL, and links the two components to
> the appropriate instance.
> 
> One possible Java analogy to this would be to bundle all code inside jar
> archives. Each jar contains dependency information, perhaps stored in
> the manifest, or some other meta-file, that describes the jar's own name
> and version number, and a list of the names and version numbers of its
> dependencies. A suitable class loader can then use this meta information
> to stitch the classes together appropriately. Actually, my knowledge of
> java class loaders isn't  sufficient for me to assert that this solution
> would definitely work, but it's a start, and I hope all of this serves
> to illustrate how .NET allows multiple versions of the same library to
> coexist.
> 
> Chris
> 
> -
> 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: AW: [proposal] avoiding jar version nightmares

[Chris Lambrou]

Correct me if I'm wrong, but didn't Microsoft come up with some type 
of solution to DLL hell in Windows 2000 or XP?  I seem to recall 
reading that a long time ago, but I'm not a Windows programmer, so I 
have no idea.  Does anyone else know?

The .NET equivalent of a jar file is called an assembly. For libraries, 
this is basically a DLL. Every time the code is compiled, the DLL is 
automatically allocated a unique version number. When you compile your 
code that refers to code in a library assembly, your assembly has an 
explicit dependency on that library assembly. At runtime, when your code 
tries to invoke the library code, an exception will be raised if the 
exact version of the library assembly is not available.

It would appear that if there are bug fixes or other improvements to the 
library, and a recompiled assembly DLL is substituted for the one you 
originally compiled against, then your code will break. At runtime, your 
code will fail to link to the library code, since the version number no 
longer matches. Obviously, a maintenance release of a library component 
shouldn't require a recompilation and redeployment of all software that 
uses the library, so .NET provides a mechanism for you to explicitly 
define a version number. This allows you to provide updated library 
components to users without requiring them to recompile. However, this 
only works if you don't break backwards compatibility.

If you break backwards compatibility in a library, then you have to 
change the version number. However, .NET still allows you to deploy 
different, incompatible versions of the same DLL. When you deploy the 
application, your installer has to register both versions of the DLL 
with the GAC - the Global Assembly Cache. In this way, if you have a 
complex application that contains two components that rely on 
incompatible versions of the same library DLL, the VM instantiates two 
separate versions of the library DLL, and links the two components to 
the appropriate instance.

One possible Java analogy to this would be to bundle all code inside jar 
archives. Each jar contains dependency information, perhaps stored in 
the manifest, or some other meta-file, that describes the jar's own name 
and version number, and a list of the names and version numbers of its 
dependencies. A suitable class loader can then use this meta information 
to stitch the classes together appropriately. Actually, my knowledge of 
java class loaders isn't  sufficient for me to assert that this solution 
would definitely work, but it's a start, and I hope all of this serves 
to illustrate how .NET allows multiple versions of the same library to 
coexist.

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

Re: AW: AW: [proposal] avoiding jar version nightmares

[Oliver Zeigermann]

On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> This would be really a funny thing, but how could we replace the classloader
> of a given application with a custom one?

Right. Impossible :(

> But what about a tool that decompiles all the product jars, changes the
> package structure and the import statements and repacks this into a new jar?
> ;-)
> Might be a megaseller...

No need to decompile. Libs like BCEL or ASM can do this for us. Other
than that cool stuff :)

This would need information which part of the software want which version! 
However, it would be very hard to debug if the tool had any bugs in
it. But of course it would not ;)

When is founding time for the company?

Oliver

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

Re: AW: AW: [proposal] avoiding jar version nightmares

[Oliver Zeigermann]

I think Daniel is right. This would not change anything. 

I am not quite sure the problem is yet obvious to anyone: The *same*
classloader must return two *different* versions of the *same* class
for different parts of your software which seems impossible for an
ordinary class loader unless the classes are in a different package.
That's why Daniel proposes to put imcompible class versions in
different packages.

Any better solution?

Oliver

On Fri, 17 Dec 2004 22:12:41 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> Don't know. But I think the classloader will still not know which class to
> pick as the names are still identical. So it might depend on the load order
> of the jars which product will fail.
> Or did I got it wrong?
> 
> Daniel
> 
> > -Ursprüngliche Nachricht-
> > Von: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > Im Auftrag von David Graham
> > Gesendet: Freitag, 17. Dezember 2004 21:33
> > An: Jakarta Commons Developers List
> > Betreff: Re: AW: [proposal] avoiding jar version nightmares
> >
> > What happens if you merge the jars for each product?  For example, put
> > commons 1.x files into productA.jar and commons 2.x files into
> > productB.jar.
> >
> > David

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

Re: Jakarta Commons Structure rehashed

[Henri Yandell]

And yet option A is going to be impossible (?) to check out as one whole blob.

I wonder if there's any magic coming from the SVN guys that'll let us
do option B and yet provide a link of some kind to automatically be
able to check out all the trunks in one go.

Hen

On Fri, 17 Dec 2004 14:01:53 -0700, Kris Nuttycombe
<[EMAIL PROTECTED]> wrote:
> Option A makes the projects look a lot more atomic, which seems like a
> good idea when one contemplates what will be necessary when promoting
> projects from the sandbox.
> 
> Kris
> 
> Tim O'Brien wrote:
> 
> >I don't think we ever settled this question.
> >
> >Which SVN structure are we interested in?
> >
> >** Option A:
> >
> >jakarta/
> >commons/
> >digester/
> >trunk/
> >tags/
> >branches/
> >beanutils/
> >trunk/
> >tags/
> >branches/
> >
> >OR
> >
> >** Option B:
> >
> >jakarta/
> >commons/
> >trunk/
> >digester/
> >beanutils/
> >tags/
> >digester/
> >beanutils/
> >branches/
> >digester/
> >beanutils/
> >
> >
> >
> 
> --
> =
> Kris Nuttycombe
> Associate Scientist
> Geospatial Data Services Group
> CIRES, National Geophysical Data Center/NOAA
> (303) 497-6337
> [EMAIL PROTECTED]
> =
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Chris Lambrou]

Someone suggested that for Log, it would be appropriate to make it an 
abstract class rather than an interface, so we can make these kinds of 
changes easier in the future.  I think the risks for this are low, and 
probably better [less problems for the majority of users] than just adding 
new methods to the existing interface.  Other thoughts on this direction?
 

I think the risk of annoying quite a number of users by changing Log 
from an interface to an abstract class is actually quite high. For sure, 
one of the default logging implementations provided by JCL would 
probably suffice for the majority. However, there are groups who will 
have chosen, for whatever reason, to provide their own logging 
implementations. I've certainly worked on a couple of projects where 
this has been the case. One of them could probably cope with the change 
relatively easiliy, but such a change could be a real pain for the 
other. Whilst the proportion of JCL users in this situation is probably 
quite small, in terms of actual numbers, such a change could cause quite 
a lot of grief.

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

Re: Jakarta Commons Structure rehashed

[Kris Nuttycombe]

Option A makes the projects look a lot more atomic, which seems like a 
good idea when one contemplates what will be necessary when promoting 
projects from the sandbox.

Kris
Tim O'Brien wrote:
I don't think we ever settled this question. 

Which SVN structure are we interested in?
** Option A:
jakarta/
   commons/
   digester/
   trunk/
   tags/
   branches/
   beanutils/
   trunk/
   tags/
   branches/
OR 

** Option B:
jakarta/
   commons/
   trunk/
   digester/
   beanutils/
   tags/
   digester/
   beanutils/
   branches/
   digester/
   beanutils/
 

--
=
Kris Nuttycombe
Associate Scientist
Geospatial Data Services Group
CIRES, National Geophysical Data Center/NOAA
(303) 497-6337
[EMAIL PROTECTED]
=

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

Re: Jakarta Commons Structure rehashed

[David Graham]

Option B doesn't make a whole lot of sense to me.  Most people are
interested in only a few commons projects so each having their own trunk,
tags, and branches makes sense.  Struts lays out its subprojects using
Option A:

http://svn.apache.org/viewcvs.cgi/struts/

David

--- Tim O'Brien <[EMAIL PROTECTED]> wrote:

> I don't think we ever settled this question. 
> 
> Which SVN structure are we interested in?
> 
> ** Option A:
> 
> jakarta/
> commons/
> digester/
> trunk/
> tags/
> branches/
> beanutils/
> trunk/
> tags/
> branches/
> 
> OR 
> 
> ** Option B:
> 
> jakarta/
> commons/
> trunk/
> digester/
> beanutils/
> tags/
> digester/
> beanutils/
> branches/
> digester/
> beanutils/
> 




__ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com

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

[launcher] ordered system properties

[Samaroo, Trevor J]

Hello,

 

We had the need to order system properties passed into our program.  I
modified LaunchTask.java in order to accomplish this.  

 

How can I contribute this 'feature'/codechange to the project?  I don't want
to diverge from the launcher codebase.

 

We need sysprops to be ordered for our application monitoring programs to
find our process correctly.  (we pass in -Dapp.id=aUniqueId and this must
exist as the first element in the command line.) Considering this change
makes a previously unordered sysprop list ordered, there shouldn't be any
impact on existing code.

 

Can someone (Patrick Luby?) from the commons-launcher project advise?

 

Regards,

 

Trevor Samaroo

AW: AW: [proposal] avoiding jar version nightmares

[Daniel Florey]

This would be really a funny thing, but how could we replace the classloader
of a given application with a custom one?
But what about a tool that decompiles all the product jars, changes the
package structure and the import statements and repacks this into a new jar?
;-)
Might be a megaseller...

Daniel

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Oliver Zeigermann
> Gesendet: Donnerstag, 16. Dezember 2004 22:44
> An: Jakarta Commons Developers List
> Betreff: Re: AW: [proposal] avoiding jar version nightmares
> 
> On Thu, 16 Dec 2004 19:09:54 +0100, Daniel Florey <[EMAIL PROTECTED]>
> wrote:
> > So I think we need a solution for this problem. My proposal would be to
> > allow different major versions of commons components to coexist. If the
> > class and package names are equal, this is not possible. My package-
> version
> > proposal is just one idea to enable this.
> 
> Some versioning class loader as it was thought of in Projector would
> really be a very elegant solution ;)
> 
> Oliver
> 
> -
> 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]

AW: AW: [proposal] avoiding jar version nightmares

[Daniel Florey]

Don't know. But I think the classloader will still not know which class to
pick as the names are still identical. So it might depend on the load order
of the jars which product will fail.
Or did I got it wrong?

Daniel

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von David Graham
> Gesendet: Freitag, 17. Dezember 2004 21:33
> An: Jakarta Commons Developers List
> Betreff: Re: AW: [proposal] avoiding jar version nightmares
> 
> What happens if you merge the jars for each product?  For example, put
> commons 1.x files into productA.jar and commons 2.x files into
> productB.jar.
> 
> David
> 
> --- Daniel Florey <[EMAIL PROTECTED]> wrote:
> 
> > So how should we handle situations where two versions of the same
> > component
> > need to coexist?
> > If I have to integrate two commercial projects where each one uses a
> > different major version of the same component, how can I achieve this?
> > There
> > is no chance to force them to up- or downgrade to the version of the
> > other
> > product. In situations like these you are absolutely lost, aren't you?
> > So my proposal was about to avoid this horrible situation. Any proposals
> > how
> > to solve this issue in another way?
> > Or is this list not the right place for discussing stuff like this?
> >
> > Cheers,
> > Daniel
> >
> >
> > > -Urspr|ngliche Nachricht-
> > > Von: [EMAIL PROTECTED]
> > >
> >
> [mailto:[EMAIL PROTECTED]
> > > Im Auftrag von David Graham
> > > Gesendet: Freitag, 17. Dezember 2004 02:26
> > > An: Jakarta Commons Developers List
> > > Betreff: Re: [proposal] avoiding jar version nightmares
> > >
> > > Struts uses the deprecation cycle I described and so did the commons
> > > components spawned from Struts the last I knew (validator certainly
> > still
> > > uses the described cycle).   A 1.x series is backwards compatible but
> > > deprecated methods may be removed after they have been deprecated for
> > at
> > > least one point release.  A jump to 2.x means, among other things,
> > there
> > > are backwards incompatible changes without a deprecation cycle.
> > >
> > > This approach obviously varies by project.
> > >
> > > David
> > >
> > > --- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> > >
> > > > Commons has always followed a longer deprecation cycle than
> > described
> > > > below.
> > > > A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0.
> > > >
> > > > 1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
> > > >
> > > > 1.1/1.2 -> 2.0 may cause issues.
> > > >
> > > > In collections we faced a peculiar compatability problem in that a
> > > > constant
> > > > was in both 2.1 and 3.0 but was declared as a different type (by
> > error).
> > > >
> > > > This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or
> > 3.1
> > > > to
> > > > get around the problem).
> > > >
> > > > Personally, I believe that a different package name for each version
> > is
> > > > overly restricting. Most users will just recompile their code for
> > the
> > > > new
> > > > version and it will just work. Plus, having the same class in two
> > > > different
> > > > packages will be very confusing when using an IDE. This would be
> > > > especially
> > > > true if someone obtains an object from one version and then tries to
> > > > pass it
> > > > to an object of another version.
> > > >
> > > > Also, since human error can be a factor, we would have to version
> > every
> > > > release, minor or major to actually make the system foolproof.
> > > >
> > > > Basically, I believe there is no simple solution to this. The best
> > we
> > > > can do
> > > > is to encourage tools like clirr which check a library for binary
> > > > compatability. This should become part of each components standard
> > > > tests.
> > > >
> > > > Stephen
> > > >
> > > > - Original Message -
> > > > From: "David Graham" <[EMAIL PROTECTED]>
> > > > > All the jakarta projects I've worked on have a deprecation cycle
> > of
> > > > one
> > > > > minor point release.  For example, you deprecate a method for the
> > 1.1
> > > > > release and can remove it for the 1.2 release.  This gives users
> > time
> > > > to
> > > > > see the deprecation warning and update their code appropriately.
> > IMO,
> > > > > requiring a package name change is overly restrictive and
> > confusing to
> > > > > users.
> > > > >
> > > > > The only time I've seen versioning problems is when commons
> > components
> > > > > depend on each other and one of them breaks backwards
> > compatibility
> > > > like
> > > > > commons collections did recectly.  This is why it's so important
> > for
> > > > > commons components to have minimal dependencies.
> > > > >
> > > > > What commons components caused your project problems?
> > > > >
> > > > > David
> > > > >
> > > > >
> > > > > --- Daniel Florey <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >> Hi all,
> > > > >> As commons components gain more and more attention you

Jakarta Commons Structure rehashed

[Tim O'Brien]

I don't think we ever settled this question. 

Which SVN structure are we interested in?

** Option A:

jakarta/
commons/
digester/
trunk/
tags/
branches/
beanutils/
trunk/
tags/
branches/

OR 

** Option B:

jakarta/
commons/
trunk/
digester/
beanutils/
tags/
digester/
beanutils/
branches/
digester/
beanutils/

Re: AW: [proposal] avoiding jar version nightmares

[David Graham]

What happens if you merge the jars for each product?  For example, put
commons 1.x files into productA.jar and commons 2.x files into
productB.jar.

David

--- Daniel Florey <[EMAIL PROTECTED]> wrote:

> So how should we handle situations where two versions of the same
> component
> need to coexist?
> If I have to integrate two commercial projects where each one uses a
> different major version of the same component, how can I achieve this?
> There
> is no chance to force them to up- or downgrade to the version of the
> other
> product. In situations like these you are absolutely lost, aren't you?
> So my proposal was about to avoid this horrible situation. Any proposals
> how
> to solve this issue in another way?
> Or is this list not the right place for discussing stuff like this? 
> 
> Cheers,
> Daniel
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: [EMAIL PROTECTED]
> >
>
[mailto:[EMAIL PROTECTED]
> > Im Auftrag von David Graham
> > Gesendet: Freitag, 17. Dezember 2004 02:26
> > An: Jakarta Commons Developers List
> > Betreff: Re: [proposal] avoiding jar version nightmares
> > 
> > Struts uses the deprecation cycle I described and so did the commons
> > components spawned from Struts the last I knew (validator certainly
> still
> > uses the described cycle).   A 1.x series is backwards compatible but
> > deprecated methods may be removed after they have been deprecated for
> at
> > least one point release.  A jump to 2.x means, among other things,
> there
> > are backwards incompatible changes without a deprecation cycle.
> > 
> > This approach obviously varies by project.
> > 
> > David
> > 
> > --- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> > 
> > > Commons has always followed a longer deprecation cycle than
> described
> > > below.
> > > A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0.
> > >
> > > 1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
> > >
> > > 1.1/1.2 -> 2.0 may cause issues.
> > >
> > > In collections we faced a peculiar compatability problem in that a
> > > constant
> > > was in both 2.1 and 3.0 but was declared as a different type (by
> error).
> > >
> > > This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or
> 3.1
> > > to
> > > get around the problem).
> > >
> > > Personally, I believe that a different package name for each version
> is
> > > overly restricting. Most users will just recompile their code for
> the
> > > new
> > > version and it will just work. Plus, having the same class in two
> > > different
> > > packages will be very confusing when using an IDE. This would be
> > > especially
> > > true if someone obtains an object from one version and then tries to
> > > pass it
> > > to an object of another version.
> > >
> > > Also, since human error can be a factor, we would have to version
> every
> > > release, minor or major to actually make the system foolproof.
> > >
> > > Basically, I believe there is no simple solution to this. The best
> we
> > > can do
> > > is to encourage tools like clirr which check a library for binary
> > > compatability. This should become part of each components standard
> > > tests.
> > >
> > > Stephen
> > >
> > > - Original Message -
> > > From: "David Graham" <[EMAIL PROTECTED]>
> > > > All the jakarta projects I've worked on have a deprecation cycle
> of
> > > one
> > > > minor point release.  For example, you deprecate a method for the
> 1.1
> > > > release and can remove it for the 1.2 release.  This gives users
> time
> > > to
> > > > see the deprecation warning and update their code appropriately. 
> IMO,
> > > > requiring a package name change is overly restrictive and
> confusing to
> > > > users.
> > > >
> > > > The only time I've seen versioning problems is when commons
> components
> > > > depend on each other and one of them breaks backwards
> compatibility
> > > like
> > > > commons collections did recectly.  This is why it's so important
> for
> > > > commons components to have minimal dependencies.
> > > >
> > > > What commons components caused your project problems?
> > > >
> > > > David
> > > >
> > > >
> > > > --- Daniel Florey <[EMAIL PROTECTED]> wrote:
> > > >
> > > >> Hi all,
> > > >> As commons components gain more and more attention you'll find a
> lot
> > > >> components in larger java based projects. This can cause much
> trouble
> > > >> when
> > > >> subprojects use different incompatible versions of the same
> > > component.
> > > >> I was faced with this problem in the project I'm currently
> working on
> > > >> and
> > > >> thought about how to avoid situations like these.
> > > >> So this is my proposal:
> > > >> - All versions of a component using the same main version number
> must
> > > be
> > > >> upwards compatible: Methods in component-1.x must not change in
> > > semantic
> > > >> or
> > > >> syntax compared to component-1.y where x < y. Methods can be
> marked
> > > as
> > > >> deprecated but must still work in the same way.
> > > >> - When inco

Re: AW: [proposal] avoiding jar version nightmares

[Matt Sgarlata]

Daniel Florey wrote:
> Any proposals how to solve this issue in another way?
Correct me if I'm wrong, but didn't Microsoft come up with some type of 
solution to DLL hell in Windows 2000 or XP?  I seem to recall reading 
that a long time ago, but I'm not a Windows programmer, so I have no 
idea.  Does anyone else know?

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

AW: [proposal] avoiding jar version nightmares

[Daniel Florey]

So how should we handle situations where two versions of the same component
need to coexist?
If I have to integrate two commercial projects where each one uses a
different major version of the same component, how can I achieve this? There
is no chance to force them to up- or downgrade to the version of the other
product. In situations like these you are absolutely lost, aren't you?
So my proposal was about to avoid this horrible situation. Any proposals how
to solve this issue in another way?
Or is this list not the right place for discussing stuff like this? 

Cheers,
Daniel


> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von David Graham
> Gesendet: Freitag, 17. Dezember 2004 02:26
> An: Jakarta Commons Developers List
> Betreff: Re: [proposal] avoiding jar version nightmares
> 
> Struts uses the deprecation cycle I described and so did the commons
> components spawned from Struts the last I knew (validator certainly still
> uses the described cycle).   A 1.x series is backwards compatible but
> deprecated methods may be removed after they have been deprecated for at
> least one point release.  A jump to 2.x means, among other things, there
> are backwards incompatible changes without a deprecation cycle.
> 
> This approach obviously varies by project.
> 
> David
> 
> --- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> 
> > Commons has always followed a longer deprecation cycle than described
> > below.
> > A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0.
> >
> > 1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
> >
> > 1.1/1.2 -> 2.0 may cause issues.
> >
> > In collections we faced a peculiar compatability problem in that a
> > constant
> > was in both 2.1 and 3.0 but was declared as a different type (by error).
> >
> > This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or 3.1
> > to
> > get around the problem).
> >
> > Personally, I believe that a different package name for each version is
> > overly restricting. Most users will just recompile their code for the
> > new
> > version and it will just work. Plus, having the same class in two
> > different
> > packages will be very confusing when using an IDE. This would be
> > especially
> > true if someone obtains an object from one version and then tries to
> > pass it
> > to an object of another version.
> >
> > Also, since human error can be a factor, we would have to version every
> > release, minor or major to actually make the system foolproof.
> >
> > Basically, I believe there is no simple solution to this. The best we
> > can do
> > is to encourage tools like clirr which check a library for binary
> > compatability. This should become part of each components standard
> > tests.
> >
> > Stephen
> >
> > - Original Message -
> > From: "David Graham" <[EMAIL PROTECTED]>
> > > All the jakarta projects I've worked on have a deprecation cycle of
> > one
> > > minor point release.  For example, you deprecate a method for the 1.1
> > > release and can remove it for the 1.2 release.  This gives users time
> > to
> > > see the deprecation warning and update their code appropriately.  IMO,
> > > requiring a package name change is overly restrictive and confusing to
> > > users.
> > >
> > > The only time I've seen versioning problems is when commons components
> > > depend on each other and one of them breaks backwards compatibility
> > like
> > > commons collections did recectly.  This is why it's so important for
> > > commons components to have minimal dependencies.
> > >
> > > What commons components caused your project problems?
> > >
> > > David
> > >
> > >
> > > --- Daniel Florey <[EMAIL PROTECTED]> wrote:
> > >
> > >> Hi all,
> > >> As commons components gain more and more attention you'll find a lot
> > >> components in larger java based projects. This can cause much trouble
> > >> when
> > >> subprojects use different incompatible versions of the same
> > component.
> > >> I was faced with this problem in the project I'm currently working on
> > >> and
> > >> thought about how to avoid situations like these.
> > >> So this is my proposal:
> > >> - All versions of a component using the same main version number must
> > be
> > >> upwards compatible: Methods in component-1.x must not change in
> > semantic
> > >> or
> > >> syntax compared to component-1.y where x < y. Methods can be marked
> > as
> > >> deprecated but must still work in the same way.
> > >> - When incompatible api changes or semantic changes of existing
> > methods
> > >> will
> > >> be introduced, a new major version number must indicate this. To
> > ensure
> > >> that
> > >> different versions of the same component can be used by a single
> > >> application, the package name must change as well.
> > >> Example:
> > >> org.apache.commons.component-1 contains the 1.x source code of the
> > >> compoenent
> > >> org.apache.commons.component-2 contains the 2.x sources
> > >>
> > >> Bot

Re: [logging] Encryption?

[Martin Cooper]

On Fri, 17 Dec 2004 11:08:55 +0100, Magnus Svensson (HF/EAB)
<[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I have a question regarding encryption and export control. Does Jakarta 
> Common Logging include any SW encryption that restricts export (i.e. special 
> ECCN code)?
> 

No, it doesn't. I believe the only Commons component that may have
code like this is HttpClient.

--
Martin Cooper


> Regards,
> Magnus Svensson
> 
> -
> 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: [all] Clean up old modules from sandbox?

[Martin Cooper]

On Fri, 17 Dec 2004 12:34:20 +, Rory Winston <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I was browsing through the commons-sandbox repository on cvs.apache.org and 
> it seems that there are a lot of unused and redundant entries in there that 
> should probably be removed, e.g. uid, chain (now promoted), transaction 
> (promoted), codec (ditto), daemon, etc.
> 
> Does anyone think it might be worthwhile removing these from CVS entirely, 
> and doing a sort of "xmas cleanout" of these old modules?
> 

Feel free to remove Chain from the sandbox. I deliberately left it
there for a couple of days after promotion, to make sure that Chain in
Proper was OK, but then I forgot to go back and clean house. ;-(

You should be aware, though, that there are some Proper components
that have (semi-)active Sandbox counterparts. They use the sandbox
version for experimentation, prior to pulling it over for a new
release. (At least, this used to be true - not sure if any are still
doing this.)

--
Martin Cooper


> Cheers,
> Rory
> 
> _
> Sign up for eircom broadband now and get a free two month trial.*
> Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer
> 
> -
> 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]

cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task UUIDTask.java

[rwinston]

rwinston2004/12/17 07:21:36

  Modified:id/src/java/org/apache/commons/id/task UUIDTask.java
  Log:
  Remove log statement
  
  Revision  ChangesPath
  1.2   +1 -2  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java
  
  Index: UUIDTask.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- UUIDTask.java 17 Dec 2004 12:19:29 -  1.1
  +++ UUIDTask.java 17 Dec 2004 15:21:36 -  1.2
  @@ -65,7 +65,6 @@
uuid = UUID.timeUUID();
}

  - log("Setting property:" + uuid.toString());
setProperty("uuid", uuid.toString());
}

  
  
  

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

Re: [ALL][VFS] Third party java library.

[Mario Ivankovits]

Hello!
Do you have a url for the project at Novell that supplies the
njclv2.jar? I need to pass something on to the legal team.
 
The library can be downloaded at http://developer.novell.com/ndk/njclc.htm
Thanks for taking the time to dig into the license stuff.
---
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ALL][VFS] Third party java library.

[Henri Yandell]

Hey Mario,

With the odd wording of the Novell licence, it looks like we might
have to get permission on a case by case basis to make sure the
library isn't early-access etc.

Do you have a url for the project at Novell that supplies the
njclv2.jar? I need to pass something on to the legal team.

Thanks,

Hen

On Tue, 7 Dec 2004 16:29:02 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
> My head hurts, reading this stuff is evil :)
> 
> Very little of the license applies directly to whether we're allowed
> to use it; basically seems:
> 
> If it's an "Early Access Product", then no, we can't use it.
> If it's a "Developer Product", then yes we can import it, distribute
> it inside a larger product, but cannot have their product in CVS,
> iBiblio etc. So exactly the same as Sun's, though the Early Access bit
> is something to watch out for.
> 
> The rest is mostly the same as Sun's. Lots of corporate garbage etc.
> Let's go ahead and treat it the same as javamail if and only if it's a
> "Developer Product", and I'll let the board/licensing know that we're
> treating it as such and to let us know if this is bad.
> 
> Hen
> 
> On Tue, 7 Dec 2004 09:07:59 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > Just from his comment it sounds much like the Sun JavaMail licence
> > that gives us such pain. So no to CVS or iBiblio, but yes to imports.
> > I'll give it a read later today.
> >
> > Hen
> >
> >
> >
> > On Tue, 07 Dec 2004 08:47:21 +0100, Mario Ivankovits <[EMAIL PROTECTED]> 
> > wrote:
> > > Henri Yandell wrote:
> > >
> > > >So first step is, ask them what the licence is. Then we'll figure out
> > > >what to do from there.
> > > >
> > > >
> > > This is what we got from Novell. If one could review this NDK License it
> > > would be nice.
> > >
> > > > Hi there,
> > > >   If the library is bundled with the application, then there is
> > > > not a problem.  But if the library would be an independent download,
> > > > then the end users will have to download it directly from Novell's
> > > > website.  For more detatils see:
> > > > http://developer.novell.com/ndk/license.htm (which you problably
> > > > already did, but I don't blame, since all legal software matters is
> > > > always confusing to everybody).
> > > >
> > > > Regards,
> > > >
> > > > Moises Morales
> > > > Novell Developer Services.
> > > >
> > > >
> > > Thanks!
> > > ---
> > >
> > >
> > > Mario
> > >
> > > -
> > > 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]

Encryption?

[Magnus Svensson (HF/EAB)]

Hi,

I have a question regarding encryption and export control. Does Jakarta Common 
Logging include any SW encryption that restricts export (i.e. special ECCN 
code)?

Regards,
Magnus Svensson

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

cvs commit: jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking GenericLockTest.java

[ozeigermann]

ozeigermann2004/12/17 08:37:07

  Modified:transaction/src/test/org/apache/commons/transaction/locking
GenericLockTest.java
  Log:
  Added test for fix for possbile lock out with incompatible preferred locks
  applied in GenericLock 1.6
  
  Revision  ChangesPath
  1.5   +127 -5
jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking/GenericLockTest.java
  
  Index: GenericLockTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking/GenericLockTest.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- GenericLockTest.java  17 Dec 2004 00:31:22 -  1.4
  +++ GenericLockTest.java  17 Dec 2004 16:37:07 -  1.5
  @@ -252,7 +252,7 @@
* 8release resumed
* 9release
*/
  -public void testPreference() throws Throwable {
  +public void testUpgrade() throws Throwable {
   
   sLogger.logInfo("\n\nChecking upgrade and preference lock\n\n");
   
  @@ -360,4 +360,126 @@
   
   }
   
  +/*
  + * 
  + * Test shows that two preference locks that are imcompatible do not 
cause a lock out
  + * which was the case with GenericLock 1.5
  + * Before the fix this test would dealock
  + * 
  + *  Owner   Owner   Owner
  + * Step #1  #2  #3
  + * 1read (ok)
  + * 2write preferred 
  + *  (blocked 
  + *  because of #1)
  + * 3write preferred 
  + *  (blocked 
  + *  because of #1 and #2)
  + * 4release
  + * 5resumed   orresumed 
  + *  (as both are preferred, problem
  + *   is that that would exclude each 
other
  + *   in the algorithm used)
  + * 6released   or   released
  + * 7resumed   orresumed 
  + * 8released   or   released
  + * 
  + * 
  + * In CounterBarrierNotation this looks like
  + * 
  + *  Owner   Owner   Owner
  + *  #1  #2  #3
  + *  0read1
  + *  2(write3)
  + *  4(write5)
  + *  6(release)7
  + *  8release9   8release9
  + * 
  + * Round brackets mean atomic execution
  + * 
  + * 
  + */
  +public void testPreference() throws Throwable {
  +
  +sLogger.logInfo("\n\nChecking incompatible preference locks\n\n");
  +
  +final String owner1 = "owner1";
  +final String owner2 = "owner2";
  +final String owner3 = "owner3";
  +
  +final String res1 = "res1";
  +
  +final ReadWriteLock lock = new ReadWriteLock(res1, sLogger);
  +
  +final RendezvousBarrier restart = new RendezvousBarrier("restart", 
3, TIMEOUT, sLogger);
  +
  +final CounterBarrier cb = new CounterBarrier("cb1", TIMEOUT, 
sLogger);
  +
  +for (int i = 0; i < CONCURRENT_TESTS; i++) {
  +
  +System.out.print(".");
  +
  +Thread t1 = new Thread(new Runnable() {
  +public void run() {
  +try {
  +cb.count(2);
  +synchronized (lock) {
  +cb.count(3);
  +lock.acquire(owner2, ReadWriteLock.WRITE_LOCK, 
true,
  +GenericLock.COMPATIBILITY_REENTRANT, 
true, TIMEOUT);
  +}
  +cb.count(8);
  +lock.release(owner2);
  +cb.count(9);
  +synchronized (restart) {
  +restart.meet();
  +restart.reset();
  +}
  +} catch (InterruptedException ie) {
  +}
  +}
  +}, "Thread #1");
  +
  +t1.start();
  +
  +Thread t2 = new Thread(new Runnable() {
  +public void run() {
  +try {
  +cb.count(4);
  +synchroniz

cvs commit: jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking GenericLockManager.java GenericLock.java

[ozeigermann]

ozeigermann2004/12/17 08:36:22

  Modified:transaction/src/java/org/apache/commons/transaction/locking
GenericLockManager.java GenericLock.java
  Log:
  Fix for possbile lock out with incompatible preferred locks.
  
  Revision  ChangesPath
  1.5   +7 -5  
jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
  
  Index: GenericLockManager.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLockManager.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- GenericLockManager.java   16 Dec 2004 23:26:31 -  1.4
  +++ GenericLockManager.java   17 Dec 2004 16:36:21 -  1.5
  @@ -88,7 +88,9 @@
   public boolean tryLock(Object ownerId, Object resourceId, int 
targetLockLevel, boolean reentrant) {
   GenericLock lock = (GenericLock) atomicGetOrCreateLock(resourceId);
   boolean acquired = lock.tryLock(ownerId, targetLockLevel,
  -reentrant ? GenericLock.COMPATIBILITY_REENTRANT : 
GenericLock.COMPATIBILITY_NONE);
  +reentrant ? GenericLock.COMPATIBILITY_REENTRANT : 
GenericLock.COMPATIBILITY_NONE,
  +false);
  +
   if (acquired) {
   addOwner(ownerId, lock);
   }
  
  
  
  1.6   +44 -25
jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLock.java
  
  Index: GenericLock.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLock.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- GenericLock.java  17 Dec 2004 00:20:36 -  1.5
  +++ GenericLock.java  17 Dec 2004 16:36:21 -  1.6
  @@ -176,7 +176,7 @@
   public boolean test(Object ownerId, int targetLockLevel, int 
compatibility) {
   boolean success = false;
   try {
  -success = tryLock(ownerId, targetLockLevel, compatibility);
  +success = tryLock(ownerId, targetLockLevel, compatibility, 
false);
   } finally {
   release(ownerId);
   }
  @@ -248,7 +248,7 @@
+ System.currentTimeMillis());
   }
   
  -if (tryLock(ownerId, targetLockLevel, compatibility)) {
  +if (tryLock(ownerId, targetLockLevel, compatibility, preferred)) {
   
   if (logger.isFinerEnabled()) {
logger.logFiner(
  @@ -288,7 +288,7 @@
   oldLock = (LockOwner) owners.get(ownerId);
   // this creates a new owner, so we do not need to
   // copy the old one
  -setLockLevel(ownerId, null, targetLockLevel);
  +setLockLevel(ownerId, null, targetLockLevel, 
preferred);
   
   // finally wait
   wait(remaining);
  @@ -299,14 +299,18 @@
   // following check
   // and not to have it in case of success either
   // as there will be an ordinary lock then
  -owners.put(ownerId, oldLock);
  +if (oldLock != null) {
  +owners.put(ownerId, oldLock);
  +} else {
  +owners.remove(ownerId);
  +}
   }
   
   } else {
   wait(remaining);
   }
   
  -if (tryLock(ownerId, targetLockLevel, compatibility)) {
  +if (tryLock(ownerId, targetLockLevel, compatibility, 
preferred)) {
   
   if (logger.isFinerEnabled()) {
logger.logFiner(
  @@ -394,37 +398,43 @@
   
   for (Iterator it = owners.values().iterator(); it.hasNext();) {
   LockOwner owner = (LockOwner) it.next();
  -buf.append("- ").append(owner.ownerId.toString()).append(": 
").append(owner.lockLevel).append("\n");
  +buf.append("- ").append(owner.ownerId.toString()).append(": 
").append(owner.lockLevel)
  +.append(owner.intention ? " intention" : " 
acquired").append("\n");
   }
   return buf.toString();
   
   }
   
   protected synchronized LockOwner getMaxLevelOwner() {
  -return getMaxLevelOwner(null, -1);
  +return getMaxLevelOwner(null, -1, false);
   }
   
  -protected synchronized LockOwner getMaxLevelOwner(LockOwner 
reentrantOwner) {
  -return getMaxLevelOwner(reentrantOwner,

DO NOT REPLY [Bug 32756] - [digester] Exact patterns overwrite patterns with wildcards

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32756


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows XP  |All
   Platform|PC  |All
Summary|[digester] Eexact patterns  |[digester] Exact patterns
   |overwrite patterns with |overwrite patterns with
   |wildcards   |wildcards




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32756] - [digester] Eexact patterns overwrite patterns with wildcards

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32756


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|exact patterns overwrite|[digester] Eexact patterns
   |patterns with wildcards |overwrite patterns with
   ||wildcards




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

cvs commit: jakarta-commons-sandbox/id/src/test/org/apache/commons/id/uuid UUIDTest.java

[rwinston]

rwinston2004/12/17 06:34:47

  Modified:id/src/test/org/apache/commons/id/uuid UUIDTest.java
  Log:
  Change package declarations
  
  Revision  ChangesPath
  1.8   +2 -2  
jakarta-commons-sandbox/id/src/test/org/apache/commons/id/uuid/UUIDTest.java
  
  Index: UUIDTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/id/src/test/org/apache/commons/id/uuid/UUIDTest.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- UUIDTest.java 14 Dec 2004 12:39:59 -  1.7
  +++ UUIDTest.java 17 Dec 2004 14:34:47 -  1.8
  @@ -28,7 +28,7 @@
   import junit.framework.TestSuite;
   import junit.textui.TestRunner;
   
  -import org.apache.commons.codec.binary.Hex;
  +import org.apache.commons.id.Hex;
   
   /**
* Unit tests for [EMAIL PROTECTED] UUID}.
  
  
  

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

DO NOT REPLY [Bug 32756] New: - exact patterns overwrite patterns with wildcards

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32756

   Summary: exact patterns overwrite patterns with wildcards
   Product: Commons
   Version: unspecified
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Digester
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In the code below the Rules with the wildcard-patterns don't seem to be fired
(at least, when using the xml even more below). If the exact matching rules are
put in comment, the wildcard matching rules do get fired.
It seems like the SetRoot rule overwrites the ObjectCreate rule.
Furthermore the pattern "datadescriptor//property" doesn't seem to match
anywhere, but this may be due to a misunderstanding of the (rather short)
explanation in the docs.

yours sincerely,
Maarten Van Puymbroeck.

-- Java Code --

// Properties
  // create the object
  digester.addObjectCreate("*/property", RealProperty.class);
  // initialize properties
String[] properties = new String[]{"name", "key", "tooltip", "mapsWith",
"type", "ref"};
digester.addSetProperties("*/property", properties, properties);
  // add the properties to the correct collection
digester.addSetRoot("datadescriptor/properties/property", "addProperty");//,
"be.generic.Property");
digester.addSetRoot("datadescriptor/searchproperties/property",
"addSearchProperty");//, "be.generic.Property");
digester.addSetRoot("datadescriptor/listproperties/property",
"addListProperty");//, "be.generic.Property");
digester.addSetRoot("datadescriptor/editproperties/property",
"addEditProperty");//, "be.generic.Property");



-- XML --




















-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [all] Clean up old modules from sandbox?

[Henri Yandell]

We should also look at killing the messenger component. As far as I
know its development has moved to Codehaus (though it's unreleased
there so you have to dig). I suspect it's dead here.

Hen

On Fri, 17 Dec 2004 13:46:38 +0100, Oliver Zeigermann
<[EMAIL PROTECTED]> wrote:
> I already deleted transaction, but left docs that redirect to commons
> transaction in the proper section and a "MOVED TO COMMONS PROPER"
> file. I thought this would be cleaner, but have no real objections
> against removing it completely.
> 
> Oliver
> 
> 
> On Fri, 17 Dec 2004 12:34:20 +, Rory Winston <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I was browsing through the commons-sandbox repository on cvs.apache.org and 
> > it seems that there are a lot of unused and redundant entries in there that 
> > should probably be removed, e.g. uid, chain (now promoted), transaction 
> > (promoted), codec (ditto), daemon, etc.
> >
> > Does anyone think it might be worthwhile removing these from CVS entirely, 
> > and doing a sort of "xmas cleanout" of these old modules?
> >
> > Cheers,
> > Rory
> >
> > _
> > Sign up for eircom broadband now and get a free two month trial.*
> > Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer
> >
> > -
> > 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]

cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/state StateHelper.java

[rwinston]

rwinston2004/12/17 06:25:00

  Modified:id/src/java/org/apache/commons/id DigestUtils.java Hex.java
   id/src/java/org/apache/commons/id/uuid UUID.java
   id/src/java/org/apache/commons/id/uuid/state
StateHelper.java
  Log:
  Change package declarations
  
  Revision  ChangesPath
  1.2   +1 -1  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/DigestUtils.java
  
  Index: DigestUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/DigestUtils.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DigestUtils.java  17 Dec 2004 14:22:36 -  1.1
  +++ DigestUtils.java  17 Dec 2004 14:25:00 -  1.2
  @@ -14,7 +14,7 @@
* limitations under the License.
*/ 
   
  -package org.apache.commons.id.uuid.utils;
  +package org.apache.commons.id;
   
   import java.security.MessageDigest;
   import java.security.NoSuchAlgorithmException;
  
  
  
  1.2   +2 -2  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/Hex.java
  
  Index: Hex.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/Hex.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Hex.java  17 Dec 2004 14:22:36 -  1.1
  +++ Hex.java  17 Dec 2004 14:25:00 -  1.2
  @@ -14,7 +14,7 @@
* limitations under the License.
*/ 
   
  -package org.apache.commons.id.uuid.utils;
  +package org.apache.commons.id;
   
   import org.apache.commons.id.DecoderException;
   import org.apache.commons.id.EncoderException;
  
  
  
  1.12  +3 -3  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/UUID.java
  
  Index: UUID.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/UUID.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- UUID.java 16 Dec 2004 16:50:45 -  1.11
  +++ UUID.java 17 Dec 2004 14:25:00 -  1.12
  @@ -21,9 +21,9 @@
   import java.util.StringTokenizer;
   
   import org.apache.commons.id.DecoderException;
  +import org.apache.commons.id.DigestUtils;
  +import org.apache.commons.id.Hex;
   import org.apache.commons.id.IdentifierUtils;
  -import org.apache.commons.id.uuid.utils.DigestUtils;
  -import org.apache.commons.id.uuid.utils.Hex;
   
   
   /**
  
  
  
  1.6   +3 -4  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/state/StateHelper.java
  
  Index: StateHelper.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/state/StateHelper.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- StateHelper.java  17 Dec 2004 11:39:20 -  1.5
  +++ StateHelper.java  17 Dec 2004 14:25:00 -  1.6
  @@ -30,9 +30,8 @@
   import org.apache.commons.id.uuid.Constants;
   import org.apache.commons.id.uuid.clock.Clock;
   import org.apache.commons.id.uuid.clock.OverClockedException;
  -import org.apache.commons.id.uuid.clock.SystemClockImpl;
  -import org.apache.commons.id.uuid.utils.DigestUtils;
  -import org.apache.commons.id.uuid.utils.Hex;
  +import org.apache.commons.id.DigestUtils;
  +import org.apache.commons.id.Hex;
   
   /**
* StateHelper provides helper methods for the uuid state
  
  
  

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

cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id DigestUtils.java Hex.java

[rwinston]

rwinston2004/12/17 06:22:36

  Added:   id/src/java/org/apache/commons/id DigestUtils.java Hex.java
  Log:
  Re-add utility classes under [id] package scope
  
  Revision  ChangesPath
  1.1  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/DigestUtils.java
  
  Index: DigestUtils.java
  ===
  /*
   * Copyright 2001-2004 The Apache Software Foundation.
   * 
   * Licensed under the Apache License, Version 2.0 (the "License");
   * you may not use this file except in compliance with the License.
   * You may obtain a copy of the License at
   * 
   *  http://www.apache.org/licenses/LICENSE-2.0
   * 
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an "AS IS" BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */ 
  
  package org.apache.commons.id.uuid.utils;
  
  import java.security.MessageDigest;
  import java.security.NoSuchAlgorithmException;
  
  
  /**
   * Operations to simplifiy common [EMAIL PROTECTED] 
java.security.MessageDigest} tasks.  This
   * class is thread safe.
   *
   * @author Apache Software Foundation
   */
  public class DigestUtils {
  
  /**
   * Returns a MessageDigest for the given algorithm.
   *
   * @param algorithm The MessageDigest algorithm name.
   * @return An MD5 digest instance.
   * @throws RuntimeException when a [EMAIL PROTECTED] 
java.security.NoSuchAlgorithmException} is caught,
   */
  static MessageDigest getDigest(String algorithm) {
  try {
  return MessageDigest.getInstance(algorithm);
  } catch (NoSuchAlgorithmException e) {
  throw new RuntimeException(e.getMessage());
  }
  }
  
  /**
   * Returns an MD5 MessageDigest.
   *
   * @return An MD5 digest instance.
   * @throws RuntimeException when a [EMAIL PROTECTED] 
java.security.NoSuchAlgorithmException} is caught,
   */
  private static MessageDigest getMd5Digest() {
  return getDigest("MD5");
  }
  
  /**
   * Returns an SHA digest.
   *
   * @return An SHA digest instance.
   * @throws RuntimeException when a [EMAIL PROTECTED] 
java.security.NoSuchAlgorithmException} is caught,
   */
  private static MessageDigest getShaDigest() {
  return getDigest("SHA");
  }
  
  /**
   * Calculates the MD5 digest and returns the value as a 16 element 
   * byte[].
   *
   * @param data Data to digest
   * @return MD5 digest
   */
  public static byte[] md5(byte[] data) {
  return getMd5Digest().digest(data);
  }
  
  /**
   * Calculates the MD5 digest and returns the value as a 16 element 
   * byte[].
   *
   * @param data Data to digest
   * @return MD5 digest
   */
  public static byte[] md5(String data) {
  return md5(data.getBytes());
  }
  
  /**
   * Calculates the MD5 digest and returns the value as a 32 character 
   * hex string.
   *
   * @param data Data to digest
   * @return MD5 digest as a hex string
   */
  public static String md5Hex(byte[] data) {
  return new String(Hex.encodeHex(md5(data)));
  }
  
  /**
   * Calculates the MD5 digest and returns the value as a 32 character 
   * hex string.
   *
   * @param data Data to digest
   * @return MD5 digest as a hex string
   */
  public static String md5Hex(String data) {
  return new String(Hex.encodeHex(md5(data)));
  }
  
  /**
   * Calculates the SHA digest and returns the value as a 
   * byte[].
   *
   * @param data Data to digest
   * @return SHA digest
   */
  public static byte[] sha(byte[] data) {
  return getShaDigest().digest(data);
  }
  
  /**
   * Calculates the SHA digest and returns the value as a 
   * byte[].
   *
   * @param data Data to digest
   * @return SHA digest
   */
  public static byte[] sha(String data) {
  return sha(data.getBytes());
  }
  
  /**
   * Calculates the SHA digest and returns the value as a hex string.
   *
   * @param data Data to digest
   * @return SHA digest as a hex string
   */
  public static String shaHex(byte[] data) {
  return new String(Hex.encodeHex(sha(data)));
  }
  
  /**
   * Calculates the SHA digest and returns the value as a hex string.
   *
   * @param data Data to digest
   * @return SHA digest as a hex string
   */
  public static String shaHex(String data) {
  return new String(Hex.encodeHex(sha(data)));
  }
  
  }
  
  
  
  1.1  
jakarta-commons-s

cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils DigestUtils.java Hex.java

[rwinston]

rwinston2004/12/17 06:16:26

  Removed: id/src/java/org/apache/commons/id/uuid/utils
DigestUtils.java Hex.java
  Log:
  Remove Utils classes from uuid package scope

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

Re: [id] cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils DigestUtils.java Hex.java

[Rory Winston]

No problem, will move them to package scope. Am open also to refactoring them 
into convenience methods onto other classes in [id].

"Jakarta Commons Developers List" <[EMAIL PROTECTED]> wrote:

> 
> Stephen Colebourne wrote:
> > Whatever is the most appropriate package. The main thing is that these 
> > method have been copied for our convenience and don't form part of the 
> > [id] public API. As such it might be that just individual methods should 
> > be copied onto specific [id] classes, rather than the whole codec class.
> > Stephen
> 
> I agree about the package scope.  IIRC, the secure session ID generator 
> does hex conversion, so could also use likely use the util hex class, so 
> I would slightly favor putting it at the top level.
> 
> Phil
> 
> 
> > - Original Message - From: "Rory Winston" <[EMAIL PROTECTED]>
> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> > Sent: Friday, December 17, 2004 11:49 AM
> > Subject: Re: [id] cvs commit: 
> > jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils 
> > DigestUtils.java Hex.java
> > 
> > 
> >> Stephen,
> >>
> >> I don't have any objections to making the utility classes 
> >> package-scoped under [id], however, I thought it might make more sense 
> >> to put them under uuid/ , as they are only used by the UUID classes. 
> >> What do you think?
> >>
> >> "Jakarta Commons Developers List" <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>
> >>
> >> _
> >> Sign up for eircom broadband now and get a free two month trial.*
> >> Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer
> >>
> >>
> >>
> >> -
> >> 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]
> 
> 



_
Sign up for eircom broadband now and get a free two month trial.*
Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer



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

Re: [id] cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils DigestUtils.java Hex.java

[Phil Steitz]

Stephen Colebourne wrote:
Whatever is the most appropriate package. The main thing is that these 
method have been copied for our convenience and don't form part of the 
[id] public API. As such it might be that just individual methods should 
be copied onto specific [id] classes, rather than the whole codec class.
Stephen
I agree about the package scope.  IIRC, the secure session ID generator 
does hex conversion, so could also use likely use the util hex class, so 
I would slightly favor putting it at the top level.

Phil

- Original Message - From: "Rory Winston" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Friday, December 17, 2004 11:49 AM
Subject: Re: [id] cvs commit: 
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils 
DigestUtils.java Hex.java


Stephen,
I don't have any objections to making the utility classes 
package-scoped under [id], however, I thought it might make more sense 
to put them under uuid/ , as they are only used by the UUID classes. 
What do you think?

"Jakarta Commons Developers List" <[EMAIL PROTECTED]> wrote:

_
Sign up for eircom broadband now and get a free two month trial.*
Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer

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


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

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

Re: [all] Clean up old modules from sandbox?

[Oliver Zeigermann]

I already deleted transaction, but left docs that redirect to commons
transaction in the proper section and a "MOVED TO COMMONS PROPER"
file. I thought this would be cleaner, but have no real objections
against removing it completely.

Oliver


On Fri, 17 Dec 2004 12:34:20 +, Rory Winston <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I was browsing through the commons-sandbox repository on cvs.apache.org and 
> it seems that there are a lot of unused and redundant entries in there that 
> should probably be removed, e.g. uid, chain (now promoted), transaction 
> (promoted), codec (ditto), daemon, etc.
> 
> Does anyone think it might be worthwhile removing these from CVS entirely, 
> and doing a sort of "xmas cleanout" of these old modules?
> 
> Cheers,
> Rory
> 
> _
> Sign up for eircom broadband now and get a free two month trial.*
> Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer
> 
> -
> 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]

cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task UUIDTask.java

[rwinston]

rwinston2004/12/17 04:19:29

  Added:   id/src/java/org/apache/commons/id/task UUIDTask.java
  Log:
  Add UUID generator Ant task
  
  Revision  ChangesPath
  1.1  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java
  
  Index: UUIDTask.java
  ===
  /*
   * Copyright 2002-2004 The Apache Software Foundation.
   *
   * Licensed under the Apache License, Version 2.0 (the "License");
   * you may not use this file except in compliance with the License.
   * You may obtain a copy of the License at
   *
   *  http://www.apache.org/licenses/LICENSE-2.0
   *
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an "AS IS" BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */
  
  package org.apache.commons.id.task;
  
  import org.apache.commons.id.IdentifierUtils;
  import org.apache.commons.id.uuid.UUID;
  import org.apache.tools.ant.BuildException;
  import org.apache.tools.ant.Task;
  import org.apache.tools.ant.types.EnumeratedAttribute;
  
  /**
   * Simple Ant task to generate a UUID.
   * $Id: UUIDTask.java,v 1.1 2004/12/17 12:19:29 rwinston Exp $
   */
  public class UUIDTask extends Task {

private String uuidVersion = "VERSION_FOUR";
private String name = "www.apache.org";
private String namespace = 
"urn:uuid:B4F00409-CEF8-4822-802C-DEB20704C365";

public void setName(String name) {
this.name = name;
}

public void setNamespace(String namespace) {
this.namespace = namespace;
}

public static class UUIDVersion extends EnumeratedAttribute {
public String[] getValues() {
return new String[] { "VERSION_ONE", "VERSION_THREE", 
"VERSION_FOUR", "VERSION_FIVE" };
}
}

public void setVersion(UUIDVersion newVersion) {
uuidVersion = newVersion.getValue();
}

public void execute() throws BuildException {
UUID uuid = null;
if (uuidVersion.equals("VERSION_THREE")) {
uuid = UUID.nameUUIDFromString(name, new 
UUID(namespace), UUID.MD5_ENCODING);
}
else if (uuidVersion.equals("VERSION_FIVE")) {
uuid = UUID.nameUUIDFromString(name, new 
UUID(namespace), UUID.SHA1_ENCODING);
}
else if (uuidVersion.equals("VERSION_FOUR")) {
uuid = (UUID) 
IdentifierUtils.UUID_VERSION_FOUR_GENERATOR.nextIdentifier();
}
else if (uuidVersion.equals("VERSION_ONE")) {
uuid = UUID.timeUUID();
}

log("Setting property:" + uuid.toString());
setProperty("uuid", uuid.toString());
}

private void setProperty(String name, String value) {
  getProject().setProperty(name, value);
  }

  }
  
  
  

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

[transaction]New feature: Upgrade and preference locks

[Oliver Zeigermann]

And another new feature: Commons Transaction now supports upgrade
/read/write locks

http://jakarta.apache.org/commons/transaction/apidocs/org/apache/commons/transaction/locking/ReadWriteUpgradeLockManager.html

and also general preference of locks:

http://jakarta.apache.org/commons/transaction/apidocs/org/apache/commons/transaction/locking/GenericLock.html#acquire(java.lang.Object,%20int,%20boolean,%20int,%20boolean,%20long)

Oliver

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

Re: [id] cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils DigestUtils.java Hex.java

[Stephen Colebourne]

Whatever is the most appropriate package. The main thing is that these 
method have been copied for our convenience and don't form part of the [id] 
public API. As such it might be that just individual methods should be 
copied onto specific [id] classes, rather than the whole codec class.
Stephen
- Original Message - 
From: "Rory Winston" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Friday, December 17, 2004 11:49 AM
Subject: Re: [id] cvs commit: 
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils 
DigestUtils.java Hex.java


Stephen,
I don't have any objections to making the utility classes package-scoped 
under [id], however, I thought it might make more sense to put them under 
uuid/ , as they are only used by the UUID classes. What do you think?

"Jakarta Commons Developers List" <[EMAIL PROTECTED]> wrote:

_
Sign up for eircom broadband now and get a free two month trial.*
Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer

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

[all] Clean up old modules from sandbox?

[Rory Winston]

Hi,

I was browsing through the commons-sandbox repository on cvs.apache.org and it 
seems that there are a lot of unused and redundant entries in there that should 
probably be removed, e.g. uid, chain (now promoted), transaction (promoted), 
codec (ditto), daemon, etc.

Does anyone think it might be worthwhile removing these from CVS entirely, and 
doing a sort of "xmas cleanout" of these old modules?

Cheers,
Rory



_
Sign up for eircom broadband now and get a free two month trial.*
Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer



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

cvs commit: jakarta-commons/transaction/src/java/org/apache/commons/transaction/util CounterBarrier.java

[ozeigermann]

ozeigermann2004/12/17 04:33:44

  Modified:transaction/src/java/org/apache/commons/transaction/util
CounterBarrier.java
  Log:
  Added a bit more of an explanation.
  
  Revision  ChangesPath
  1.2   +7 -4  
jakarta-commons/transaction/src/java/org/apache/commons/transaction/util/CounterBarrier.java
  
  Index: CounterBarrier.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/transaction/src/java/org/apache/commons/transaction/util/CounterBarrier.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CounterBarrier.java   17 Dec 2004 00:11:38 -  1.1
  +++ CounterBarrier.java   17 Dec 2004 12:33:44 -  1.2
  @@ -25,6 +25,9 @@
   
   /**
* Simple counter barrier to make a sequence of calls from different threads 
deterministic.
  + * This is very useful for testing where you want to have a contious flow 
throughout 
  + * different threads. The idea is to have an ordered sequence of numbers 
where n can not be executed before 
  + * n-1 has not been.
* 
* @version $Revision$
*/
  
  
  

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

[transation][all] Tiny concurrency testing class

[Oliver Zeigermann]

Folks,

I know this is nothing new, but I have just created a tiny class that
helps you make concurrent scenarios deterministic. This is very useful
for testing where you want to have a contious flow throughout
different threads. The idea is to have an ordered sequence of numbers
where n can not be executed before n-1 has not been:

Here are the API docs

http://jakarta.apache.org/commons/transaction/apidocs/org/apache/commons/transaction/util/CounterBarrier.html

and here are the sources

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/transaction/src/java/org/apache/commons/transaction/util/CounterBarrier.java?rev=1.1&view=markup

As an example have a look at the testPreference() method in

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking/GenericLockTest.java?rev=1.4&view=markup

Getting the same sutff done with synchronized blocks is something that
will make you need medical attendance very soon.

Hope I am not already getting on anybodies nervers with me stuff and cheers,

Oliver

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

cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task uuid.xml

[rwinston]

rwinston2004/12/17 04:28:36

  Added:   id/src/java/org/apache/commons/id/task uuid.xml
  Log:
  Add build script for UUIDTask
  
  Revision  ChangesPath
  1.1  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/uuid.xml
  
  Index: uuid.xml
  ===
  
  
  
  
  
  
  

  


 
 

 

 


  
  
  
  

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

cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task - New directory

[rwinston]

rwinston2004/12/17 04:18:57

  jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task - New directory

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

cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id DecoderException.java EncoderException.java

[rwinston]

rwinston2004/12/17 03:43:04

  Added:   id/src/java/org/apache/commons/id DecoderException.java
EncoderException.java
  Log:
  Add Exception classes for encoding/decoding operations
  
  Revision  ChangesPath
  1.1  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/DecoderException.java
  
  Index: DecoderException.java
  ===
  /*
   * Copyright 2001-2004 The Apache Software Foundation.
   * 
   * Licensed under the Apache License, Version 2.0 (the "License");
   * you may not use this file except in compliance with the License.
   * You may obtain a copy of the License at
   * 
   *  http://www.apache.org/licenses/LICENSE-2.0
   * 
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an "AS IS" BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */ 
  
  package org.apache.commons.id;
  
  /**
   * Thrown when a Decoder has encountered a failure condition during a decode. 
   * 
   * @author Apache Software Foundation
   * @version $Id: DecoderException.java,v 1.1 2004/12/17 11:43:04 rwinston Exp 
$
   */
  public class DecoderException extends Exception {
  
  /**
   * Declares the Serial Version Uid.
   * 
   * @see http://c2.com/cgi/wiki?AlwaysDeclareSerialVersionUid";>Always Declare 
Serial Version Uid
   */
  private static final long serialVersionUID = 1L;
  
  /**
   * Creates a DecoderException
   * 
   * @param pMessage A message with meaning to a human
   */
  public DecoderException(String pMessage) {
  super(pMessage);
  }
  
  }  
  
  
  
  
  1.1  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/EncoderException.java
  
  Index: EncoderException.java
  ===
  /*
   * Copyright 2001-2004 The Apache Software Foundation.
   * 
   * Licensed under the Apache License, Version 2.0 (the "License");
   * you may not use this file except in compliance with the License.
   * You may obtain a copy of the License at
   * 
   *  http://www.apache.org/licenses/LICENSE-2.0
   * 
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an "AS IS" BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */ 
  
  package org.apache.commons.id;
  
  /**
   * Thrown when there is a failure condition during the encoding process.  This
   * exception is thrown when an Encoder encounters a encoding specific 
exception
   * such as invalid data, inability to calculate a checksum, characters 
outside of the 
   * expected range.
   * 
   * @author Apache Software Foundation
   * @version $Id: EncoderException.java,v 1.1 2004/12/17 11:43:04 rwinston Exp 
$
   */
  public class EncoderException extends Exception {
  
  /**
   * Declares the Serial Version Uid.
   * 
   * @see http://c2.com/cgi/wiki?AlwaysDeclareSerialVersionUid";>Always Declare 
Serial Version Uid
   */
  private static final long serialVersionUID = 1L;
  
  /**
   * Creates a new instance of this exception with an useful message.
   * 
   * @param pMessage a useful message relating to the encoder specific 
error.
   */
  public EncoderException(String pMessage) {
  super(pMessage);
  }
  }  
  
  
  
  

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

cvs commit: jakarta-commons/transaction build.xml project.xml

[ozeigermann]

ozeigermann2004/12/17 04:09:32

  Modified:transaction build.xml project.xml
  Log:
  Incremented version
  
  Revision  ChangesPath
  1.8   +1 -1  jakarta-commons/transaction/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-commons/transaction/build.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- build.xml 14 Dec 2004 12:13:35 -  1.7
  +++ build.xml 17 Dec 2004 12:09:32 -  1.8
  @@ -20,7 +20,7 @@
 
 
   
  -  
  +  
 
 
 
  
  
  
  1.4   +1 -1  jakarta-commons/transaction/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/transaction/project.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- project.xml   21 Nov 2004 09:50:18 -  1.3
  +++ project.xml   17 Dec 2004 12:09:32 -  1.4
  @@ -10,7 +10,7 @@
 Commons Transaction
 Commons Transaction
   
  -  1.0rc1
  +  1.1b1-pre
   
 
http://jakarta.apache.org/commons/${pom.artifactId.substring(8)}/
 org.apache.commons.${pom.artifactId.substring(8)}
  
  
  

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

cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/state StateHelper.java

[rwinston]

rwinston2004/12/17 03:39:20

  Modified:id/src/java/org/apache/commons/id/uuid/state
StateHelper.java
  Log:
  Remove dependency on [codec]
  
  Revision  ChangesPath
  1.5   +5 -4  
jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/state/StateHelper.java
  
  Index: StateHelper.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/state/StateHelper.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- StateHelper.java  31 May 2004 06:56:50 -  1.4
  +++ StateHelper.java  17 Dec 2004 11:39:20 -  1.5
  @@ -24,14 +24,15 @@
   import java.util.Random;
   import java.util.StringTokenizer;
   
  -import org.apache.commons.codec.DecoderException;
  -import org.apache.commons.codec.binary.Hex;
  -import org.apache.commons.codec.digest.DigestUtils;
  +import org.apache.commons.id.DecoderException;
   import org.apache.commons.discovery.tools.DiscoverClass;
   import org.apache.commons.id.uuid.Bytes;
   import org.apache.commons.id.uuid.Constants;
   import org.apache.commons.id.uuid.clock.Clock;
   import org.apache.commons.id.uuid.clock.OverClockedException;
  +import org.apache.commons.id.uuid.clock.SystemClockImpl;
  +import org.apache.commons.id.uuid.utils.DigestUtils;
  +import org.apache.commons.id.uuid.utils.Hex;
   
   /**
* StateHelper provides helper methods for the uuid state
  
  
  

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

cvs commit: jakarta-commons-sandbox/id project.xml

[rwinston]

rwinston2004/12/17 03:51:58

  Modified:id   project.xml
  Log:
  Remove dependency on codec
  
  Revision  ChangesPath
  1.12  +0 -4  jakarta-commons-sandbox/id/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/id/project.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- project.xml   14 Dec 2004 12:39:58 -  1.11
  +++ project.xml   17 Dec 2004 11:51:58 -  1.12
  @@ -90,10 +90,6 @@
 commons-logging
 1.0.3
   
  -
  -  commons-codec
  -  1.3
  -
 
   
 
  
  
  

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

DO NOT REPLY [Bug 32743] - [betwixt] Adding DEBUG to log4j.properties results in IndexOutOfBoundsException

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32743


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Adding DEBUG to |[betwixt] Adding DEBUG to
   |log4j.properties results in |log4j.properties results in
   |IndexOutOfBoundsException   |IndexOutOfBoundsException




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [id] cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils DigestUtils.java Hex.java

[Rory Winston]

Stephen,

I don't have any objections to making the utility classes package-scoped under 
[id], however, I thought it might make more sense to put them under uuid/ , as 
they are only used by the UUID classes. What do you think?

"Jakarta Commons Developers List" <[EMAIL PROTECTED]> wrote:




_
Sign up for eircom broadband now and get a free two month trial.*
Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer



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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Emmanuel Bourg]

I don't think this alternative has been proposed, the additional 
features could also be provided by a decorator, something like :

ExtendedLog log = new ExtendedLog(LogFactory.getLog(Foo.class));
or
ExtendedLog log = LogFactory.getExtendedLog(Foo.class));
For localization, ExtendedLog would create a LogMessage and pass it to 
the log implementation. It could also add a code guard to reduce object 
creations:

public void debug(String key, Object[] params) {
if (log.isDebugEnabled()) {
log.debug(new LogMessage(key, params));
}
}
For log implementations supporting i18n, the key is extracted from the 
LogMessage and searched in a resource bundle. For other implementations, 
LogMessage.toString() returns the key and the parameters concatenated.

Just some thoughts :) For i18n I think I like Curt's solution of parsing 
the message in the implementation.

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

Re: [proposal] avoiding jar version nightmares

[Oliver Zeigermann]

On Fri, 17 Dec 2004 00:43:55 -, Stephen Colebourne
<[EMAIL PROTECTED]> wrote:
> Basically, I believe there is no simple solution to this. The best we can do
> is to encourage tools like clirr which check a library for binary
> compatability. This should become part of each components standard tests.

I am sure clirr is a nice tool, but the knowledge that 1.x is
incompatible with 2.0 is of no big use when you have both in your
classpath.

Oliver

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

[GUMP@brutus]: Project commons-id (in module jakarta-commons-sandbox) failed

[Adam Jack]

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-id 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-id :  Commons Identifier Package


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-id-17122004.jar] identifier set to project name
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html
Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-17122004.jar
-
symbol  : class DecoderException 
location: class org.apache.commons.id.uuid.utils.Hex
public byte[] decode(byte[] array) throws DecoderException {
  ^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils/Hex.java:146:
 cannot resolve symbol
symbol  : class DecoderException 
location: class org.apache.commons.id.uuid.utils.Hex
public Object decode(Object object) throws DecoderException {
   ^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils/Hex.java:180:
 cannot resolve symbol
symbol  : class EncoderException 
location: class org.apache.commons.id.uuid.utils.Hex
public Object encode(Object object) throws EncoderException {   
   ^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/UUID.java:189:
 cannot resolve symbol
symbol  : class DecoderException 
location: class org.apache.commons.id.uuid.UUID
} catch (DecoderException de) {
 ^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils/Hex.java:57:
 cannot resolve symbol
symbol  : class DecoderException 
location: class org.apache.commons.id.uuid.utils.Hex
throw new DecoderException("Odd number of characters.");
  ^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils/Hex.java:85:
 cannot resolve symbol
symbol  : class DecoderException 
location: class org.apache.commons.id.uuid.utils.Hex
throw new DecoderException("Illegal hexadecimal charcter " + ch + " 
at index " + index);
  ^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils/Hex.java:151:
 cannot resolve symbol
symbol  : class DecoderException 
location: class org.apache.commons.id.uuid.utils.Hex
throw new DecoderException(e.getMessage());
  ^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid/utils/Hex.java:185:
 cannot resolve symbol
symbol  : class EncoderException 
location: