Re: [Vote] Bill Barker - Commons Proper Committer

[Costin Manolache]

+1

Costin



-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
Sent: 30. prosinac 2003 14:54
To: [EMAIL PROTECTED]
Subject: [Vote] Bill Barker - Commons Proper Committer

Howdy,
I think everyone knows Bill Barker already ;)  He's done a 
ton of work on tomcat and related jakarta projects, including 
some in the commons-sandbox.  Now that commons-daemon is in 
the Commons Proper, I'd still like to have his help and I 
think he'd like to help as well, but we need a vote it seems. 
So here's my +1.

[ X ] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] 
-1, perhaps not, because

Yoav Shapira
Millennium ChemInformatics


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

Re: [VOTE] Promote commons-sandbox-daemon to Commons Proper

[Costin Manolache]

+1

Costin

Shapira, Yoav wrote:

> 
> Howdy,
> The tomcat team would like to promote commons-daemon to the
> commons-proper and issue a 1.0 release to serve as a dependency for
> tomcat 5.0 stable.
> 
> We have been using commons-daemon for a while, and there are no open
> bugs filed against it.  We'll go through with the proper release
> process, plan, and vote, as always, of course.  In fact, I'll probably
> be the release manager for it.
> 
> Please vote on this promotion ;)  Thanks,
> 
> Yoav Shapira
> 
> ---
> Vote:  Promote commons-attributes to commons proper
> [ X ] +1 I am in favor of the move, and will help support it
> [ ] +0 I am in favor of the move, but am unable to help support it
> [ ] -0 I am not in favor of the move
> [ ] -1 I am against this proposal (must include a reason).
> ---
> 
> 
> 
> 
> This e-mail, including any attachments, is a confidential business
> communication, and may contain information that is confidential,
> proprietary and/or privileged.  This e-mail is intended only for the
> individual(s) to whom it is addressed, and may not be saved, copied,
> printed, disclosed or used by anyone else.  If you are not the(an)
> intended recipient, please immediately delete this e-mail from your
> computer system and notify the sender.  Thank you.




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

Re: [modeler] Introspection only for primitives?

[Costin Manolache]

Davanum Srinivas wrote:

> Costin,
> 
> Am +1 on fewer dependencies...Yes, i am writing a small program for
> "register the mbeans, introspection it and write the descriptor". That's
> when i found the missing constructor info.

I don't know if you noticed the small ant task that writes the .ser
descriptors ? It may help.

> #1 - Can you please review the fixes that i checked in yesterday? (one for
> #constructors and
> another for javabeans/additional-java-types).

I'm extremely busy - hopefully in few weeks I'll have more time and I can
help more. The fixes seemed ok.

> #2 - Currently MbeansDescriptorsIntrospectionSource does not do anything
> #for notifications. Does
> it need to? Is there some standard pattern to look for - for
> notifications?

I don't know any good pattern - I was thinking at some point to use the 
java bean event/listener patterns ( addXXXListener() -> XXX notification )
and do some conversion between the 2 event models. But it seems too
complicated and I'm not sure people should use the old event model with
JMX.

If you have any idea - it would be great to add some support. 

> #3 - Should we mark digester as optional in build/docs?

+1

I think we can even remove the dependency completely - the main reason to
keep it was a backup, in case something doesn't work with the new code.

Again - digester is a great tool, but for modeler I think it is better to 
use DOM. 

Cotin

> 
> Thanks,
> dims
> 
> --- Costin Manolache <[EMAIL PROTECTED]> wrote:
>> Craig R. McClanahan wrote:
>> 
>> >> If i hear you right...If the Java class is a well behaved JavaBean
>> >> then we should not need a mbeans-descriptor.xml. Right?
>> > 
>> > Not exactly.  I think you still want a place define the metadata
>> > information about your managed bean -- in the same way that BeanInfo
>> > lets
>> > you supply that externally about a standard JavaBean.  We can probably
>> > figure out ways to synthesize default metadata if there is no
>> > descriptor.
>> > 
>> > My comment was really directed at why the class you are proposing a
>> > patch
>> > for exists in the first place.  The original version of Modeler used
>> > Commons Digester to parse the descriptor file, and Digester can already
>> > deal with the sorts of conversions you are patching to achieve -- plus
>> > a
>> > whole bunch more.  But Costin decided he didn't like it, so he
>> > abstracted out a mini-Digester (with fewer features, but probably a
>> > little faster and smaller), which you're now left with having to patch
>> > to get back to where we already were.
>> 
>> I made a proposal, nobody -1 - so I did it :-)
>> 
>> Faster wasn't the only goal - but also fewer dependencies, so modeler can
>> be placed in the parent loader and it's smaller.
>> Also ability to use different sources for metadata - like introspection (
>> to allow modeler to be used without a mbeans-desriptors.xml for the
>> simple use cases ), or .ser files which seem much faster than parsing
>> xml.
>>  
>> 
>> >> That was exactly my point :) I want to use modeler in axis and was
>> >> wondering if i really needed the mbeans-descriptor.xml files.
>> 
>> IMO - no, you don't need it.
>> 
>> But it's good to use it to associate descriptions with
>> attributes/operation or to support more complex types and operations.
>> 
>> 
>> >> Of course if the tool can generate a sample mbeans-descriptor.xml
>> >> given a set of java classes then folks can edit it to their hearts
>> >> content.
>> 
>> I think that should be easy to do, just register the mbeans,
>> introspection will be automatically used to extract metadata and all you
>> have to do is write the descriptor.
>> 
>> Costin
>> 
>> >>
>> >> BTW, can someone commit my patch? or shall i go ahead and commit them?
>> >> (fixes for both JavaBean params and extend the list of supported types
>> >> to include everything mentioned in the "open mbeans" spec)
>> >>
>> >> -- dims
>> >>
>> > 
>> > Craig
>> > 
>> > 
>> >> --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> >
>> >> > On Mon, 21 Jul 2003, Costin Manolache wrote:
>> >> >
>> >> > > Date: Mon, 21 Jul 2003 22:28:45 -0700 (PDT)
>> >> > > From: Costin Manolache <[EMAIL PROTECT

Re: [modeler] Introspection only for primitives?

[Costin Manolache]

On Mon, 21 Jul 2003, Davanum Srinivas wrote:

> Costin,
> 
> Right now modeler just allows parameters that are listed in the supportedType method 
> when we use
> introspection.
> 
> #1 - How difficult/easy is it to allow other data types? (Why is this list of items 
> limited?)

It's not difficult to add more data types. We added mostly commont types - 
I think we should cover at least the types in "open mbeans" part of the 
spec.

We could also add a generic mechanism to allow pluggable types ( i.e. to 
add more types to the list of supportedTypes ).


> #2 - How about other beans as parameters? (if you look at
> test\org\apache\commons\modeler\demo\mbeans-descriptors.xml, StandardServer has 
> addService,
> removeService etc that take in a service as parameter)

Sure - if it doesn't complicates things too much. 

BTW, one of the reason we have the "supportedTypes" is to avoid 
introspection extracting too much stuff.


Costin


> Thanks,
> dims
> 
> =
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 
> __
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 

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

Re: [VOTE] Yoav Shapira (yoav@apache.org) for modeler committer

[Costin Manolache]

robert burrell donkin wrote:

> (i don't want to set a president about nominating committers for
> components by people who aren't committers for that component but i think
> that this is a special case since folks responsible for the component have
> already given a +1 before the VOTE.)
> 
> i don't know too much about yoah other than he's a committer for tomcat
> and for the log4j sandbox (so i can't provide the traditional eulogy) but
> recommendations by costin and craig are good enough for me (see
> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=105478999528602&w=2)
> .
> 
> so i'd like to nominate Yoav Shapira ([EMAIL PROTECTED]) as a commons
> committer for modeler.
> 
> here's my +1.
> 
> - robert

Thanks Robert :-)

( and +1 as well ).

Costin


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

Re: [Modeler] [VOTE] Proposal: Modeler 1.1 Release

[Costin Manolache]

Shapira, Yoav wrote:

> 
> Hi,
> I would like to propose a release of the Modeler commons component:
> release 1.1.  The latest version of the release notes is available here:
> 
> http://cvs.apache.org/viewcvs/jakarta-commons/modeler/RELEASE-NOTES-1.1.
> txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
> 
> There are no open items againast Modeler in the bug database.  I myself
> am not a committer for Modeler (I hope I don't need to be in order to be
> the release manager -- I'll find out soon enough ;)).
> 
> So, please vote ;)


+1

I'm very busy at work - but I'll try to help if there is any problem. The
milestone seems to work fine, and almost no change happened since that.

BTW, I would also add a +1 on adding you as a commons and commons-modeler
committer :-)


Costin




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

[Modeler][Vote] 1.1 release

[Costin Manolache]

I think modeler is now relatively stable.

It is still backward compatible with the 1.0 API - so even if a lot
of things were added/changed, I think it should be called 1.1.

I would like to build the first milestone of 1.1 and release it - so 
other projects can use something stable ( tomcat5.0 or 4.1 ). 

If I get the 3 +1 votes, I will also like to start marking all stable
APIs - including the ones from 1.0 - and add few deprecations. 

My proposal is to use @since tag as a mark for a supported API - any
method not having a @since tag should be considered as not frozen.

New features:
- support for extracting metadata using introspection
- reads the metadata using DOM or .ser files
- ant tasks for JMX operations
- support for mlet-like files ( same syntax as the ant tasks - but doesn't
require ant )
- many bug fixes and small performance improvements

Votes ?

Costin

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

Re: [VOTE] Release vote for JXPath 1.1

[Costin Manolache]

+1

Costin

Stephen Colebourne wrote:

> +1, and +1 on Roberts additions.
> Stephen
> 
> - Original Message -
> From: "robert burrell donkin" <[EMAIL PROTECTED]>
> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 05, 2003 8:27 PM
> Subject: Re: [VOTE] Release vote for JXPath 1.1
> 
> 
>> +1
>>
>> i did notice a couple of small things (i'm currently revising the release
>> notes).
>>
>> the apache license (both in source and in the distribution) appears to
>> have 'Copyright (c) 1999-2001'. it would be nice if it showed the correct
>> year.
>>
>> also, it would be better if the MANIFEST.MF were changed to something
> like:
>>
>> Extension-Name: org.apache.commons.jxpath
>> Specification-Title: "Jakarta Commons JXPath"
>> Specification-Vendor: "Apache Software Foundation"
>> Specification-Version: "1.1"
>> Implementation-Title: "org.apache.commons.JXPath"
>> Implementation-Vendor: "Apache Software Foundation"
>> Implementation-Version: "1.1"
>>
>> - robert
>>
>> On Wednesday, March 5, 2003, at 01:07 AM, Dmitri Plotnikov wrote:
>>
>> > I'd like to call for a release vote on JXPath 1.1 .  It has been stable
>> > for
>> > a while, and there are no outstanding bugs against it.  All the goals
>> > we had
>> > initially stated for this release have been met.
>> >
>> > The release candidate build is at
>> >
>> > http://jakarta.apache.org/builds/jakarta-commons/release/commons-
>> > jxpath/v1.1
>> >
>> > +1 (this is my vote)
>> >
>> > Thank you,
>> >
>> > Dmitri
>> >
>> >
>> > -
>> > 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: VFS and JNDI

[Costin Manolache]

James Strachan wrote:

>> This pretty much reflects the current VFS architecture - the missing
>> piece
> is
>> the JDNI adapter.  The goal is to minimise the layering between the
> providers
>> and the user API (be that JNDI or VFS), rather than sitting one API on
>> top
> of
>> the other.  I think with a bit of reorganising, we can end up with a
>> reasonably performant VFS for both APIs.  I'd be willing to bias
> performance
>> in favour of JNDI, if that were necessary.
> 
> This sounds good. Just a thought about another idea; what if VFS also
> provided an optional JNDI-extension interface. i.e. provide an API on top
> of JNDI's Context / DirContext so that the VFS-like API can be used or the
> underlying JNDI API all from the same objects. Or to put that another way,
> would implementing Context & DirContext & Name as part of the VFS API be a
> good thing?


I think we are all talking about the same thing - from different angles.

Both wrappers are needed:
- a VFS wrapper on top of a JNDI provider ( like tomcat's, or Sun minimal
file provider ) would allow people who want to use the VFS-oriented API,
and may absorb differences in attribute namming and support some
conventions for random access. 

- a JNDI wrapper on top of VFS allow people who are familiar with the JNDI
API to use it, and allows JNDI tools ( browsers, ant tasks, etc ) to
manipulate the VFS.

- A JNDI wrapper for VFS providers will allow people to write providers
using a simpler API ( and have them exposed as JNDI via the VFS->JNDI
wrapper ). 
- In the same sense, one or several base classes and utils to simplify 
the creation of JNDI providers are usefull. All JNDI providers would be
useable as VFS - just like all VFS providers could be used as JNDI.

I think the main point is to make it as easy as possible to create JNDI
drivers - and to be able to use drivers from any source. It 
doesn't matter how JDNI driver is implemented, as long as it follows the
spec. 

What's important is to treat VFS as:
- a collection of drivers that can be used by JNDI application
- a set of tools to simplify the creation of JNDI drivers for VFS-like
systems
- a set of APIs to porvide a VFS-centric view of JNDI or VFS drivers.

I think we do need a separate component to:
- simplify creation of generic JNDI drivers ( like config file abstraction,
etc).
- implement JNDI drivers for common config files
- eventually map to and from jdk1.4 prefs
- provide high-level JNDI tools - replication, deep copy, ant tasks, etc.
Those will operate on both VFS and any other kind of JDNI ( config, etc ).

Remy - are you still on this list :-) ?

Costin





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

Re: VFS and JNDI

[Costin Manolache]

Adam Murdoch wrote:

>> JNDI is bundled with JDK1.3+ and is available to JDK1.1. It is well
>> documented ( books, etc ), required ( or strongly supported ) in Servlet
>> environments. I could say it is ubiquous. I can hardly see any reason
>> why someone would use a different API to use a VFS.
> 
> For the same reason you'd use a different API for anything: a better fit
> for the task, and a model that is a better match for the user's mental
> model.
> It's argueable whether the current VFS API achieves this over JNDI.  It
> largely comes down to personal preference, I think.  I certainly prefer
> the VFS API to JNDI for file access.  But I can understand how others
would
> prefer to use JNDI.  And I can picture cases where I'd rather use JNDI
> too.

For "user mental model" - learning a new  model is usually more painful than
applying a model you know. And most people are used with JNDI and with the 
"content + attributes". 

It is possible to add a wrapper on top of JNDI to provide (or emulate) a
different API if you want. There is one particular case that is not very
well covered by JNDI - random access to a file. That's where some special
extensions or API would be needed. 


> What I'd like to do is see if we can support both.  There's a few
> approaches
> we could take.  My preferred option is to do the interoperability at the
> provider level.  Something like this:

> - Move the provider agnostic stuff into a core framework.  This would
> provide services like caching, replication, event handling, federation,
> and so on. - Sit the framework on top of the providers, using a custom
> provider API (not the JNDI provider API).
> - Sit the VFS API on top of the framework.
> - Sit a JDNI provider adapter on top of the framework.

That is basically wasting the benefits of JNDI... 
- A well-defined standard for implementing providers. 
- ability to do caching/replication in a generic way, not specific to VFS
( a JNDI cache can be used for caching LDAP auth  results for example ).
- built-in event handling, federation, etc.

JNDI is an API - i.e. it provides all those things. 


> This pretty much reflects the current VFS architecture - the missing piece
> is
> the JDNI adapter.  The goal is to minimise the layering between the
> providers and the user API (be that JNDI or VFS), rather than sitting one
> API on top of
> the other.  I think with a bit of reorganising, we can end up with a
> reasonably performant VFS for both APIs.  I'd be willing to bias
> performance in favour of JNDI, if that were necessary.

The architecture of VFS seems close enough to JNDI - so why not use 
JNDI as the API ? 

Something like:
- refactor VFS providers to become JNDI providers
- create a VFS wrapper on top of JNDI - for backward compat and for people
who preffer to use VFS API
- all generic tools will be implemented using JNDI - this way they'll
be usefull in general JNDI, not only for VFS ( like deep copy of a JNDI
tree, replication, caching ). All this can be abolutely standalone
components ( if possible with ant wrappers :-)
- move the fs and cache from tomcat and merge. 

The only "framework" that is needed is a set of base classes and utils
to simplify the implementation of JNDI drivers. ( i.e. utils ).

Costin










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

RE: [logging] Class Loading Problems

[Costin Manolache]

Shapira, Yoav wrote:

>>can I add myself to logging comiters list and fix this problem ?
> 
> No, you can't make yourself a committer.  You are welcome to open bug

A commons committer can participate in any common component. 

If you check in something and other people disagree - they can -1 it.


>>It is not possible to solve all problems with current API.
> 
> That sounds very determined.  I disagree, but I'm not interested enough
> to get into a debate.

There is no need for a debate. Most likely changes to the API that are not
backward compatible will get a quick -1.

We can allways improve the API - but I suggest individual proposals and
good arguments :-) 
For example - I wouldn't support the 24 new methods in Log, but I would
be +1 on adding a LogRecord class. There are multiple opinions about
everything, but we can probably find middle ground.

Costin


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

Re: [logging] Class Loading Problems

[Costin Manolache]

Juozas Baliuka wrote:
 
> It is not my opinion about logging, but this problem exists and reported a
> few times for logging and lang
> (possible it nothing about this in bugzilla). Some solutionsare proposed a
> few months ago too.
> 
> I have "karma" on commons, but as I understand I need to ask active
> commiters before to add myself to status.html  and commit something.

You only have to inform active committers, and you already did :-)

I'm waiting for the commits. 


Costin



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

Re: VFS and JNDI

[Costin Manolache]

Henri Yandell wrote:

> 
> 
> On Wed, 26 Feb 2003, Costin Manolache wrote:
> 
>> James Strachan wrote:
>>
>> > From: "Costin Manolache" <[EMAIL PROTECTED]>
>> >
>> > It'd me nice to move the Tomcat JNDI implementation into Commons so it
>> > can be a general purpose JNDI implementation for those that want/need
>> > one.
>>
>> +1 - if someone has the time :-)
>>
>> It is pretty well separated - but there are few things that are specific
>> to tomcat ( caching is specific to resources, etc). I started a small
>> refactoring - with the goal of making it completely separate in
>> jakarta-tomcat-connectrs/naming. A second goal was to make it much easier
>> to write plugins. It is pretty low on the priority list for me - but if
>> other people are interested I can make some time to help.
> 
> I'm happy to work/help on this. I've another little crappy jndi project
> and James has hassled me about doing the right thing and refactoring
> tomcat-jndi before.

The nice thing about JNDI is that the API and the provider API are as stable
as it can get, and it proved to allow very low coupling. 

In other words - there is no need for an "all or nothing" or dependencies, 
it can be done step by step. 

I already started a refactoring in j-t-c ( I'll commit today the latest
changes ), my main focus was on having some base classes that make it much
easier to implement drivers. I choose Name over String because I feel it can
be made more efficient and may support recycling and MessageBytes-based
implementation. I think it would be nice to have another set of base
classes based on Strings - duplication is good :-)

One big issue is refactoring the cache - right now it is very specific to
the tomcat use-case, and to the filesystem provider ( casts, etc ). 


Costin





  




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

Re: VFS and JNDI

[Costin Manolache]

James Strachan wrote:

> From: "Costin Manolache" <[EMAIL PROTECTED]>
>> Hanasaki JiJi wrote:
>>
>> > Thinking out loud here  What do you think?
>> > 1. turn the VFS providers into JNDI SPI
>> > 2. implement VFS via JNDI or the JNDI SPI's directly
>>
>> +1
>>
>> Tomcat abstracts the file system using JNDI - it may be worth taking
>> a look.
> 
> It'd me nice to move the Tomcat JNDI implementation into Commons so it can
> be a general purpose JNDI implementation for those that want/need one.

+1 - if someone has the time :-)

It is pretty well separated - but there are few things that are specific to
tomcat ( caching is specific to resources, etc). I started a small
refactoring - with the goal of making it completely separate in
jakarta-tomcat-connectrs/naming. A second goal was to make it much easier
to write plugins. It is pretty low on the priority list for me - but if
other people are interested I can make some time to help. 

Costin



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

Re: VFS and JNDI

[Costin Manolache]

Nicola Ken Barozzi wrote:

>> They are very similar.  JNDI is a little more general: a namespace of
>> Objects. VFS is a little more specific: a hierarchy of files.
>> 
>> VFS does not try to be as universal as JNDI does, even though there is
>> going to be plenty of overlap (find by name, create, delete, get/set
>> attribute,
>> etc).  VFS adds things that don't make sense under JNDI's more general
>> model (get content as a stream, content signing, copy a tree, converting
>> to/from java.io.File, etc), and does things in a way that reflects how
>> files get used (as opposed to how generic namespaces of Objects get
>> used).
> 
> And many don't want JNDI just to use VFS, just like we use io.File.
> But I agree that a JNDI wrapper to VFS would be very cool.

JNDI is bundled with JDK1.3+ and is available to JDK1.1. It is well
documented ( books, etc ), required ( or strongly supported ) in Servlet
environments. I could say it is ubiquous. I can hardly see any reason 
why someone would use a different API to use a VFS. 

The only reason to chose a different API if you _implement_ a VFS is the
extra complexity ( JNDI does a pretty good job at keeping simple things
simple for _user_ ). However in the long run, the many small details that
JNDI covers and VFS doesn't might matter - I'm talking about security, the
very tricky isolation on class loaders ( java:comp ), federation,
optimizations ( caching, avoiding GC, etc ).


Costin



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

Re: VFS and JNDI

[Costin Manolache]

Nicola Ken Barozzi wrote:

> Why not make Tomcat a TLP and make this a subproject?
> 

I think we are quite happy in jakarta :-)

The place for any component/library that is general purpose is (IMHO) 
in jakarta-commons. However, since there is some hope that
jakarta walls will go gradually down - I think keeping the code
in tomcat or moving it will be the same thing :-)

Costin







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

Re: VFS and JNDI

[Costin Manolache]

Adam Murdoch wrote:

> On Wed, 26 Feb 2003 02:17 am, Hanasaki JiJi wrote:
>> Any comparisons on VFS vs JNDI?  seems very similar to me.
> 
> They are very similar.  JNDI is a little more general: a namespace of
> Objects. VFS is a little more specific: a hierarchy of files.

The namespace of Objects is just 1/2 of JNDI ( the Context ).
The other half is objects with attributes (DirContext)- that maps very well
with files. As I mentioned in my previous post - there are few JNDI-based
VFS impl. already ( from the sample filesystem JNDI provider to the 
more featured and optimized one in tomcat )


> etc).  VFS adds things that don't make sense under JNDI's more general
> model (get content as a stream, content signing, copy a tree, converting
> to/from java.io.File, etc), and does things in a way that reflects how
> files get used (as opposed to how generic namespaces of Objects get used).

Get content as stream is certainly part of JNDI. There is also a pretty 
sophisticated system for conversion. The higher level utils should be
separated ( copy a tree, or more special operations on the content ). 

JNDI also have a reasonably good policy-based security, federation ( nice if
you work with multiple domains with different naming conventions ).

The real issue is stable, well known API - versus some extra complexity due
to the fact that it's more generic and optimizable. Of course, stability
has 2 sides - it's good because its frozen, well known
and tested - but bad because you can't change it.

Costin

  



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

Re: VFS and JNDI

[Costin Manolache]

Hanasaki JiJi wrote:

> Thinking out loud here  What do you think?
> 1. turn the VFS providers into JNDI SPI
> 2. implement VFS via JNDI or the JNDI SPI's directly

+1

Tomcat abstracts the file system using JNDI - it may be worth taking 
a look. That means any JNDI based VFS would be easy to plug into tomcat,
and you can get some pretty well tested and optimized modules for .war and
file system.

You may also take a look at the caching and other optimizations that Remy
put into the jndi layer. 

One of the big benefits of using JNDI as the API for the VFS is the
stability of the API, and the huge number of people who are already 
familiar with it. 

A disadvantage is the greater complexity - even if you don't have to
implement all JNDI methods, there is a bit more work. However Name and
few other things allow some very interesting optimizations that are just
imposible otherwise.

If VFS switches to JNDI - it may be worth merging some of the code from
tomcat. 

Costin
 


> 
> Adam Murdoch wrote:
>> On Wed, 26 Feb 2003 02:17 am, Hanasaki JiJi wrote:
>> 
>>>Any comparisons on VFS vs JNDI?  seems very similar to me.
>> 
>> 
>> They are very similar.  JNDI is a little more general: a namespace of
>> Objects. VFS is a little more specific: a hierarchy of files.
>> 
>> VFS does not try to be as universal as JNDI does, even though there is
>> going to be plenty of overlap (find by name, create, delete, get/set
>> attribute,
>> etc).  VFS adds things that don't make sense under JNDI's more general
>> model (get content as a stream, content signing, copy a tree, converting
>> to/from java.io.File, etc), and does things in a way that reflects how
>> files get used (as opposed to how generic namespaces of Objects get
>> used).
>> 
> 



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

Re: [Logging] Internationalization enhancement proposal

[Costin Manolache]

Andrew McConnell wrote:

> I miss your point about different styles of ResourceBundles. Can you
> elaborate?

If you pass in the key - the logger is expected to locate the bundle
and do the substitution. How do you specify where is the key stored ( which
resource bundle ) ? And AFAIK not everyone uses the same layout and style
for the ResourceBundle.

You could pass in the RB as a param, but with the signatures you posted
I just don't see how it could work without additional config or complexity.


> I disagree with the notion that i18n has no place in logging
> infrastructures for the following reason:

I didn't say that. 

I said that logging and i18n shouldn't be mixed up in the same API.


> Despite the well-documented limitations of the JDK 1.4 API, Sun did
> something very useful by exposing the raw log message ("before
> localization and formatting") within the LogRecord, as well as all of
> the parameters that are ultimately handed to the ResourceBundle. In my

That's exactly my sugestion - instead of adding 24 new methods, just
define a LogRecord class ( that can be added to c-l without _any_ backward
compat problems ). The LogRecord method will have a toString() method doing
the normal formatting - but loggers that are I18N-aware could use the 
information directly.

All log() methods take Object as param - it can be a String, and most
current loggers are just converting it to String. But it can be a LogRecord
or something else.

If a LogRecord would be used - performance-critical code could benefit from
not having to do the concatentation of strings and conversions, and a smart
logger could store the fields directly ( I'm thinking about access.log as
example, or general "logs" that are generated by apps, not only for debug). 

Costin


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

Re: [Logging] Internationalization enhancement proposal

[Costin Manolache]

Adding 24 methods and the requirement that the logger deals with
internationalization doesn't seem right. The second part is worse - 
each app uses different styles of ResourceBundles - and you mix 
very different domains.

A much simpler solution - with no API change in Log - is to 
use the fact that the message is an Object, and define conventions
for what it should be for "internationalized" messages.
For example, add a "I18NMessage" class that holds message and params - 
and has a toString() method that returns something printable.

Then add a second class that deals with I18N - I don't think the right
place is logging ( again - this is a complex issue ), but some helper
could be included in logging as long as it doesn't impose too many 
restrictions on how the ResourceBundles are organized. 

I know some people preffer to use message IDs (ints), some use XML files,
and so on.

Another alternative: create a separate interface ( in a i18n component )
that uses Log for the actual display of the message. 

Implementing 24 methods ( even if it is cut&paste ) doesn't seem like fun.

Costin



Andrew McConnell wrote:

> I would like to propose that a number of methods be added to the Log
> interface to meet the suggestion outlined in the commons-logging user
> guide: "Perhaps more direct support for internationalizing log messages
> can be introduced in a future or alternate version of the Log interface"
> 
> It seems to me that the JDK1.4 logging support for i18n is an excellent
> model.
> 
> To implement, a single overloaded getInstance() method needs to be added
> to LogFactory so that a resource bundle can be associated with a Log.
> Several methods would need to be added to the Log interface to provide a
> way to pass parameters to the resource bundle for rendering. For
> example, for trace-level messages, add:
> 
> trace(Object message, Object param);
> trace(Object message, Object[] params);
> trace(Object message, Throwable t, Object param);
> trace(Object message, Throwable t, Object[] params);
> 
> All levels would need analogous methods.
> 
> The implementation of these and existing methods should change slightly,
> to first attempt to retrieve the log messages from a resource bundle (if
> a bundle exists). If the key cannot be found, return Object.toString(),
> otherwise use ResourceBundle.getString() to create the displayed
> message.
> 
> While this adds numerous (24!) methods to the Log interface, the
> development effort required to implement is limited due to the
> intelligent structure of the Log impls already written, and having this
> full set of methods may be the easiest for commons-logging users.
> 
> There is a slight performance penalty, due to having to add a check to
> see if a resource bundle is set. Perhaps there is an alternate
> implementation that can avoid this penalty altogether such as having the
> LogFactory return a different implementation of the Log depending on if
> a resource bundle is needed?
> 
> 



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

Re: [vote] moving commons-sql, commons-dbcp and commons-dbutils to db.apache.org

[Costin Manolache]

Robert Leland wrote:

> Costin Manolache wrote:
>> Martin Poeschl wrote:
>> 
>> 
>>>as the name indicates db.apache.org is for db related projects.
>>>the db project is new but people will look for db related stuff there
>>>and not at jakarta-commons .. so it makes sense to move the projects to
>>>db.apache.com
>> 
>> 
>> 
>> And people who are already use it will look for it in jakarta-commons.
>> 
>> I know tomcat uses ( and bundles ) commons-dbcp.jar, and I would preffer
>> it remains in jakarta-commons. For the others - I don't care.
> 
> It seems keeping the package name org.apache.commond.dbcp is the most
> important, for now.
> 
> Automatically redirecting the page
> http://jakarta.apache.org/commons/dbcp.html to
> db.apache.org/dbcp should be trasparent.

Again - why should we do this ?

At this moment I'm -1 for commons-dbcp.jar, and -0 on the others.
Moving code for the sake of moving code is wrong - you won't increase
the community or the quality of the code by moving it.

Since commons-dbcp.jar is used by at least one jakarta project - I need more
arguments on the benefits of such a move. 


Costin 


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

Re: httpclient client certificate authentication

[Costin Manolache]

Eric Johnson wrote:

> Hello,
> 
> I was looking into using the httpclient in an
> application that requires client certificate
> authentication.  According to the JSSE documentation,
> the mechanism for doing this is to get your
> SSLSocketFactory from an SSLContext, which allows you
> to specify the KeyManager and TrustManager.  I plan on
> writing my own implementation of the
> SecureProtocolSocketFactory that takes a SSLContext as
> an argument for a constructor and has a
> SSLSocketFactory field.  I just thought I'd pass this
> along as it might be a nice addition to
> SSLProtocolSocketFactory.  I have no need of it, but
> if anyone has an idea of how to specify a particular
> HostNameVerifier similar to SUN's method in
> HttpsUrlConnection, that might also be a nice
> addition.


You can check the FakeTrusteSocketFactory in xml-axis - it 
implements what you (seem to) need.

Costin


> 
> BTW, if anyone has a strong opinion on whether I
> should even consider http-client for my application,
> please feel free to share it with me.  I realize it's
> only at alpha2, but my options have pretty well been
> narrowed down to rolling my own feature starved
> httpclient, mucking about with the sun.net... client,
> or using the commons-httpclient.
> 
> Regards,
> 
> Eric
> 
> __
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day
> http://shopping.yahoo.com



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

Re: [vote] moving commons-sql, commons-dbcp and commons-dbutils to db.apache.org

[Costin Manolache]

Martin Poeschl wrote:

> as the name indicates db.apache.org is for db related projects.
> the db project is new but people will look for db related stuff there
> and not at jakarta-commons .. so it makes sense to move the projects to
> db.apache.com


And people who are already use it will look for it in jakarta-commons.

I know tomcat uses ( and bundles ) commons-dbcp.jar, and I would preffer 
it remains in jakarta-commons. For the others - I don't care.
 


Costin


> martin
> 
> Juozas Baliuka wrote:
> 
>>Why do we need to move commons-dbcp ?
>>Is it  new, more active community for commons-dbcp in db.apache.org ?
>>- Original Message -
>>From: "Martin Poeschl" <[EMAIL PROTECTED]>
>>To: <[EMAIL PROTECTED]>
>>Sent: Thursday, February 13, 2003 6:02 PM
>>Subject: [vote] moving commons-sql, commons-dbcp and commons-dbutils to
>>db.apache.org
>>
>>
>>  
>>
>>>I would like to move the following packages to db.apache.org
>>>
>>>o commons-sql
>>>o commons-dbcp
>>>o commons-dbutils
>>>
>>>should we move them to db-commons or should they become db subprojects??
>>>
>>>we can use irc.werken.com#db to discuss
>>>
>>>martin
>>>
>>>
>>>
>>>-
>>>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: [logging] To depend or not to depend?

[Costin Manolache]

James Strachan wrote:

> Maybe using introspection on the Log implementation might be easier to add
> incrementally to Log implementations without breaking backwards
> compatibility.

Introspection or JMX ( which is the other name for introspection :-).

Each LogFactory or Log can support a lot of features in a backward
compatible way by using JMX. There is absolutely no reason to change the
Log interface - it does what it should do. Adding another interface may be
a solution - but I don't think it is needed in most cases - and certainly
not for management operations.

Costin



> 
>> Adding a new method might be OK in a 2.x release (although I don't feel a
>> particular compulsion towards it), but would be against the spirit of
>> Commons support for backwards compatibility in a 1.x releaese; so I'd
>> definitely be -1 there.
> 
> So you might not be -1 if if it were a 2.x release change?
> 
> James
> ---
> http://radio.weblogs.com/0112098/
> 
> __
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com



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

Re: [logging] To depend or not to depend?

[Costin Manolache]

Ryan Hoegg wrote:

> Commons-logging-api.jar is 16K, which would increase our applet JAR size
> by 60+%.  That's not acceptable for a system level service like logging.

You can remove the jdk14 logging and the simple logger - and jar only 
the interface and a dummy factory.


Costin


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

Re: [CLI] new design possibly?

[Costin Manolache]

Nicola Ken Barozzi wrote:

>> import org.apache.commons.logging.Log;
>> 
>> public class SomeService {
>> // container sets the logger to be used using IOC
>> public void setLog(Log log);
>> }
> 
> Is that what packages using Commons Logging do?
> Every single package in Commons that uses CL uses the static accessor.

Commons-logging can be used both ways. Each package can decide
if it wants to use IoC or not. You can choose to not use any
package that is not "pure IoC" - if that's what you want - but
you can't force others to write IoC. 

 
> What you say is correct, and I would like it to be a possible method to
> enable logging to the component.

Nothing stops you from adding any method you want in components or 
framework or anything else, and nothing forces you to use the inpure
static accessor.

> /**
>   * Components that need to log can implement this interface to
>   * be provided Loggers.
>   *
>   * @author Avalon Development Team
>   */
> public interface LogEnabled
> {
>  /**
>   * Provide component with a logger.
>   *
>   * @param logger the logger. Must not be null.
>   */
>  void enableLogging( Logger logger );
> }

That's wonderfull. You have solved your problem, you have your
interface and you can use it if you like it  - and we can
use the static accessor. 


> Back on track: yes, it can make sense to evaluate Commons Logging as a
> facade for Loggers, but it's a major break in our main code contracts.
> We are discussing about Avalon 5, and Configuration and Logging are a
> major part of that discussion. You are invited  :-)

Thanks, but at least I have found the answers for both logging and
configuration. ( commons-logging API and JMX - plus ant setter patterns 
where JMX is not available ). 


> So let me say the opposite: is Commons Logging advocating IOC?

No. It only advocates a log interface. How you use it is your choice.

> What is the preferred method to get a Logger?
> Come on, be fair. It's the static accessor.

Preffered by most people - yes. I don't think commons-logging itself
has any preferences - it's just a piece of code. 

But again - nothing stops avalon from using a method that is different 
that what other people preffer. 


> We don't want a dependency on a package that has a static accessor to
> get a logger. You may not need it, but why not put this possibility at
> all.

Look - if you can't accept that people want to use a static accessor,
maybe you shouldn't use commons-logging and any of the commons or jakarta
packages that make this choice. 

Nobody forces you or avalon users to use static methods.


>> How did you do that? By writing yet another logging abstraction? :-)
> 
> We had our Logger with a worldful of utility methods for easy logging
> without having to +++ strings together by hand all the time.

Technically - commons-logging doesn't requires you to use Strings.
The param is an Object - it can be a StringBuffer or a String [] or 
any other entity. You'll need some special appenders in log4j ( not 
sure about jdk14 logging ) - but the API is _not_ string based.

Costin


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

Re: [VOTE] Promote "el" from commons-sandbox to commons-proper

[Costin Manolache]

I have a "deja-vu" sentiment, I remember we already voted on this.

But +1 again.

Costin

Jan Luehe wrote:

> Please cast your vote on the promotion of the commons-el package from
> "commons sandbox" to "commons proper".
> 
> The commons-el package contains the EL evaluator code from JSP 2.0.
> See jakarta-commons-sandbox/el/PROPOSAL.html for more details.
> 
> commons-el nightly source and binary builds are available at:
> 
>   http://cvs.apache.org/builds/jakarta-commons/nightly/commons-el/
>   
> Regards,
> 
> Jan




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

Re: [VOTE] Promote "el" from commons-sandbox to commons-proper

[Costin Manolache]

robert burrell donkin wrote:

> the following concerns me about the proposal:
> 
> (4) Initial Committers
> The initial committers will be identical to those of the Standard Taglib
> project.
> 
> i'm unhappy with this since it implies that all current taglib committers
> will be grandfathered in. a list of the people being proposed would be
> much better.

And what's wrong with that 

Any jakarta committers who wishes to become a commons committer should
be able to do it with minimal effort. Jakarta itself is moving toward a 
"single community" model ( or at least that's my understanding ). 

Costin




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

Re: A new VOTE list commoons-vote

[Costin Manolache]

Ortwin Glück wrote:

> -1
> 
> Filtering can be done in most mail clients if the right subject prefixes
> are used. A separate list is not necessary.
> 
> i.e. use [VOTE][Codec] and not just [VOTE]
> 
> for votes interesting for all projects you could use [VOTE][COMMONS] or
> [VOTE][ALL] or similar

I agree with Craig and others who point that vote should be where the
developers are - if someone is interested in the development of a component,
he should track the dev list.

I do think it is bad to abuse the mail filtering and subject line parsing.

I remain +1 on spliting the commons list based on component, with votes and
discussions on that component going to the component list.


Costin


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

Re: Time for more mailing lists ?

[Costin Manolache]

I wasn't planning to "force" anyone to move to a different list - 
the reason I started this thread is that I felt overwhelmed with the
ammount of mail, and it seems commons keeps growing. I don't think it
hurts if someone asks this question every few months :-)

Given that we now have a wiki and many people start blogging - it 
is possible that the pressure on the mail list will be reduced, so it
doesn't hurt waiting few more months. 

To throw another idea: another way to classify commons ( and not only ) 
is by the level of activity. Projects like commons-logging are stable, with
very few changes or discussions. Other projects are in full development.
It may be worth having a "jakarta-stable" - with low traffic, focused on
the components that are "done". It is very easy for an email related to a 
low-actity project to get lost in the current traffic.

Costin

 


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

Time for more mailing lists ?

[Costin Manolache]

This has been discussed in the past - but the traffic on commons is 
getting bigger as we add more very active components.

We could split the list based on category - expression languages (jxpath,
jexl, jsp-el, etc ), util libraries ( logging, discovery, modeler,
collections, etc ). 

Opinions ? Should we vote ?

Costin   


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Grant] Ant problems

[Costin Manolache]

Stefan Bodewig wrote:

> On Mon, 27 Jan 2003, bob mcwhirter <[EMAIL PROTECTED]> wrote:
> 
>> I haven't tracked ant very closely lately, but if/when it allows us
>> to manage ant properties external to the o.a.t.ant.Project backed by
>> some external structure, then grant itself will become useless.
> 
> CVS HEAD should give you that ability, see
> src/main/org/apache/tools/ant/PropertyHelper.java.
> 
> Costin has been trying to design his work in a way that will allow you
> to use a different ProjectHelper to do this for 1.5 as well, but I'm
> not sure whether it will actually work that way.

It does - AFAIK. 

The code is in ant/proposals/embed - right now embed works _only_ for
ant1.5 ( since 1.6 already has the same or better code ).
It is a ProjectHelper plugin - if you build embed and place it in
ant1.5 CLASSPATH it'll enable support for "dynamic properties", import
and few other features.

The interfaces are not frozen - I'm sure Stefan and other people will review
it and some improvments will happen. 

Support for JXPath and Velocity dynamic properties is in proposals/embed -
you can use it as example.

Costin 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Promote jexl from commons sandbox to commons

[Costin Manolache]

robert burrell donkin wrote:

> jexl is a simple expression language for accessing java objects. it is
> used extensively by jelly. jexl has been (relatively) stable for a while.
> jelly is pushing towards it's first release. the time therefore seems
> right for jexl to be promoted to the commons.
> 
> - 8< -
> Vote to promote the "Jexl" component from Commons Sandbox to Commons
> Proper:
> 
> [X] +1 I am in favor of this action and will help
> [ ] +0 I am in favor of this action but cannot help
> [ ] -0 I am not in favor of this action
> [ ] -1 I am opposed to this action and here is why:
> - 8< -

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [functor] Next step

[Costin Manolache]

Rodney Waldhoff wrote:

> ...
> Functors are a (arguably *the*) central organizing principle behind
> functional programming languages like these.

And that's the reason why commons-functor needs to be aproached as a 
fundamental interface, and we should require a very strong support and 
participation across Apache in it's implementation. 

Functor may affect all apache java projects - must extension mechanisms can
be implemented using functors. Each apache project defines 2-3 callback
mechanisms.

In order for this to happen they need to be flexible and powerfull enough
to cover the existing patterns, and provide at least the same features
as found in the various projects. 

One thing I wouldn't want to see is "yet another callback mechanism".

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [general][lang] monolithic components considered harmful

[Costin Manolache]

Rodney Waldhoff wrote:

> Try this: fill in the blanks in the following
> 
>   If you want to ___, you may want to use ___.
> 
> For example:
> 
> * interact with JavaBeans via reflection and introspection; beanutils
> * translate between JavaBeans and XML; betwixt
> * parse command line arguments; cli
> * work with abstract data structures; collections
> * parse xml configuration files; digester
> * discover services that have been externally configured; discovery
> * pool database connections; dbcp
> * implement an XML scripting language; jelly
> * process multipart/form-data HTTP requests; fileupload
> * interact with HTTP servers; httpclient
> * work with XPath expresssions in java; jxpath
> * functional test HTTP applications; latka
> * write debugging and logging messages; logging
> * support JMX via Model MBeans; modeler
> * pool objects; pool
> * validate user input; validator
> 
> Now try it with [lang], [util] or [pattern] and any scope signficantly
> different from "develop software in Java".

If you define "functor" the way Craig did - an interface that 
could be used as a common hook mechanism - I would gladly change my vote
to +1.

And it will be: "if you want a hook mechanism, use commons-functor"

There are few requirements I have:

1. You must be well aware that this is an interface package. 
It just won't work with 3 +1 votes as a regular commons interface.
You need buy-in and participation from significant apache projects.

2. It shouldn't get too much into implementing functors, just define
the interface and tools ( and maybe wrappers for existing hook
mechanisms ).

3. It should be able to support existing patterns:
- iterative invocation of functors as well as recursive ( 
valve/interceptors:-)
- be able to replace existing mechanisms
- JDK1.1 compat ( so it could be used someday in Ant ).

It could go the same way as logging and define adapters and wrappers
for other interfaces used for this ( in tomcat, ant, axis, etc ). 
It would be ideal if bidirectional wrappers would be provided so
that functors are useable in existing systems.

This must be config-neutral and support regular bean patterns ( so
it can be managed by modeler and integrated in existing apps ).

I also have a problem with the name "functor". I would rather have
"callback", "hook", "extension point", "plugin" ( if this is what you
have in mind ).

In other words: one hook mechanism to rule them all :-)

Costin










--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[Jelly][Grant][JXPath] Ant PropertyHelper

[Costin Manolache]

I don't know if you track ant-dev - I made a small change that 
would allow pluggable properties. In few weeks I hope this 
will stabilise ( and nobody will -1 the entire concept ). 

This would provide the same features as Grant. I don't know
what is better - to depend on ant HEAD or depend on Grant,
but if you preffer the ant PropertyHelper, I can provide
the patches.

I would also like to move the JXPath/Jelly PropertyHelpers
from ant/proposal/embed to jxpath jelly.

( this is based on the assumption that PropertyHelper will stick ).

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[modeler] update

[Costin Manolache]

I did few small changes to make the source of the 
modeler information pluggable ( i.e. the code that reads
the xml files ). The interface is not yet final, my main
goal was to allow it to work with DOM ( for example if
we want modeler in the main loader and we don't want
all dependencies ).

It seems modeler never used beanutils directly ( it does
its own introspection based on the JMX spec ), so it will
be possible to use modeler with dependencies only one
commons-logging and JAXP.

Regarding speed - it doesn't seem much slower when using DOM.
On my machine it is actually 20% faster ( at least with the
crimson included in JDK1.4 ). Most likely this is due to
direct calls (instead of introspection). I'm testing with
JDK1.4 - other VMs and parsers may have different characteristics.
In any case - it should be easy to use digester if DOM turns to
be slower.

I would also like to change the auto-loading of descriptors
( I added it few weeks ago ). Instead of loading from META-INF
( or in addition ), we should also look in the same package
with the class that needs metadata. This allows a more flexible
layout and provides almost the same features.

The next step I want to make is to let it load  and 
/ directly. You probably noticed the ant tasks 
that support this syntax - they allow you to create, set and 
call mbeans inside an ant build file. I would like to do the
same, but without ant. 
In addition I would like to also support the syntax used by jboss - 
it seems clean and I don't want to reinvent what's already available.

The end goal is to allow modeler to read jmx components - like those 
proposed for tomcat.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Costin Manolache]

+1

The code is already part of 2 jakarta projects ( taglibs and tomcat ), it
has a clear community and is very likely it'll be actively supported. 
A perfect match for jakarta-commons.

It would be nice if JEXL and EL would share some code ( and even better
if JEXL would support the EL syntax ). But that's not required by
jakarta-commons.


Costin

Jan Luehe wrote:

> I'd like to resume discussion on a proposal circulated by James
> Strachan on March 13, 2002, about turning the implementation of JSTL's
> expression language (EL) into a reusable component and moving it from
> the Standard Taglib, an implementation of JSTL hosted by
> jakarta-taglibs, to jakarta-commons, in order to make it available to
> a larger number of projects.
> 
> James' original proposal received some positive feedback from the
> taglibs-dev community. Below is a draft proposal for a formal
> submission to jakarta-commons, following the format of the
> jakarta-commons charter at http://jakarta.apache.org/commons/charter.html.
> 
> (0) Rationale
> 
> The JSP Standard Tag Library (JSTL), version 1.0, introduced the
> concept of an Expression Language (EL), whose main goal is to provide
> page authors with an easy way to access and manipulate application
> data without requiring the use of scriptlets
> 
> JSP 2.0 adopted the EL specification from JSTL, and expanded its
> scope: EL expressions are no longer limited to JSTL action attributes,
> but may be used in any standard or custom action attribute declared to
> accept a runtime expression. In addition, EL expressions may now also
> be used directly in template text outside of any actions. JSP 2.0 also
> added an important feature to the EL specification: EL functions,
> which allow page authors to invoke static methods in Java classes from
> EL expressions. Additionally, JSP 2.0 allows programmatic access and
> customization of the EL evaluator through a set of standard interfaces
> and abstract classes.
> 
> Currently, there are a number of projects (including Tomcat 5 and Java
> Server Faces) that leverage the EL implementation of the Standard
> Taglib. In addition, there seems to be interest in leveraging the EL
> in the context of scripting workflow activities using custom tag
> libraries.
> 
> In order to make the EL implementation available to Tomcat 5, the
> Tomcat team defined a new "ant" target for the Standard Taglib that
> builds just the EL portion and packages it in a JAR file
> ("jsp20el.jar") which is stored in Tomcat's common/lib directory. This
> approach has always been considered an interim solution only, until
> the EL implementation would move from the Standard Taglib to a more
> visible location such as jakarta-commons.
> 
> (1) Scope of the package
> 
> The package shall provide an implementation of the Expression Language
> specification which is part of the JSP 2.0 standard.
> 
> (1.5) Interaction with other packages
> 
> The package shall provide an implementation of the standard interfaces
> and abstract classes of the javax.servlet.jsp.el package, which is
> defined in the JSP 2.0 specification.
> 
> (2) Identify the initial source for the package
> 
> The initial codebase will be taken from the Standard Taglib project
> hosted at jakarta-taglibs. The source of the Standard Taglib is
> available as part of the jakarta-taglibs nightly source distribution
> at http://jakarta.apache.org/builds/jakarta-taglibs/nightly/src/
> 
> (2.1) Identify the base name for the package
> 
> The base name of the package shall be org.apache.commons.el
> 
> (2.2) Identify the coding conventions for this package
> 
> The package follows Sun's Java coding conventions (see
> http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html).
> 
> (3) Identify any Jakarta-Commons resources to be created
> 
> (3.1) Mailing list
> 
> The package shall use the jakarta-commons mailing list.
> 
> (3.2) CVS repositories
> 
> The package shall use a root branch of the jakarta-commons CVS.
> 
> (3.3) Bugzilla
> 
> The package shall be listed as the "EL" component under the "Commons"
> project in Bugzilla.
> 
> (3.4) Jyve FAQ (when available)
> 
> n/a
> 
> (4) Identify the initial set of committers to be listed in the Status
> File.
> 
> The initial set of committers will be identical to the set of
> committers of the Standard Taglib project.
> 
> 
> Thoughts?
> 
> Jan




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [logging] Adding jndi java:env support

[Costin Manolache]

Craig R. McClanahan wrote:

> I'm neutral on prefix versus suffix (although prefix feels a little more
> in keeping with the hierarchical naming I tend to use for logging).  But
> that raises an important consideration -- do the underlying logging
> implementations we support deal gracefully with a ":" syntax in a logger
> name?  In particlar, could I configure a logger for "DOMAIN:" and have it
> apply to all loggers in that domain?  I'm wondering if we might want to
> use a period (".") as the connector instead.

I don't know - that's why I ask :-)

We should certainly use a syntax that is compatible with both jdk1.4 and
log4j. We could encode the name - but it needs to be easy to type ( I hate
 %xx ).

The only reason for suffix is easier configuration - but I'm not even sure 
it's easier :-)  Can log4j or jdk14 support 
  *.org.apache.commons.level=DEBUG  ?
The use case of setting the log level on a component in multiple 
applications seems more common.

We can leave the log name unchanged and try to play 
some tricks with the logger config. Changing the log name seemed
like the easiest solution.

We can associate the application name with the hierarchy - but
again I don't know how this would work from a config perspective.

Ceki - any idea ? 

The use case I have in mind is a container ( like tomcat ), with
several applications, a JMX-based config tool and some centralised
config file ( eventually managed by the JMX tool or editor or some
other UI ). The apps shouldn't have to do anything - they should just
see the normal log patterns as a standalone app today. 

( of course - this should also work for jdk14 or other 
loggers - even if log4j is the best :-)

Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [logging] Adding jndi java:env support

[Costin Manolache]

The big issue is the behavior. 

My proposal was: if java:env/comp/LoggingDomain is set ( as a String ), 
it'll be used as a prefix in all loggers ( that don't have a prefix ).
The syntax for the logger names will become: 
   DOMAIN:LOGGER
And all loggers will have to be configured with this name ( if running
in a container env with LoggingDomain support ).

This is very important - and I would like to see more opinions. Maybe
we should use the domain as a suffix instead of prefix ? Then you would
have: 
  org.apache.foo:host:8080/examples
as the log name, but you can set org.apache.foo.* to debug and enable
the loggers in all apps.

The prefix is cleaner, but the suffix may be easier to configure.

For implementation - I'm in no hurry ( I would like to have it before
tomcat5 is released - but that's not very close ). And I can use 
reflecion or a hook, if needed.


Costin 

Richard Sitze wrote:

> I'll wait for the formal call to vote before I start voting, BUT I support
> the following:
> 
> +  release a 1.0.3 before any major code changes
> +  JNDI
> 
> -  NO API changes
> -  NO new runtime dependencies, and I'd like to be able to build, even if
> I cannot test it.
> 
> 
> 
> ***
> Richard A. Sitze
> 
> 
> 
> 
> sounds like a good plan.
> 
> this sounds (to me) like a change big enough to call for a new (major?)
> version.
> 
> (i'm not a cvs expert) but from what i can see there have been some small
> changes since the last release. maybe a quick bugfix 1.0.3 release would
> be a good idea before adding making this change.
> 
> - robert
> 
> On Thursday, December 12, 2002, at 03:29 AM, Costin Manolache wrote:
> 
>> Based on Ceki's email - I think it would be a good idea to add
>> this mechanism in the default logging factory.
>>
>> My proposal is to insert a lookup for
>>
>>  java:comp/env/CommonsLoggingFactory
>>
>> at the top of the discovery chain. If such a factory exists, it'll
>> be used to create the logger. If not, we'll continue with the
>> normal mechanism.
>>
>> The big downsize is that we'll add a compile dependency on
>> JNDI ( the code can catch ClassNotFound - and run even if
>> JNDI is not present ).
>>
>> This will allow containers using commons-logging to better enforce
>> isolation between apps.
>>
>> In addition, I think we should add an optional "domain name" prefix.
>> If such a prefix is set ( for example in
>> java:comp/env/CommonsLoggingDomain)
>> then it'll be added in front of every log name that is created.
>>
>> For example, if the container will set myHost:8080/myApp/ as a prefix,
>>  logs created in that app will be named:
>>   myHost:8080/myApp/org.apache.
>>
>>
>> As a note, web.xml allows you to define and set a number of
>> jndi entries. This could also be used to allow user-based tuning,
>> but in general the container settings should be able to
>> take preference .
>>
>> Costin
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]
> .
>> org>
>> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
> .
>> org>
>>
> 
> 
> --
> To unsubscribe, e-mail:   <
> mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <
> mailto:[EMAIL PROTECTED]>




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

Re: [logging] Adding jndi java:env support

[Costin Manolache]

Craig R. McClanahan wrote:

> 
> 
> On Wed, 11 Dec 2002, Costin Manolache wrote:
> 
>>
>> The big downsize is that we'll add a compile dependency on
>> JNDI ( the code can catch ClassNotFound - and run even if
>> JNDI is not present ).
>>
> 
> Why couldn't we use reflection to avoid the compile-time dependency as
> well?  After all, you like that pattern everywhere else :-).

That's not necesarily true - I usually like a hook that plugs a class
with the dependency, and conditional compilation. ( like in jdk11 compat
package in tomcat ). Since JNDI is included in JDK1.3 and available for 
1.1 - and it can be detected at runtime - I would rather use it directly
and keep the code simpler.

Costin



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

Re: JNDI based selection

[Costin Manolache]

Ceki Gülcü wrote:

> OK, the solution I presented solves the "VOLUNTATRY separation of
> logging" problem. It can be further refined to address the
> "MANDATORY separation of logging" problem Costin mentions.

> Costin suggested the use of string prefixes to enforce mandatory
> separation which is quite a nice idea.
> 
> One possible approach is to have the string values stored in JNDI to
> be prefixed by the host name if requested to so by the  element
> within the server.xml file. Thus, the log4j repository selector can
> provide a host specific logger hierarchy for the hosts that request
> the service. Moreover, the host specific logger hierarchy cannot be
> spoofed by other hosts living in the same container. Looks like we
> have got a solution to the mandatory logging separation problem.

The prefix should be set by container - and it should probably be 
the "canonical" name of the application. 

One remaining issue is if we allow apps to open loggers of a different
app. getLog() needs to check if a prefix is already present - and
if so do a permission check ( that would need JDK1.2 - but can be 
implemented in a LogFactoryImpl ).


> Now, this solution requires that the Container directly provide
> support for log4j. Will Tomcat do that? Probably not, at least not
> until all the other containers do. How ironic would that be?

This has nothing to do with other containers. 

If we add the jndi stuff to commons-logging, tomcat will set the 
"prefix" env and it can also set other jndi properties that 
are needed. Both log4j and commons-logging could use this info. 
And of course, if LogFactory implements this lookup, then 
it'll separate the loggers regardless of implementation ( we 
may have a problem if both c-l and log4j are adding the prefix :-)

We already include commons-logging-api and we're in process of
migrating all the internal logging to c-l, and separating the
loggers is an important issue. 

I think it would be a good idea to include log4j and log4j 
specific hooks in tomcat5 - but that's an issue for tomcat-dev.
There are already some discussions about the content of the
5.0 release and increased modularity ( and a better hook system
and support for JMX ). 

Costin

 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[logging] Adding jndi java:env support

[Costin Manolache]

Based on Ceki's email - I think it would be a good idea to add
this mechanism in the default logging factory.

My proposal is to insert a lookup for
 
 java:comp/env/CommonsLoggingFactory

at the top of the discovery chain. If such a factory exists, it'll
be used to create the logger. If not, we'll continue with the
normal mechanism.

The big downsize is that we'll add a compile dependency on 
JNDI ( the code can catch ClassNotFound - and run even if 
JNDI is not present ). 

This will allow containers using commons-logging to better enforce
isolation between apps.

In addition, I think we should add an optional "domain name" prefix.
If such a prefix is set ( for example in java:comp/env/CommonsLoggingDomain)
then it'll be added in front of every log name that is created.

For example, if the container will set myHost:8080/myApp/ as a prefix,
 logs created in that app will be named:
  myHost:8080/myApp/org.apache.


As a note, web.xml allows you to define and set a number of 
jndi entries. This could also be used to allow user-based tuning, 
but in general the container settings should be able to 
take preference . 

Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JNDI based selection

[Costin Manolache]

Ceki Gülcü wrote:

> 
> I have been a long time critic of commons-logging API for its class
> loader based approach of selecting the logging implementation. See for
> example my http://qos.ch/logging/thinkAgain.html document. I think
> more reliable solutions exist. In particular, you might want to
> consider the JNDI based solution discussed in
> http://qos.ch/logging/sc.html.

The class loader based _default_ approach is not perfect, but
you can plug other factories. 

I like the JNDI solution, excelent idea. 

One comment: application isolation is not a voluntary thing. If we want to 
isolate the loggers you can't allow the application to specify what logger 
it wants in web.xml and hope they'll not use the same name. 

Using java:env is a great solution, probably it needs an external
config ( server.xml or the logging config file ).

Costin


> 
> 
> I suggest that you begin reading "thinkAgain.html" first and then read
> sc.html. You are welcome to use the heretical ideas contained therein
> to your advantage or alternatively ignore them altogether. Your
> comments, constructive or otherwise, are welcome.
> 
> Regards,
> 
> --
> Ceki




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [configuration] XmlConfiguration

[Costin Manolache]

There are 2 existing APIs to abstract config storage: one is the JDK1.4 
prefs, the other one is JNDI. Each provides plugin mechanisms for
arbitrary storage ( XML, props - win registry, ldap, etc ).

There are several different philosophies for configuring applications -
push and pull are the major directions. 

There are 2 APIs config ( push-style ): JMX and JavaBeans. 
( for Pull - either JNDI or prefs can be used directly ).

I think we have more than enough. I don't see myself working on (or using)
any new config API. JMX and Beans for push are pretty clear. Prefs
is not acceptable ( since it's tied into JDK1.4 ), but JNDI is widely
used and extremely flexible. ( the only downside is the huge number 
of methods a provider must implement - that can be solved with some
base classes )

Regarding the "implement all features" aproach - one important feature
is the footprint and complexity of the config. It would be quite hard
to combine it with all others.


Costin

Ola Berg wrote:

>> 10 other projects also have their implementation and they don't want to
>> switch :-
>> 
>> it definitly doesn't make sense to have 10 implemetations for something
>> like reading an xml config file!!!
>> is it really impossible to find a solution which can be used by all
>> projects??
>> 
>> let's join forces to find a way to have one configuration package!!!
> 
> Hint (if you think it is worth it):
> 
> 1) Check out the 10 implementations, factor out a common denominator API.
> 
> 2) Merge all features from all implementations so that your thing will be
> the most featuresque of them all (so that the potential "customers" won't
> lose anything in the transition), and thus expanding the API from 1)
> above.
> 
> 3) Sell it to them by offering replacement classes that adapts your thing
> to theirs (a slip-in-replacement).
> 
> 4) Offer the added functionality on their email lists, pushing the
> benefits of your thing.
> 
> 
> Why I don't think that the above will work is that
> 
> a) the installed base is too big,
> 
> b) configuration is such a core feature of your product so that you want
> to retain full release/bugfix/management control over the configuration
> component
> 
> and
> 
> c) The different APIs take different approaches, esp when in the
> configuration process, and how, the provided String values get converted
> into real objects.
> 
> I welcome better config utilities (even though I know that the existing
> impls are good enough for about any case), but I think that when doing
> such a thing, considering your answer to point c) is of great importance.
> 
> I have limited coding possibilities as of now, but I am with you in
> thinking (feature requests, modelling, opinions etc).
> 
> I prefer seeing XML config files as a special case of XMLalizing
> object/bean structures.
> 
> /O




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [modeler] removing deps ?

[Costin Manolache]

robert burrell donkin wrote:

>> We'll not "duplicate" anything - the code to do what we need
>> already exists ( in several forms ), we'll just use it ( adapted
>> to the specific needs ). I don't think it'll be a problem with
>> the duplicated maintainance either - the code we need has been
>> quite stable for a long time and I think people working and using
>> the modeler have enough experience to do maintain this code.
> 
> since when has it been a question of experience? it's just the amount of
> leg work required.
> 
> FYI
> 
> the introspection code has been stable for some time.
> 
> the reflection code - on the other hand - has proved buggy and unstable.
> (the problem is that the reflection code in java 1.3 doesn't work very
> well.)

I'm not sure what exactly you have in mind ( as problems with reflection ).

I'm familiar with the code in ant and tomcat - and I don't remeber any 
serious problem that would affect modeler. I plan to use one of those 2 - 
and most of the "leg work" is already done.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[modeler] removing deps ?

[Costin Manolache]

It would be reasonably easy to remove the deps of modeler on
digester ( use DOM or SAX directly instead ) and beanutils (
 we use only a a very small piece ). 
Our use of introspection will not be exposed to the user and 
we have some very specific requirements ( as mandated by the spec ),
so there's little benefit of using the general purpose beanutils - 
quite the contrary. 

Modeler is a very critical piece - it needs to be in the parent
loader ( if we want to control tomcat or other apps via JMX and 
modeler ), and it'll be critical for security. The fewer public
APIs it exposes ( besides JMX ) and the fewer classes it drags into
the same protection domain - the better it is.

We'll not "duplicate" anything - the code to do what we need 
already exists ( in several forms ), we'll just use it ( adapted
to the specific needs ). I don't think it'll be a problem with
the duplicated maintainance either - the code we need has been
quite stable for a long time and I think people working and using
the modeler have enough experience to do maintain this code.

Craig ? Remy ? Other people who are interested in modeler ? 

Costin





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [beanutils] moving reflection classes out of beanutils

[Costin Manolache]

Craig R. McClanahan wrote:

>> It doesn't quite matter. There are people using it ( digester, other
>> projects), it was released - we have to live with it. We may learn a
>> lesson about APIs and use it next time, but as long as it does what it is
>> supposed to do and works - you can't remove it.

> I believe that adding a dependency on [lang] or [reflect] would itself be
> grounds for a 2.x version number for [beanutils], even with no other
> changes (although there would undoubtedly be some).

I don't know. 

this kind of stuff. 

If the [reflect] package will have the same features and better API - 
then it may be better to mark beanutils as "stable"/"closed" and 
migrate modeler, digester, etc directly to [reflect]. I don't see why 
would we need a 2.x version. 

I don't think we need more than a component for this kind of stuff - 
or at least I would use a single component ( even beanutils ) over
some reflection that is split in more components. Matter of taste,
of course - but also complexity, dependencies, spaghetti.

( well, you can  do all the introspection witha single class - both ant and 
tomcat3 are basically doing that ).


> It's clear that ConstructorUtils and MethodUtils belong together,
> wherever they end up.  But it seems less clear that a move would mean
> *deleting* MethodUtils from [beanutils].  It's straightforward to leave
> the existing APIs available (for backwards compatibility), but as wrappers
> around calls to the new functionality, probably deprecated but at least
> kept through a 2.x version lifecycle.  That way, the actual functionality
> is still in one place for easy maintenance/enhancement, we can fix the
> method names in the new versions, and users of MethodUtils can migrate in
> a controlled manner, at their own leisure.

My point is that it would be better if the new package would focus
on doing what it has to do - API, implementation, features.

When it's ready - we can decide if it makes sense to deprecate ( freeze )
beanutils entirely, implement it as a wrapper for backward compat - 
or keep it if it fits a different niche.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [digester] collections and default for useThreadClassLoader

[Costin Manolache]

Craig R. McClanahan wrote:


>> In addition to the threadClassLoader:
> 
> +1 on changing this default, by the way ... forgot to say that yesterday.

Thanks. That was the major issue.

>> Same for beanutils ( which is used quite extensively in digester,
>> and may be needed in modeler as well ).
>>
> 
> In [beanutils] it looks like the only use of [collections] is for
> FastHashMap, which is used to cache things that can still be read with no
> synchronization locks.  I suspect the performance impacts here would be
> more substantial and relevant than the [digester] direct dependencies; it
> probably needs more performance analysis before a decision.

What worries me more is the dependency on the Comparator in a public API.
That would make it impossible to remove beanutils->collection without
one backward incompatibility ( at least at source level - at runtime
it won't have any effect ).

Regarding FastHashMap - most my tests on JDK1.4 show absolutely no
difference. The cost for a lock that is allways unlocked is extremely
small. On the other side - if beanutils is in the top loader and 
gets accessed concurently by many apps - we may find some strange
errors if some of the locks are actually needed. 

I can add some code to check if FastHashMap is available and fallback.
I need to look a bit more at the code in beanutils.

There is also the issue of statics ( which become very visible when 
you move stuff to the top loader), and the issue of security - which is
particularily important for beanutil and probably in collections
( i.e. - if things are cached - can an application access other 
application's data ? Is there any thread that may change the 
security context ? )
And of course - Class.forName and things like that would create
yet another set of problems ( is all the code using the 
thread loader ? ). Pluse the difficulties to override some classes,
possible linkage errors on reverse loaders, etc.

( well, I know you know all this :-)

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [core] Scope, you choose!

[Costin Manolache]

Stephen Colebourne wrote:

>> Jeff said:
>> To say (as
>> has been said) that this approach is not code reuse but simply copying
> smacks of snobbery and is
>> incorrect.  It is a reuse policy that allows version-freeze on small
> portions of code.
> 
> Copied code is copied code. It means dual maintainance and
> incompatabilities.

There is no dual maintainance. Everyone maintains the code that
he cares about and uses. 


> What I have consistently failed to understand about this debate is how
> commons can ask other jakarta projects to refactor out their common code
> when commons is unwilling to do the same job within its own borders.

Commons is not asking other projects to refactor common code just for the
sake of moving code around and creating dependencies. If someone feels 
a piece of code would benefit from having more hands and more diverse 
opinions - and is willing to take the risks of more diverse opinions - 
then commons may be a good idea. 

It is not in commons charter to create a one-size-fits-all introspection 
library. 

What I fail to understand is what is the real issue of debate - 
if you want to create a library for reflection, do it. 
That doesn't mean you have to force everyone to use it or to stop 
people from working on other reflection libraries or to say that the other
reflection code should move to your component.

If a piece of code works well, is stable, fast, clean and does
what it is needed - it will be used, and people will stop working 
on other implementations. If some other implementation does 
something different and people need that - then probably both
will exist for a while.

We must mind our own itches. That's the real issue that people 
don't seem to understand.  

Costin







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [core] Scope, you choose!

[Costin Manolache]

I think there are 2 separate issues.

Having one big jar with all the commons code - or one big jar 
with all jakarta code - is a good idea.
So is having a distribution with 20 small jars. It's a matter
of taste, so having both is the best solution.

The issue I'm concerned with is the spaghetti that goes between
the packages, and the ability to pick one component without
having to use all jakarta.

And as a practical problem - modeler won't work without digester
which doesn't work without collections, beanutils. And digester
doesn't work well in the top loader - and who knows what else
has the same problems. As you know, there are good reasons to
be able to keep the root loader clean. It may be just another
matter of taste - but at this moment bloat ( include everything,
just in case ) wins. 

I think those are _very_ distinct problems, and we shouldn't mix them.
I fully support one big jakarta-commons.jar, as well as a distribution
that includes all the software in jakarta.
 

Costin


Craig R. McClanahan wrote:

> 
> 
> On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote:
> 
>> Date: Fri, 6 Dec 2002 18:05:53 + (GMT)
>> From: [EMAIL PROTECTED]
>> Reply-To: Jakarta Commons Developers List
>> <[EMAIL PROTECTED]> To: [EMAIL PROTECTED]
>> Subject: Re: [core] Scope, you choose!
>>
>> My mail was meant to emphasise the different ideas/companents/packages
>> that have been mentioned over time. In particular they are the ones that
>> are about assisting development with the 'core' of the JDK.
>>
>> I would suggest that if we follow the charter, and all of its
>> theoretically marvellous principles, then we end up with lots and lots
>> of small jars.
>>
> 
> Lots of JARs isn't necessarily bad, if your development environment makes
> it easy to dynamically build classpaths (like Ant does).  However, there
> are often going to be cases where you'd really like a "bunch o commons
> JARs" all together, to make life easier.  The political challenge is, who
> gets to define what is included in the bunch?
> 
> I tried to punt on this issue with the "combo" project, which includes a
> specified released version of *all* the packages in jakarta-commons (but
> not the sandbox).  Currently, this thing actually builds (except for
> Latka, but that's most likely an issue on my development platform), ending
> up with a JAR file of just over one megabyte.  As a side benefit, it
> generates consolidated Javadocs for the packages that are included.
> 
> The theory is that most people will want a JAR that contains the latest
> released version of all the JARs, so that is how the build is set up.
> Presumably, any time a Commons package was released, the CVS tag to pull
> for that package would also be updated in the combo build.xml file.
> However, because each of the tags is itself an Ant property, it is very
> easy to use this to grab exactly the combination of versions you want.  It
> also would be straightforward to set up mechanisms where you can subset
> this -- right now you'd just have to comment out the things you don't
> want.
> 
> Rather than getting into emotional discussions of "core" versus
> "non-core", how about if we start with "combo" that includes *all* the
> non-sandbox packages, and work from there?
> 
> Craig




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [beanutils] moving reflection classes out of beanutils

[Costin Manolache]

robert burrell donkin wrote:

> 
> the guidelines have an inbuilt mechanism whereby components may - if they
> wish - prevent a new existing commons committer joining. that is, they can
> veto the addition of the committers name to the list of developers for the
> component.

With a valid technical reason.

Probably it can be done in a majority vote - but I certainly hope we'll
not reach that point.



Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [beanutils] moving reflection classes out of beanutils

[Costin Manolache]

[EMAIL PROTECTED] wrote:

>>  from:Jeff  Robertson <[EMAIL PROTECTED]>
>> > From: Rodney Waldhoff [mailto:[EMAIL PROTECTED]]
>> Costin> If duplication is a concern - then just use
>> Costin> beanutils ( however duplication is explicitely
>> Costin> allowed in commons AFAIK).
>> 
>> Robert> i've been convinced that beanutils is
>> Robert> not the right place for this code.
>> 
>> Rodney> And I'm convinced that lang isn't the right place either.  Let's
>> split the
>> Rodney> difference and propose commons-reflect or commons-reflection or
>> whatever,
>> Rodney> and end this thread.
>> 
> Jeff> As I think several people have pointed out, isn't that what "clazz"
> is Jeff> supposed to be?
> 
> No. [clazz] is high level pluggable introspection.


Please stop this nonsense "where it should be".

Code will be where people write it - if someone wants to write and maintain 
reflection code in clazz, do so. Same for lang, beanutils, ant or tomcat.
If you don't want to maintain the reflection code in beanutils - don't. 

You can't block a change or a feature because some other component 
implements it. The charter allows duplicated features, so I don't consider
this a valid veto reason. 


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[digester] default for useThreadClassLoader

[Costin Manolache]

Is there any reason for having 'false' for useThreadClassLoader ?

I have a number of failures with tomcat if digester is in the 
parent loader, since a lot of code doesn't set this. And 
IMO the correct behavior for any utility designed to work in 
a server side environment is to check the thread class loader first.

Comments ? Can I change it ?

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [beanutils] ConstructorUtils in beanutils: a bad idea

[Costin Manolache]

I'm not sure I understand what is proposed :-)
However I'm strongly -1 on removing ( or deprecating ) public
code in beanutils, or on adding more dependencies.

It works fine and if another package wants to do reflection - that's 
perfectly fine, but that doesn't mean everyone else is required to
stop doing reflection. If duplication is a concern - then just use 
beanutils ( however duplication is explicitely allowed in commons AFAIK).

beanutils is stable, it works well, it had a number of releases that 
are used in at least few jakarta projects ( tomcat for example ). The 
change doesn't add any new feature and doesn't fix any bug. 


Costin




robert burrell donkin wrote:

> On Thursday, December 5, 2002, at 03:25 PM, Rodney Waldhoff wrote:
> 
> 
> 
>> Looking through the archives, I now see the thread named
>> "[beanutils][lang][PROPOSAL] deprecated beanutils version of MethodUtils"
>> [1] which apparently should have been flagged "[VOTE]", if that was
>> intended to be a binding vote.
> 
> no, that thread wasn't binding. that's one reason why i wanted to try to
> engage you in debate rather than just -1'ing the commit straight away :)
> 
>> I'd be OK with leaving beanutils as the repository for reflection
>> oriented
>> stuff.  In light of this thread, I think I'd prefer to create true
>> reflection oriented commons component.  I'm strongly opposed to moving a
>> bunch of stuff into lang because it seems somehow central or widely
>> applicable.  I'd rather see a bunch of focused modules with well defined
>> scope (however tiny) than a grand utilties framework, and my reading of
>> the commons charter says it agrees with me.
> 
> though i agree about your point in general, the reflection code fits
> perfectly into lang's spec. they are utility classes for package
> java.lang. reflect.
> 
> AFAIK class and reflect(ion?) were intended to be
> introspection-alternatives. they need to rely on solid, low level
> reflection utilities.
> 
> - robert




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [modeler] Modeler does not handle generic Descriptors (bug 14361)

[Costin Manolache]

+1 in general. Modeler is missing several things - right now it
is 'good enough' for tomcat ( i.e. implements what we need ).

Regarding DTD extension - it is needed, however I would like to 
ask you to take a look first at other DTDs that solve 
the same problem ( like in jboss for example ). It would
be very nice to at least share the same tag names and
layout - and maybe support multiple descriptors.
Of course, the ideal would be a unique DTD used in
multiple products/projects - that would be the best
for users and everyone involved.

I'm also doing some enhancements to modeler - I'm mostly interested
in the persistence part ( saving the modified attributes ). A 
proposal was made on tomcat to use JNDI as an API for the data
storage ( it is already used to abstract the VFS ), and 
I'm trying to bridge the 2 - i.e. modeler to save changed
attributes in JNDI, plus jndi providers to abstract the
existing config files.

Costin



Roberts George E (Ed) NPRI wrote:

> Hi,
> 
> I have been looking at the modeler for a project I am working on... I
> communicated with Craig and he suggested that I bring our conversation to
> this email group...
> 
> The modeler as it stands now does not have full compliance with the spec
> (unfortunately I have been reading JMX 1.1 instead of JMX 1.0.1 but I took
> a peek and it did not seem to change between those releases)... basically
> the problem is this... the specs says that one can add any number of
> descriptor fields that one wants, right now the DTD does not allow you to
> do that (only the standard ones) nor does the parser take care of that.  I
> have a DTD that I have posted as an attachment to bug 14361 that I want to
> purpose as a DTD that will take care of this problem... it will be
> backward compatible with the current DTD but I have deprecated some of the
> attribute entries
> 
> ... there is a lot of metadata that I wanted added into the Descriptor for
> my class' parts and if one looks at the spec (even the 1.0.1 spec) there
> are Descriptor items such as for ModelMBeanAttributeInfo
> 
> The fields in the descriptor are defined, but not limited to, the
> following:
>  name   : attribute name
>  descriptorType : must be "attribute"
>  value  : current value for attribute
>  default: default value for attribute
>  displayName: name of attribute to be used in displays
>  getMethod  : name of operation descriptor for get method
>  setMethod  : name of operation descriptor for set method
>  protocolMap: object which implements the ProtocolMap interface: map
>  of protocol names and protocol hints
>  persistPolicy  : Update|OnTime|NoMoreOftenThan|Always|Never
>  persistPeriod  : seconds - frequency of persist cycle. Used when
>  persistPolicy is"OnTime" or "NoMoreOftenThan". currencyTimeLimit : how
>  long value is valid, <0 never, =0 always, >0 seconds lastUpdatedTimeStamp
>  : when value was set
>  iterable   : T - object value supports Iterable interface, F - does
>  not support Iterable interface
>  visibility : 1-4 where 1: always visible 4: rarely visible
>  presentationString : xml formatted string to allow presentation of data
> 
> there is no way in the present DTD to account for this information... one
> way that could be done is through attributes but then one could not have a
> general object as the field value allows... I think I have accounted for
> that in the DTD...
> 
> ed roberts




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [lang][logging] dependencies (was: Re: [lang] MethodUtils)

[Costin Manolache]

Michael Davey wrote:

> Henri Yandell wrote:
> 
>> I'm +1 for System.err too. Should this be institutionalised across Lang?
> 
> There has been discussion before about a 'Core' component with the bare
> minimum from various commons components and upon which (nearly) every
> commons component would depend.
> 
> Could the Log interface, LogFactory, SimpleLog and NoOpLog classes be
> moved to 'Core' leaving the rest in Logging (thus making Logging an
> extension to Core's
> logging functionality)?  The only obvious Core candidates from Lang (for
> me) are Nestable*.
> 

I don't see any reason for [logging] to depend on [lang], so 
it is perfectly fine if lang uses logging.

It is possible that some drivers will use [lang] - for example
to use Nestable to provide this feature for log4j - but that
shouldn't be part of commons-logging, but part of a special
commons-logging-log4j.jar.

In general I think it was a bad idea to mix the drivers in
the same interface with the API ( I'm waiting the "I told you so" :-).
I think the ant pattern ( ant-foo.jar for the drivers that are dependent
of "foo" ) is a very good one.


Costin





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[modeler] merging dynamicMbean and discovery

[Costin Manolache]

I would like to propose 3 enhancements to modeler. 

The DynamicMbean ( from tomcat-util ) can support beans that
have no xml description, using introspection. I'm in process of converting 
it to a model mbean and integrate it with Registry.

The second is a new class "Modeler" that will act as a front
end - with no dependency on JMX. The goal is to be able to use
modeler in applications directly, even if the app doesn't have
a dependency on JMX. ( i.e. if JMX is not available, the code
will fall back to noop). I think this will simplify a lot of 
code ( i.e. it would be possible to make calls to modeler directly
without listeners/etc ).

I would also like to add a bit of discovery ( for start 
just getResources(), but later we could use commons-discovery ).
It should read "META-INF/modeler.xml" ( not sure about the name)
from all jars. This will allow other applications to be 
jmx-enabled.

Opinions? Craig ? Remy ? 

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthan we thought...)

[Costin Manolache]

Geir Magnusson Jr. wrote:

>>> Great.  Perfect description.  Not disputing the general sentiment (I
>>> still think it's moving deck chairs around if you move every committer
>>> into the PMC).
>> 
>> I think it's more about a consistent naming and organization with the
>> rest of apache ( and the httpd project where all things started ).
> 
> Ok - that's fine.  But note that httpd and jakarta are different (for what 
I
> know of httpd...).  I don't think Jakarta is all bad, and think that
> changes should be made to improve things.

+1

Having a consistent naming and structure as a starting point can't hurt.

>> It is also a good opportunity to improve few things:
>> 
>> - find who's tracking what component.
> 
> That would be good, but don't we know that from the status files ?

We know who's commiting - or did. And we have no mechanism to 
track sandbox - since most of them have 1-2 committers only.


>> - better tracking of who's active ( if we use 'active committer' def. )
> 
> How?  Once on the PMC, your are on, right?

My 'active committer' would mean that once you stop beeing active 
you are supposed to remove yourself from the list.
( and add yourself back when you return )


>> - a way to better pass the message and get people involved in the
>> monitoring activity
> 
> I don't see how a new title and mail list will change anything.  If we
> have
> to start changing the values of the community, we can do it directly.  If
> there are things we have to change, it's our responsibility as committers
> to do it.

different issues - the title is to make things more uniform with 
httpd/apr/etc and get closer to the legal protection.

The other issue is increasing awareness and having more active involvement
in the management of the project.

I'm not sugesting automatic committer/SPMC conversion. If some committer
wants to participate in the SPMC ( which is more of a title, you're right )
he'll have to volunteer at least for monitoring few components ( and sandbox 
components ).


> Ok - why not just make the file then?  I am sure that every active
> committer will step up to do this.
> 
> The thing that we do get out of this is a formal accountability to the ASF
> -
> but it strikes me as strange that we take all (or most) committers,  
define
> them to be the PMC, and all of a sudden accountability happens.  Do you
> see what I mean?

Well, I think we _are_ accountable already - at least for jakarta-commons 
proper, and many committers are acting as a PMC. Do you see what I mean ?

Again - I'm not sugesting taking all committers and just define them as 
SPMC. 
I'm sugesting creating a SPMC that will be open to all active committers
who want the title or are willing to help with this task ( monitoring ). 
Most of us are indeed tracking few components.


> Seems like we have a problem if our committers aren't responsible and
> willing to be held accountable.

I think we all agree this is not the case. Except that outside j-c
there is a perception that if you are not in a PMC or you don't have
some PMC to read each code commit - you're not accountable ( or protected 
legally or whatever ).


>> We can create some rules so that any committer can join the SPMC by
>> volunteering for some components and participating in some sort
>> of load distribution, and use this as a way to pass information.
> 
> What information?  Why not the usual list?  We wouldn't want this to be
> closed, would we?

I meant pass the information on the load distribution. When you decide 
you want to be a SPMC member, you volunteer for some tasks - and this
way we can synchronize and spread the load. 


>> Regarding 'separating from jakarta' - I do think that j-c is in a way
>> the 'core' of jakarta ( I don't know any other jakarta sub-project
>> to bring so many people together ).
>> 
> 
> Bingo. +1.  Exactly.  That was the intent, and that is what we achieved. 
> To break it up or move it  in the name of 'community' means someone is
> missing the point (not you, Costin)

The problem is that quite a few people already expressed the idea of 
moving pieces of the code ( and this will affect the community ).


>> But I wouldn't mind opening it up to xml.apache.org people - we already
>> have few great committers from xml working on j-c, and I think it would
>> be great to expand this.
> 
> Fine - our hurdles for becoming a committer aren't very high.  Do we have
> a
> problem where XML people aren't being allowed to contribute?  I mean, if
> someone showed up with patches or new code, I think there is enough mixing
> of the communities that the person would be granted committer status, just
> like we automatically let in committers from other Jakarta projects,
> right?

I know. We know. It would be nice for them to know that too :-)
And right now I don't think this is well-known in xml.apache.org.



>> AFAIK HTTPD PMC includes every committer.
> 
> I don't think so - I asked.  It doesn't include every committer, and those
> that are a

Re: moving to a top-level project (was: [Ant nudgeSTATUS] Betterthan we thought...)

[Costin Manolache]

On Tue, 2002-10-29 at 12:13, Geir Magnusson Jr. wrote:

> Great.  Perfect description.  Not disputing the general sentiment (I still
> think it's moving deck chairs around if you move every committer into the
> PMC).

I think it's more about a consistent naming and organization with the 
rest of apache ( and the httpd project where all things started ).

It is also a good opportunity to improve few things:

- find who's tracking what component.
- better tracking of who's active ( if we use 'active committer' def. )
- a way to better pass the message and get people involved in the
monitoring activity

My view was a global 'SPMC' file listing all the people _and_ the
components he's volunteering to monitor ( even if he's not actively
working on it ). STATUS tracks who's working on what.

We can create some rules so that any committer can join the SPMC by
volunteering for some components and participating in some sort 
of load distribution, and use this as a way to pass information.


> > The open questions are:
> > - can jakarta PMC recognize jakarta-commons SPMC and delegate oversight
> > officially ?
> 
> Good question, and I don¹t see why we couldn't ask, although
> 
> > - if that's not possible, can jakarta-commons form a PMC and ask the
> > ASF board to recognize it ? ( it seems implied that tomcat or ant could
> > do that easily ). If so, can it remain part of jakarta ( and eventually
> > extend/merge with xml.apache.org )
> 
> Yes, it could.  I would really be against J-C separating from jakarta in any
> way.  Renaming all committers to be members of the PMC again seems like
> window dressing until you educate those committers about their
> responsibilities - where I then wonder if there is education to be done, why
> don't we just do it?

I'm not very sure what education - I suspect we all know the rules.

We do need probably a bit more formal organization - and some 
explicit procedures/rules/plans. 

Regarding 'separating from jakarta' - I do think that j-c is in a way 
the 'core' of jakarta ( I don't know any other jakarta sub-project 
to bring so many people together ).

But I wouldn't mind opening it up to xml.apache.org people - we already
have few great committers from xml working on j-c, and I think it would
be great to expand this.



> > - technical details: who is part of the SPMC ( my initial proposal was
> > 'all active committers who like to be', maybe with a 1-2 month delay for
> > very new committers ). I'm sure other opinions will be raised on this.
> 
> This is why I think it's window dressing - why would you *not* allow a
> committer to be participant in the PMC?  Would that reason, whatever it is,
> be a reason for them not to be a committer?  Don't we believe that when we
> make someone a committer, its because they have shown they share the vision
> and are willing to take responsibilty?  It's more than just the ability to
> 'cvs commit'.

I think a 1-2 month delay is just reasonable - to let him get used with 
the environment and the rules. But I'm ok with dropping it ( again, this
is my understanding of httpd procedures ).

Using 'active' is a way to make sure we have things covered up and 
to track the people who are involved. If some European committer 
takes a 3-month vacation he should remove himself from the 'PMC' list
and add back when he returns. This way we'll know that whatever
he was monitoring/working on is not covered and we can redistribute it.

I see little value in a very large PMC where 1/2 of people don't 
track the mailing list. 

I'm also very strongly against any 'elective' system - as you said,
if someone is voted as committer he should also be trusted ( after
some adjustment and READMEs ) as PMC. 



> Just curious - I am asking the same questions about HTTPD and APD, as it
> sounds like it's pretty much the same thing.  They assure me it's not, for
> example the HTTPD PMC election is based on 'merit', where the Jakarta  PMC
> is a 'popularity contest', but no one has yet to define the difference.

AFAIK HTTPD PMC includes every committer. 

I think it's more of a naming issue - the jakarta PMC is mirroring the
board ( i.e. small set of people, elected ). I don't think
it's 'popularity', but more 'trust' that is the target of the election.
Each jakarta subproject behave just like httpd or apr - with all
active committers doing all the code reviews and monitoring and
decisions.

The problem is that we call things differently, and this de-facto
'delegation' that happened since the beginning of jakarta is now 
considered a problem.



> To me, merit would be objective, popularity would be subjective.  However,
> there are no objective measures of merit here, only opinions of those
> voting. (HTTPD has the curious feature that only the existing PMC can vote
> in new members, not the rest of the community... I have yet to ask about
> that)  My work in Velocity is really valuable to some people (like
> myself :), but someone else, say someone working on

Re: Proposal: httpd-like PMC organisation

[Costin Manolache]

Morgan Delagrange wrote:


> Quite right, your proposal did say "all committers".
> Sounds like we're essentially arguing about nothing.
> I'm saying that all committers should keep an eye on
> commits.  You're saying that the PMC should monitor
> all commits, but that the PMC should be all the
> committers.  Fine.
> 
> I'm not sure what is gained by waving a wand over the
> committers and naming them an unofficial PMC, but I
> agree that we need to be responsible for commits.

You're right - we're arguing about nothing. It's just a
naming/terminology issue - to make things more in line
with what other expect things to be called.

But I think there's something more - if we can use it to
better organise and keep track of who's active, on
what and what other components is he interested in. 
Right now we kind of use STATUS, but it doesn't 
reflect who's active or who's monitoring what. 

I think we should wait for things to at jakarta level
to settle down, and then reopen the issue.

--
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal: httpd-like PMC organisation

[Costin Manolache]

Morgan Delagrange wrote:

> It's correct that we did not monitor commits as
> closely as we should.  Roy raised our awareness or
> this, and that's good.  However I don't think we need
> a small group to check every single commit to every
> component.  We all should be and will be more vigilant
> now.

Morgan - I'm not talking about a 'small group'. If you read 
reorg, IMO the PMC should be formed of all active commiters,
like in httpd.

For example, we can have a list of all active commiters and
what is covered by each. Part of this is already in STATUS,
but out-of-date. There are also projects that we monitor 
without beeing in STATUS. 

We can call it 'PMC' or 'active commiters'. But we kind of need
to know if the entire codebase is covered - and if not, 
either find volunteers or move the code to some 'stable' 
area ( if nobody is working on it anymore ).

Besides the name ( PMC or whatever ) there is a problem of
organization and coordination. 

I don't know - if it is too complicated we'll need a simpler 
solution. I hope we all realise that nobody can track all
the code commits and all the code in general, and sooner
or later an error can happen.

Maybe a stylecheck would be enough to spot the obvious problems
and the normal review that takes place will spot the others - 
and we don't actually need to do anything special. But 
I think it's good to at least discuss options and make an
informed decision.

-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Promote "FileUpload" from Commons Sandbox to Commons Prope r

[Costin Manolache]

>> - 8< -
>> Vote to promote the "FileUpload" component from Commons Sandbox to
> Commons
>> Proper:
>> 
>> [X] +1 I am in favor of this action and will help
>> [ ] +0 I am in favor of this action but cannot help
>> [ ] -0 I am not in favor of this action
>> [ ] -1 I am opposed to this action and here is why:
>> - 8< -

+1 

-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal: httpd-like PMC organisation

[Costin Manolache]

Martin van den Bemt wrote:

> 
>> Questions:
>> - should we vote on the volunteering offer ? What is httpd doing ?
> 
> Yes. In a way you are trusted with a task. If people think your not up
> to it, they should be able to -1 it. Also a lot of +1's is good for the
> ego ;)

Well, one thing I would like to avoid is making it 'political' or 
subjective or tie it with 'ego' issues :-)

That's why I would much prefer a more deterministic system - if
you're an active commiter ( i.e. spend few hours a week reading
the mail and making commits ) and you've been around for N months - then 
you can add yourself to a list, togheter with the projects you
volunteer to monitor.

If someone is a commons commiter - he can vote and make code changes
and everything else. All important decisions are already majority
based. 

I'll try to find out exactly how things work in httpd.


>> - should the pmc have a separate mail list ? ( I personally don't
>> think so - but that's how other pmcs are organised )
> 
> Will be usefull I think. There is already too much mail and this way you
> keep discussions clean (not saying it should be a closed list though)

Good point.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Proposal: httpd-like PMC organisation

[Costin Manolache]

We already have a line in our charter about having a jakarta-commons 
specific PMC. Right now it is modeled after jakarta, with 3 
members.

I would like to propose changing this number to include more
people - I think the right solution is more closer to what httpd
and apr projects are doing, where the PMC is composed of most
active commiters.

My proposal is to modify the charter so that a jakarta-commons PMC
is composed of all active commiters. This will be volunteer-based,
in the sense that any active commiter who wants to become
part of the PMC will announce his willingness to participate.

Questions:
- should we vote on the volunteering offer ? What is httpd doing ?
- Should we impose a 2-3 month wait period for new commiters ? )
- should the pmc have a separate mail list ? ( I personally don't
think so - but that's how other pmcs are organised )

The commons PMC members will split the task of monitoring the
files. All decisions will continue to be taken by majority 
vote of all jakarta-commons commiters.

Not that this is not a proposal to form a top-level project - 
just to better organise ourself. Jakarta-commons is IMO at the
core of jakarta - with the most diverse set of commiters from
almost all jakarta projects. Any major issue will be forwarded
to the Jakarta PMC. 


-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

What should we do about sandbox ? RE: License and copyright issues

[Costin Manolache]

Martin Cooper wrote:

> I found a few things not yet mentioned:
> 
> 1) In codec\Metaphone.java, "Copyright 1997, William B. Brogden", which is
> clearly a problem.
> 
> 2) In scaffold, numerous instances of "Copyright (c) 2002 Synthis
> Corporation.", also clearly a problem.

Acording to jakarta-commons rules, the sandbox is just a CVS repository 
where experiments may happen. 

I see it similar with commiters using their homes or public_html
pages on jakarta - or with the commiters cvs repository.

The sandbox is open to any jakarta commiter.

The question is: do we have to police it and monitor all forms
of activities that happen on apache servers ? Because as far as 
I can see, there is no difference between a file placed by a 
jakarta commiters on his public_html or home and the files
in commons-sandbox. 

We made it very clear that sandbox code can't be released,
and the fact that it is accessible using public cvs and 
viewcvs is similar with the public_html files.


I would propose to ask the sandbox to be removed from viewcvs
and the eventually discuss what to do about the public cvs. 
As a way to protect ourself. I wouldn't mind if this is voted
down :-) 

What do you think about this issue ? Any other proposed solutions ?
 

-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: License and copyright issues

[Costin Manolache]

Dmitri Plotnikov wrote:

> Costin,
> 
> When PLOTNIX was OFFICIALLY contributing this code to Apache, I copied
> the license from some other Apache source file, which had IIRC Lotus
> mentioned as the original contributor.
> 
> The original JXPath was not an Open Source project, it had an
> Apache-style license and was distributed freely with the source.  I
> wrote the original version in its entirety.
> 
> Just let me know what change needs to be made to the license and
> whether I need to make some changes to the disclaimer on my website.

AFAIK things are fine - I personally don't see any problem with that.
However you should ask the pmc ( [EMAIL PROTECTED] ), just 
to be sure.

I've seen similar things in httpd and other projects.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: License and copyright issues

[Costin Manolache]

That may be a problem. I remember seeing similar statements 
even in httpd code, and it is not a different copyright - it
just indicates that the code was originally based on some code
that was donated to ASF ( which is just a true fact )

It is true, tomcat ( when donated by Sun ) didn't include such
a statement. 

Ok, we need to find out if this is indeed a problem or not. Or
just ask jxpath commiters to remove it - but I think we should
first get an answer that this is wrong. 
If it is not wrong - it would just remove a very fair attribution.

Dmitri - I assume you didn't 'take this code from another open 
source project' and replaced copyright. No offense please, I have to ask.

Costin

Michael A. Smith wrote:

> The closest I can identify is jxpath which contains this at the end of
> the license in each source file[1]:
> 
>   * This software consists of voluntary contributions made by many
>   * individuals on behalf of the Apache Software Foundation and was
>   * originally based on software copyright (c) 2001, Plotnix, Inc,
>   * <http://www.plotnix.com/>.
>   * For more information on the Apache Software Foundation, please see
>   * <http://www.apache.org/>.
> 
> Where typical apache code contains only:
> 
>   * This software consists of voluntary contributions made by many
>   * individuals on behalf of the Apache Software Foundation.  For more
>   * information on the Apache Software Foundation, please see
>   * <http://www.apache.org/>.
> 
> However, I can't imagine this would be the source of the problem since
> this project has been in CVS for over a year now (Aug 23, 2001), not 4
> months, as Roy specifies.  I should also note that it has had active
> participation by an Apache member (craigmcc), and on the plotnix
> website, there is the statement:
> 
> "JXPath was initially developed by Dmitri Plotnikov at PLOTNIX and then
> contributed to the Apache Jakarta project. The new home of JXPath is
> Jakarta Commons"[2]
> 
> And Dmitri Plotnikov is a committer here, actively developing JXPath.
> 
> Thus, I'm not sure this is the problem that Roy was referring to.
> That's why I asked Roy (and Ken Coar) on the reorg list to specify the
> problem[3].  I have yet to hear back.
> 
> Any other ideas what the problem may be?
> 
> regards,
> michael
> 
> [1] For example,
> 
http://cvs.apache.org/viewcvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/AbstractFactory.java?rev=1.4&content-type=text/vnd.viewcvs-markup
> 
> [2] http://www.plotnix.com
> 
> [3] [EMAIL PROTECTED]
> 
> Costin Manolache wrote:
>> The following was posted by Roy Fielding:
>> 
>> "Just look at the commons cvs -- there is code present
>> that was taken from another open source project, the license removed,
>> and replaced with the committer's own copyright alongside that of the
>> ASF.  That isn't just contrary to our guidelines; it is immoral!
>> And, it has been there for four months without anyone so much as
>> lifting a finger (not to mention deleting the module, which is what
>> I would have done).  If that isn't cause to terminate an entire project,
>> I don't know what is."
>> 
>> This is a very serious accusation, and it seems other people
>> are aware of this issue - yet neither jakarta-commons nor
>> jakarta PMC have been informed ( at least to my knowledge ).
>> We may have too much traffic - or maybe people don't know
>> about [EMAIL PROTECTED], or maybe those who claim 'we don't
>> care' are right.
>> 
>> As you should know, it is our duty to review the code that
>> is checked in and make sure it respect some basic rules.
>> 
>> I think it is essential for us to find the code and
>> find out how this happened and how it can be prevented in the
>> future. Nothing is perfect - and it is possible that people
>> don't understand the rules or just didn't think.
>> 
>> I can't find many excuses for whoever noticed and who knew about that and
>> failed to  notify the community or the PMC - and I include Roy here. But
>> that doesn't change the fact that we have a serious and major problem -
>> I think it is our fault in the first place as commons commiters for
>> letting such a thing happen.
>> 
>> Since I still can't find out what code he is reffering to - I would like
>> to ask for your support in identifying it ( and fixing the problem,
>> of course ), and then to discuss and try to find out solutions to
>> avoid this in future.
>> 
>> Costin
>> 
>> 
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:  
>> <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional
>> commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>

-- 
Costin



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>

Re: [Latka][Proposal] Make Jelly a required dependency?

[Costin Manolache]

[EMAIL PROTECTED] wrote:

> "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote on 15/10/2002 02:20:01
> AM:
> 
>> 
>> 
>> On Mon, 14 Oct 2002 [EMAIL PROTECTED] wrote:
>> 
>> >
>> > Is there a rule somewhere about not having sandbox components as a
>> > dependency?
>> 
>> At a minimum, I think you can infer an indirect rule from the following
>> conventions:
>> 
>> * You can't release a Sandbox component at all -- it's just
>>   a wad-o-code.
>> 
>> * You can't release a Commons component that depends on
>>   non-released other code.
>> 
>> Struts has some interim dependencies on a sandbox component or two, but
>> that will need to be resolved before a final Struts 1.1 release.
> 
> Craig,
> 
> out of curiosity, do you know where these conventions are laid out?

The first part was made very clear when the commons was created - 
I don't know where it is actually written, but I fought a lot
against it and I remember quite well losing the vote. ( and 
IMO the majority was right :-)

The second is pretty obvious since otherwise the component
won't work well with a missing dependency.

> Did I notice struts having 1.1 beta release(s) with sandbox dependencies?

Struts is a standalone project that makes its own decisions. If no struts 
commiter voted against the release, then there's nothing we can do, 
they don't have to follow jakarta-commons rules.
As a matter of fact, tomcat has major releases with sandbox dependencies.

IMO a majority of commiters can release whatever it wants. If struts
or tomcat or another project wants to release a sandbox component - they
can do that, there's no rule against this. The rules applies only on 
releasing sandbox components without a vote ( out of jakarta-commons )


-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Latka][Proposal] Make Jelly a required dependency?

[Costin Manolache]

James Strachan wrote:
 
> I'd really like a stable release of Jelly out ASAP so migrating it to the
> commons proper sounds like a great idea.

There is no need for a stable release. 

All you need ( IMO ) is a community and a plan to eventually get 
a release. 


> Though I am having second thoughts on whether Commons is the right place
> for Jelly; maybe it should be a top level Jakarta project? Jelly started
> out as a little reusable XML scripting engine that could be embedded
> anywhere and is increasingly growing in scope to have all kinds of add-on
> libraries like JellyUnit, JellySwing and to do things like SOAP scripting
> (via Apache Axis).

If jelly commiters want it to be a top level jakarta project, I'm 
sure it can happen.

I would presonally prefer to see it as a commons project. It can have
its own list ( like httpclient ), but I think it would benefit from
the low-entry barier, and given the ammount of plugins it has
it would be much easier for people to contribute to it.

It would also be much easier for other project to rely on jelly.

That doesn't mean I'm against it as top-level, just that I think it
would be _much_ better for jelly to be a common component. 


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Latka][Proposal] Make Jelly a required dependency?

[Costin Manolache]

The only problem is that jelly is still in sandbox.

be in a suficiently stable state ( if other components
start to have deps ). So it may be the time for someone
to make the proposal  for commons.

Costin


Morgan Delagrange wrote:

> Hey all,
> 
> I finished a rough cut conversion of the Latka tags
> and validators to Jelly.  The Jelly tags have syntax
> identical to the previous Latka tags.  I think it will
> be pretty easy to emulate Latka variables inside the
> Jelly expression language (JEXL).  With a patch I made
> to Jelly this week, I think even the lack of a
> namespace declaration in existing scripts will not be
> a problem.
> 
> I believe that the functionality of the Jelly tags is
> actually a complete superset of the previous
> implementation.  The command line interface should be
> able to function unchanged if converted to a Jelly
> backend, but the new tags will make it much easier to
> run Latka inside applications like Ant and JUnit.  I
> propose that we make Jelly one of Latka's
> dependencies, so that we can remove the XML handlers
> and processors that support the previous tags.  In my
> view, the Jelly implementation is much cleaner and
> will render the old tags unnecessary.
> 
> - Morgan
> 
> =
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
> http://jakarta.apache.org/watchdog
> 
> __
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com

-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [logging] Log4j's NDC and MDC

[Costin Manolache]

I haven't used this feature - if anyone can provide a short 
description and a proposal for API it'll probably have my
+1.

Regarding no-op - it may be better to try to provide a 'default'
or baseline implementation, if possible ( even if the behavior will
be inefficient ). At least IMO, commons-logging should provide
a common API but also try to harmonize the behavior.

Costin

Ceki Gülcü wrote:

> At 11:10 10.10.2002 -0400, Steve Downey wrote:
>>It looks like the concept is available in both LogKit and Log4J, although
>>in slightly differenct forms. I don't know if the forms are compatible.
>>
>>It's not available in JDK 1.4 logging.
>>
>>So, the question is two-fold. Can the differences between LogKit and Log4J
>>be harmonized, and is this useful if it might be a no-op?
> 
> Yes on both accounts. Yes they should be compatible, and yes a no-op under
> JDK 1.4 is better than having nothing under log4j or logkit.
> 
> 
>>On Wednesday 09 October 2002 09:02 pm, Sean C. Sullivan wrote:
>> > I spotted this message on the jboss-developer mailing list.
>> >
>> > > -Original Message-
>> > > From: Jason Dillon [mailto:jason@pl...]
>> > > Sent: Tuesday, October 08, 2002 8:24 PM
>> > > To: [EMAIL PROTECTED]
>> > > Subject: RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j
>> > >
>> > >
>> > > It is too bad commons logging does not provide abstractions
>> > > for a ContextStack or ContextMap similar to Log4j's NDC and
>> > > MDC.  These are valuable constructs.
>> > >
>> > > Do you know anyone on the commons logging team?
>> > >
>> > > --jason
> 
> --
> Ceki
> 
> TCP implementations will follow a general principle of robustness: be
> conservative in what you do, be liberal in what you accept from
> others. -- Jon Postel, RFC 793

-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Announce][HttpClient] New mailing list httpclient-dev

[Costin Manolache]

For those using gmane: I made a request for the 

gmane.comp.jakarta.commons.httpclient.devel 

news mirror for the new list. ( I read apache and all other lists
via news - I assume other do this too )

Costin


Jeff Dever wrote:

> Hello all,
> 
> A new mailing list on Jakarta was created today for the Commons
> HttpClient project.  You can subscribe to this list by sending email to:
> 
> [EMAIL PROTECTED]
> 
> This list is ment for *all* development traffic related to HttpClient,
> including: discussions, cvs commit messages, and bug reports.  No
> particular string is needed in the subject field when posting to this
> list.
> 
> Any voting will still be held on the commons-dev list with at least
> [httpclient] in the subject line.
> 
> No doubt that many of us will still monitor the commons-dev list, but
> all HttpClient traffic should be moved to the new httpclient-dev list.
> Please feel free to subscribe if you are interested, and don't forget to
> adjust your mail filters!
> 
> PS: Thanks to Justyna Horwat at Sun for creating the new list.
> 
> Jeff Dever
> HttpClient 2.0 release manager




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [HttpClient] Preferences Architecture Implementation Draft II

[Costin Manolache]

Jeff Dever wrote:

> I'm torn about this.  I don't think that "bean style" (aka "ass load of
> setters
> and getters") is the answer.  The components in question in HttpClient are
> just
> too big for that to work.  There would be many more _configuration_
> methods in the public interface than anything else.

Then a generic setAttribute ? Or JMX ?

But in general - HttpClient should work as a bean ( or component ) as 
part of a larger program, and support configuration/tunning via API
calls.

Even if a hierarchical pull method is prefered - defining HttpClient's
own config API and/or config file is _bad_ ( and I would -1 it ). 
Either use an existing API ( jndi, properties, etc ), or propose
a top-level commons package ( as a wrapper on top of existing 
solutions ).

Commons component should be easy to integrate in other products and
apps - if they define their own config mechanisms this will be much harder.

Costin


> I think that the configuration that Odi is proposing is a reasonable
> possibility.  The comments that Mark made in a previous email also should 
be
> considered.  I wouldn't exclude a HttpClient customized solution, but if
> there are others, those should be considered too.


 
> As per Mark's email, storing the properties in the respective classes
> themselves
> seems reasonable.  The only problem is making them respect a hierachy. 
> The time that all the components come together (httpmethod, httpstate and
> httpconnection) is in the execute method.  The behavioural properties
> could be checked at the time that execute is called.
> 
> Again, I'm not sure what the right way to go is.
> 
> 
> 
> Costin Manolache wrote:
> 
>> I personally thing this is a very bad idea.
>>
>> There are already enough 'config' architectures:
>> - ant/jmx/bean style, with introspection used to call java bean
>> setters ( with or without Digester )
>> - jdk1.4 preferences/JNDI for hierarchical config and components
>> getting the info themself.
>> - simple Properties storing data with hierarchical names
>>
>> Defining another config API and impl - and doing it specifically
>> for http client is even worse - as it has implications for the
>> code that would like to use http-client and already has its
>> own config mechanisms.
>>
>> I personally think that for components like http client, java-bean
>> style of configuration is the best and in no case should they
>> define their own config files and apis.
>>
>> Except maybe using a common API modeled after jdk1.4 ( similar with
>> commons-logging ) that wraps jdk1.4 logging, jndi and other
>> hierarchical-storage configs ( for those who prefer this instead
>> of setters ).
>>
>> Costin
>>
>> Ortwin Glück wrote:
>>
>> > This is the second iteration in finding the right architecture for the
>> > preferences API.
>> > _
>> > Notes
>> > - Moved to a separate package: httpclient.config
>> > - Configuration is not immutable.
>> > - Configuration is now hierarchical and reflects changes in underlying
>> > Configurations immediately.
>> > - The new ConfigManager links any object with a Configuration instance.
>> > - If the user does nothing the default configuration is always used.
>> >
>> > ___
>> > Sample Code
>> >
>> > The user can set the configuration from the outside for HttpClient,
>> > HttpMultiClient, HttpMethod, HttpConnection. The user should not try to
>> > configure other classes directly:
>> > --user app
>> > HttpClient client = new HttpClient();
>> > Properties patch = new Properties();
>> > patch.setProperty(ConfigKeys.USER_AGENT, "My HTTP Client 0.01");
>> > Configuration clientConfig = new Configuration(Configuration.DEFAULT,
>> > patch);
>> > ConfigManager.setConfiguration(client, clientConfig);
>> >
>> > HttpClient configures HttpMethod automatically IF not yet configured.
>> > The same way a HttpConnection is configured:
>> > --HttpClient
>> >   public synchronized int executeMethod(HttpMethod method) {
>> > ...
>> > if (!ConfigManager.isConfigured(method)) {
>> >  ConfigManager.setConfiguration(method, myConfig);
>> > }
>> > method.execute(getState(), connection);
>> > ...
>> >   }
>> >
>> >
>> > Low level objects use the configuration of a higher level object. The
>> > same applies to inner classes:
>> > --ChunkedInputStream
>> >   myConfig = C

Re: [HttpClient] Preferences Architecture Implementation Draft II

[Costin Manolache]

I personally thing this is a very bad idea.

There are already enough 'config' architectures: 
- ant/jmx/bean style, with introspection used to call java bean
setters ( with or without Digester )
- jdk1.4 preferences/JNDI for hierarchical config and components
getting the info themself.
- simple Properties storing data with hierarchical names

Defining another config API and impl - and doing it specifically 
for http client is even worse - as it has implications for the 
code that would like to use http-client and already has its
own config mechanisms. 

I personally think that for components like http client, java-bean
style of configuration is the best and in no case should they
define their own config files and apis.

Except maybe using a common API modeled after jdk1.4 ( similar with
commons-logging ) that wraps jdk1.4 logging, jndi and other 
hierarchical-storage configs ( for those who prefer this instead
of setters ).

Costin

Ortwin Glück wrote:

> This is the second iteration in finding the right architecture for the
> preferences API.
> _
> Notes
> - Moved to a separate package: httpclient.config
> - Configuration is not immutable.
> - Configuration is now hierarchical and reflects changes in underlying
> Configurations immediately.
> - The new ConfigManager links any object with a Configuration instance.
> - If the user does nothing the default configuration is always used.
> 
> ___
> Sample Code
> 
> The user can set the configuration from the outside for HttpClient,
> HttpMultiClient, HttpMethod, HttpConnection. The user should not try to
> configure other classes directly:
> --user app
> HttpClient client = new HttpClient();
> Properties patch = new Properties();
> patch.setProperty(ConfigKeys.USER_AGENT, "My HTTP Client 0.01");
> Configuration clientConfig = new Configuration(Configuration.DEFAULT,
> patch);
> ConfigManager.setConfiguration(client, clientConfig);
> 
> HttpClient configures HttpMethod automatically IF not yet configured.
> The same way a HttpConnection is configured:
> --HttpClient
>   public synchronized int executeMethod(HttpMethod method) {
> ...
> if (!ConfigManager.isConfigured(method)) {
>  ConfigManager.setConfiguration(method, myConfig);
> }
> method.execute(getState(), connection);
> ...
>   }
> 
> 
> Low level objects use the configuration of a higher level object. The
> same applies to inner classes:
> --ChunkedInputStream
>   myConfig = ConfigManager.getConfiguration(method);
>   ... myConfig.getBooleanValue(ConfigKeys.IGNORE_PROTOCOL_VIOLATION);
> 
> A static class must be configured by the caller using the meta object.
> Users should never try to configure low-level classes:
> --caller class
>   ConfigManager.setConfiguration(NTLM.class, myConfig);
> 
> --NTLM
>   Configuration myConfig = ConfigManager.getConfiguration(NTLM.class);
>   String mySecurityProvider =
> Configuration.getStringValue(ConfigKeys.SECURITY_PROVIDER);
> 
> 
> 
> Problems
> 
> As you can see this approach generates a large overhead. This is mainly
> caused by one requirement: "Would there be a means to assign my own
> properties object to the HttpClient, HttpConnection and HttpMethod
> objects? So I could control the settings on a "client by client",
> "connection by connection",  or "method by method" basis?" by Mark R.
> Diggory, 2002-9-18.
> 
> Any single object (e.g. Cookie) must therefore know which Configuration
> applies to it. This means that the creator of an object must set its
> configuration in the ConfigManager. For static classes  the requirement
> can not be fulfilled at all. Not so nice, is it.
> 
> Please, if any of you has a good idea how to deal with this, drop me a
> note.
> 
> 
> Odi




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [logging] VOTE for cutting release 1.0.2

[Costin Manolache]

Richard Sitze wrote:

> I volunteer to be the release manager.
> 
> This is also my explicit vote for cutting 1.0.2:  +1
> 
> By my count, current binding votes are at:
> 
> +12  (scott sanders, richard sitze)
> +00
> -10

+1 as well.

As this is a majority vote ( as any release vote ) - it seems 
to pass. ( unless 2 -1 votes will be made ).

Regarding the status - not sure I understand what you need. If 
you are a commons commiter, you can add yourself to any commons
project you like.


Costin



> 
> 
> ***
> Richard A. Sitze
> IBM WebSphere WebServices Development
> 
> 
> On Thursday, September 26, 2002, at 03:07 PM, Richard Sitze wrote:
> 
>> I volunteer(ed) [I wouldn't ask for a vote without doing that :-]  I
> will
>> happily stand aside if there is anyone with experience who would prefer
> to
>> do it.
> 
> i'm happy about you acting as release manager but it's probably better to
> say it explicitly.
> 
> we gathered quite a few -1's (on this principle) the last time we tried to
> 
> release without explicitly naming a release manager.
> 
> - robert
> 
> 
>> I DON'T have an account on daedelus, but I've had a number of offers
> from
>> various folks, who do, that are willing to help me with that.
>>
>>
>> ***
>> Richard A. Sitze
>> IBM WebSphere WebServices Development
>>
>>
>> On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote:
>>
>> 
>>
>>> 4.  Folks, if you are committers, please update the commons-logging
>>> STATUS.html document with your name, and that includes myself! :-)
>>
>> 1. i'd suggestion that people do this ASAP since (by my count) there are
>> not enough votes from committers for the required quorum.
>>
>> 2. a release manager is required. that person needs to be a committer
> (see
>>
>> 1) and (probably) needs an account on daedelus. any volunteers?
>>
>> (FYI my vote would be binding...)
>>
>> - robert
>>
>>
>> --
>> To unsubscribe, e-mail:   <
>> mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail: <
>> mailto:[EMAIL PROTECTED]>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:    .
>> org>
>> For additional commands, e-mail:  .
>> org>
>>
> 
> 
> --
> To unsubscribe, e-mail:   <
> mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <
> mailto:[EMAIL PROTECTED]>

-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [configuration]

[Costin Manolache]

FYI, on tomcat-dev we agreed ( AFAIK ) to use JNDI as the 
configuration storage API, with jndi providers for the current data
source ( server.xml, jk.properties, etc ). 

We'll continue to use a 2-layer config, jndi is just for storage - 
normal ant-like reflection/introspection will be used to configure
most components.

Costin

Stephen Colebourne wrote:

> There's quite a bit of code here that could be useful. I tried to have a
> look at the [configuration] project in commons sandbox to compare, but
> didn't have the time to do it properly. I suggest you might like to
> produce a compare and constrast list for your version versus the current
> commons sandbox version.
> 
> I should also point out that my own philosophy is not to use configuration
> like this. I choose to use resources for all configuration, even if its
> not locale specific. That way the program can become localised quickly if
> needed later. (I have my own framework for resources that allows XML
> resource files and classes that get the locale passed to them so they can
> do database lookups for example)
> 
> Stephen
> 
> PS. Your beans package is similar to my www.joda.org package, you might
> want to take a look.
> 
> - Original Message -
> From: "Eric Daugherty" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, September 21, 2002 12:21 AM
> Subject: [configuration]
> 
> 
>> I came across the configuration project today.  I have written my own
>> open source library that includes a configuration framework that is
>> fairly similar to the new 1.4 prefs package.  (I wrote it before the 1.4
>> package was released, or at least before I knew about the new package).
>> Since I wrote it without before looking at the prefs package, they are
>> more similar in concept than in actual API.
>>
>> My entire library is available at
>> http://ericdaugherty.com/java/daughertylib/index.html.
>>
>> I would be happy to contribute any and all of the code in this library
>> to the configuration package.  Also, I would be willing assist in the
>> development and/or maintenance of the package, if there is interest.
>>
>> Eric Daugherty
>> http://www.ericdaugherty.com/java
>>
>>

-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: