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

[Simon Kitching]

On Fri, 2004-12-10 at 13:20, Charles Daniels wrote:
> > -Original Message-
> > From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, December 09, 2004 4:54 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
> > 
> > I'm not a logging expert, but couldn't the internationalized 
> > logger be 
> > just a specific Log implementation ? You would just log the 
> > key of the 
> > message with the existing methods :
> > 
> > log.warn("key");
> > 
> > The Locale would be a configuration parameter. There is just an issue 
> > with the message's parameters :) This will require at least an 
> > additional method like warn(String, Object[]).
> 
> Since all of the logging methods (fatal, error, etc.) accept a message
> of type Object, you could support i18n/l10n by doing something like the
> following:
> 
> log.warn(new Message("key", params));
> 
> where params is an Object[].  Of course, Message could have additional
> constructors.
> 
> The Message class would encapsulate all l10n functionality.  This way,
> you probably wouldn't even have to create any new implementations
> specifically for handling i18n/l10n.  Further, you probably wouldn't
> even have to modify existing Log implementations since most of them
> (perhaps all?) just end up doing something like String.valueOf(message)
> to get the actual text to log.  Therefore, the new Message class would
> simply implement toString to properly construct the localized message.

Alas, I don't think that is efficient enough. This approach would
require a new Message object to be created *before* each call,
regardless of whether that logging level was enabled or not.

Of course, each call could be wrapped in:
  if (log.isWarnEnabled()) {
log.warn(new Message());
  }
but that would get tiring very quickly!

Actually, for warn/error/fatal, this approach is probably not too bad.
After all, there won't be a whole lot of such calls, and they *are*
likely to have logging enabled.

It's only for debug/trace levels that this approach would have problems.
Is it really important to "globalize" debug and trace messages?

Regardless of the performance, though, there is still the matter of
exactly where the messagekey+params gets converted to a message string.
Having a user-provided Message object do it delegates the responsibility
of locating the i18n resource bundle to the logging app, which may or
may not be appropriate. Having an underlying log adapter class do it (a
kind of "i18n decorator" pattern?) raises the issue of how it would
locate the bundle. Log adaptor classes don't currently deal with
configuration in any way AFAIK; they just pass the message down.

Regards,

Simon


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

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

[Simon Kitching]

On Fri, 2004-12-10 at 14:23, Simon Kitching wrote:

> Alas, I don't think that is efficient enough. This approach would
> require a new Message object to be created *before* each call,
> regardless of whether that logging level was enabled or not.
> 
> Of course, each call could be wrapped in:
>   if (log.isWarnEnabled()) {
> log.warn(new Message());
>   }
> but that would get tiring very quickly!

Not to mention that it is pretty much equivalent to:
  if (log.isWarnEnabled()) {  
// compute internationalised message by hand
// using a resource bundle, key + params
log.warn(msgString);
  }



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

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

[Simon Kitching]

On Sat, 2004-12-11 at 15:24, Noel J. Bergman wrote:
> It disturbs me that what seems to me to be a reasonable and small set of
> requirements --- along with what appears to have been considerable
> forethought based upon real world issues, and experiences supporting many
> developers --- appears to be discounted a bit too out of hand.  I hope my
> perception is wrong.
> 
> Does anyone really dispute the requirement to support localization for log
> messages or the additional JSR-mandated logging requirements?  If not, then
> let's work constructively towards satisfying the requirements.  And not by
> relying upon some IDE's tooling.

I am quite sure the IBM Websphere team have a good idea of what J2EE
environments need in terms of logging. And I believe their proposal
should be given serious consideration.

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

I will dispute localisation of log messages if this:
(a) forces commons-logging to terminate support for underlying logging
implementations that don't provide this feature, or
(b) forces commons-logging to include a "configuration layer" that it
didn't previously need so that it can implement i18n within
commons-logging.

In neither case would this mean the requirements are wrong; it just
means (IMHO) that the implementation shouldn't be in commons-logging.
(Note: it's not clear to me whether IBM's proposal has problems (a) or
(b) or not).

My initial thoughts were that i18n support was a good idea. But the more
I think about it, the more concerns I have about whether these can be
included in commons-logging without making it unfit for purposes it is
currently used for.

I also dispute adding APIs to commons-logging if they encourage poor
software design, just because JSR-47 has that API. I've been convinced
by the arguments put forward in this thread that explicit enter/exit
methods taking class+method strings should not be encouraged because of
that (in addition to the practical issue of what to do with logging
implementations that don't have methods taking class/method names).

I look forward to seeing further discussion on i18n support + logging
config, and would be very happy to see improvements made to JCL - as
long as they fit.

Regards,

Simon


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

Enterprise Logging

[Simon Kitching]

Hi Richard,

The class javadoc for the EnterpriseLog class states:

Please note that a specific implementation of Commons Logging can choose
to support either the simple logging interface (represented by [EMAIL PROTECTED]
Log}) or the advanced logging interface (represented by this
interface).  A user of a Common Logging implementation that supports
only the simple logging interface will not be able to instantiate a
EnterpriseLog. 


Given the following code:

if ((day == saturday) || (day == sunday)) {
  EnterpriseLog log = EnterpriseLogFactory.getLog(...);
  log.error("This code doesn't work on weekends");
}

are you proposing that this code will run fine all week, then suddenly
throw a runtime error on saturday if the underlying log implementation
does not support "enterprise" logging?

While this example is a bit contrived, I can certainly envisage an app
put together with modules, one of which uses "enterprise" logging, and
is only invoked under some conditions...

Incidentally, it looks like JCL itself will throw an exception on
startup if an explicit log implementation is specified (eg via system
properties or commons-logging.properties) but that implementation cannot
be found. This is quite in contradiction to the log4j logging approach,
which is that an app should *never* fail just because logging fails. I
prefer the log4j philosophy myself...

Regards,

Simon


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

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

[Simon Kitching]

On Sun, 2004-12-12 at 08:04, David Graham wrote:
> What you're seeing is the natural result of design conversations held
> outside of the mailing list.  No one here had the benefit of participating
> in the localized logging design so naturally we're asking questions and
> making suggestions.  
> 
> Additionally, it might have helped all of us if the proposal didn't use
> marketing hype terms devoid of meaning (ie. "enterprise") to describe what
> is actually a small and reasonable set of additions related to localized
> messages.

On the subject of the "EnterpriseLog" name proposed by Richard: if you
read the commons-logging "user guide" document, you will see where that
name came from:
  http://jakarta.apache.org/commons/logging/guide.html

Despite this, I agree that it is probably still too grand a name for the
classes used to support the patterns described in the "enterprise"
section of this doc.


NB: As Richard Sitze has noted elsewhere, he actually wrote at least the
"enterprise" section of this document. Unfortunately the cvs log doesn't
show that, presumably because the file was moved from somewhere else
when the build process was 'mavenised'.

The terminology in that doc is *probably* derived from the fact that
Richard works on J2EE frameworks. The patterns described there certainly
are useful when a commercial entity has a support "contract". And they
are useful in environments where software monitoring/alerting systems
are in place (eg Nagios/BigBrother/Zabbix/Tivoli/OpenView). But they can
also be regarded as good practice for many open-source frameworks and
libraries that would not typically refer to themselves as "enterprise"
software.

Richard: sorry if I misrepresented your view on any of this.

Cheers,


Simon


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

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

[Simon Kitching]

On Thu, 2004-12-16 at 10:21, Richard Sitze wrote:
> "Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/15/2004 

> > ...byte-code engineering contradict each other. One of the really,
> > really strong things of c-l is, that it needs no additional jars. Just
> > drop commons-logging in, develop your app, deploy with the app,
> > commons-logging and a logger implementation, off you go.
> 
> This is a strong point from a "lazy" point of view [no offense, please]. 
> But it's also one if it's greatest weaknesses.  You have no way of knowing 
> which logger impl. you are going to be using.  Yes, you can configure. No, 
> there is no assurance that what you configured will be used...   you can 
> check it once, but when you start deploying your applications in 
> production, you have to re-check.. and re-check... and you never know when 
> someone's going to change the classpath and change the behavior.  It's a 
> nightmare.

I think this demonstrates a major issue.

When using logging in an "enterprise" situation, the logging can be
considered a critical part of the application. If you have heavy-duty
monitoring systems watching for alerts from the software, and have
sysadmins on call 24x7 to deal with issues, then for an application to
fail to locate the correct logging libs or config files is a *failure*
of the app. You don't want an app to start up, but then not be able to
generate alerts if problems occur.

But when using logging in other situations, logging is *not* a critical
part, and should not cause an application to fail to start.

The latter is the focus of commons-logging at the moment. And
unfortunately as commons-logging has no *mandatory* configuration, it is
not possible to add a "fail-on-no-config" option!

So perhaps we could build two separate jars from mostly-common source
code? Deploying the traditional commons-logging jar would do the "be
quiet on no config", while the "enterprise" commons-logging jar would do
something like "write message to STDERR then throw a runtime exception
on no config"?

> Yes, I want to maintain the "easy" route as much as possible, but it's 
> time we adopt proven best practices from the industry and stop falling all 
> over ourselves to keep a few programmers happy.  It's easier to figure out 
> what your problem is if you missed one of two required jar files, than it 
> is to debug the current situation.  Strategies have been discussed in more 
> detail on other threads, so I'm not going to go in this any further here.

I think this depends on what your application's goal is. You seem to be
thinking *only* of commons-logging from a J2EE point of view. Writers of
stand-alone apps often want exactly the behaviour that commons-logging
currently gives, and would be very against commons-logging terminating
apps unless config is found.

I hope that my suggestion above (two commons-logging variants built from
a common source tree) provides a way to address both goals without
having to create a separate fork for "enterprise" logging.

> 
> > I'd very much like to keep that, which means that any bytecode
> > manipulation code should be part of the commons-logging jar. I'd like
> > to avoid getting dependent on things like BCEL.
> 
> I'm cool with any byte-code manip as an ant task, for those who want to 
> pull those dependencies into their environment.  But JCL should not start 
> down this path [redundant with other projects, just like it's discovery is 
> redundant with Jakarta Commons Discovery... admittedly JCL came first].
> 
> So I'll repeat an earlier request: anyone want to submit the correct 
> AspectJ [and other's are of course welcome] declarations to perform this 
> type of work?  Even if it's a few lines in the User's Guide. 

I notice that just4log (just4log.sourceforge.net) supports automatically
adding entry/exit logging at compile-time. 

Regards,

Simon


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

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

[Simon Kitching]

On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote:
> Simon Kitching wrote:
> > I think this demonstrates a major issue.
> > 
> > When using logging in an "enterprise" situation, the logging can be
> > considered a critical part of the application. If you have heavy-duty
> > monitoring systems watching for alerts from the software, and have
> > sysadmins on call 24x7 to deal with issues, then for an application to
> > fail to locate the correct logging libs or config files is a *failure*
> > of the app. You don't want an app to start up, but then not be able to
> > generate alerts if problems occur.
> > 
> > But when using logging in other situations, logging is *not* a critical
> > part, and should not cause an application to fail to start.
> > 
> > The latter is the focus of commons-logging at the moment. And
> > unfortunately as commons-logging has no *mandatory* configuration, it is
> > not possible to add a "fail-on-no-config" option!
> > 
> > So perhaps we could build two separate jars from mostly-common source
> > code? Deploying the traditional commons-logging jar would do the "be
> > quiet on no config", while the "enterprise" commons-logging jar would do
> > something like "write message to STDERR then throw a runtime exception
> > on no config"?
> 
> Why not just introduce a boolean parameter that says whether or not an 
> inability to log is a failure?  e.g.
> 
> Log log = LogFactory.getLog(MyClass.class, true);

It's not "inability to log" as such. It's whether finding no specific
config info or underlying log implementation and therefore falling back
to using java.util.logging (java>=1.4) or
org.apache.commons.logging.SimpleLog (java<1.4) is allowed or not.
 
In many cases, what you *want* an app to do if it can't find any
specific logging config is simply to output ERROR and FATAL messages to
stderr. This is what commons-logging will currently do if its
"discovery" process finds nothing.

I guess commons-logging *could* use a parameter such as you suggest to
indicate "explicit configuration of logging is mandatory". This would
presumably mean detecting whether commons-logging.properties or the
corresponding system properties have defined an explicit log
implementation and config file for that implementation.

I'm not sure, however, if the decision on whether logging is mandatory
or not should be a compile-time one. It seems to me to be more like
something the application *deployer* should choose. That then leads us
to a circular reference: how do we know whether configuration is
mandatory or not, if we can't find any configuration?

Regards,

Simon


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

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

[Simon Kitching]

Hi Chris,

On Sat, 2004-12-18 at 11:32, Chris Lambrou wrote:
> >Someone suggested that for Log, it would be appropriate to make it an 
> >abstract class rather than an interface, so we can make these kinds of 
> >changes easier in the future.  

That was me (inspired by Robert Donkin's enthusiasm for using abstract
classes rather than interfaces in digester).

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

First, I was suggesting that instead of introducing a *new* *interface*
(Richard's proposal) to provide an extended API that a *new* *abstract
class* be introduced. Neither of us were proposing changing the existing
Log interface.

But if the Log interface were to be changed, then adding methods to it
would break binary compatibility. The most obvious way is that classes
that were previously valid implementations of the interface become
incomplete.

Suppose for a moment that we were to choose between adding methods to
the Log interface, and turning it into an abstract class with some
methods; I don't understand what "real pain" would be incurred by having
custom logging adapters be declared as:
  public class FooLog extends Logger {...}
instead of the existing
  public class FooLog implements Log {...}

Sure there would be some inconvenience, but wouldn't it be the same as
having to update the existing log implementation to add implementations
for the new methods added to a Log interface? Making this sort of change
would indeed "annoy" users as they couldn't used their existing
log-specific adapters with the new JCL release without modifying them.
But that would be the case even if the Log class remained an interface.

And once a move to using abstract classes has been made, we *can* extend
the API later without breaking binary compatibility as long as a
reasonable default implementation can be provided.

The only problem would be if someone had an adapter class that for some
reason needed to extend some other existing class. But I don't see why
that would happen for a logging adapter, and there are reasonable
workarounds for this anyway (eg using a trivial inner class).


Regards,

Simon


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

Re: Jakarta Commons Structure rehashed

[Simon Kitching]

svn 1.1 (released 2004-09-29) supports "symbolic links". Perhaps that
would resolve the issue by allowing us to (manually) build an
alternative directory containing just symbolic links to the "trunk"
directory of each subproject? Of course whenever a new subproject was
created, a symbolic link would need to be manually added - but that is
no great problem. Possibly that could even be automated; I'm willing to
try to get that working.

Regards,

Simon

On Sat, 2004-12-18 at 12:10, Henri Yandell wrote:
> And yet option A is going to be impossible (?) to check out as one whole blob.
> 
> I wonder if there's any magic coming from the SVN guys that'll let us
> do option B and yet provide a link of some kind to automatically be
> able to check out all the trunks in one go.
> 
> Hen
> 
> On Fri, 17 Dec 2004 14:01:53 -0700, Kris Nuttycombe
> <[EMAIL PROTECTED]> wrote:
> > Option A makes the projects look a lot more atomic, which seems like a
> > good idea when one contemplates what will be necessary when promoting
> > projects from the sandbox.
> > 
> > Kris
> > 
> > Tim O'Brien wrote:
> > 
> > >I don't think we ever settled this question.
> > >
> > >Which SVN structure are we interested in?
> > >
> > >** Option A:
> > >
> > >jakarta/
> > >commons/
> > >digester/
> > >trunk/
> > >tags/
> > >branches/
> > >beanutils/
> > >trunk/
> > >tags/
> > >branches/
> > >
> > >OR
> > >
> > >** Option B:
> > >
> > >jakarta/
> > >commons/
> > >trunk/
> > >digester/
> > >beanutils/
> > >tags/
> > >digester/
> > >beanutils/
> > >branches/
> > >digester/
> > >beanutils/
> > >
> > >
> > >
> > 
> > --
> > =
> > Kris Nuttycombe
> > Associate Scientist
> > Geospatial Data Services Group
> > CIRES, National Geophysical Data Center/NOAA
> > (303) 497-6337
> > [EMAIL PROTECTED]
> > =
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


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

RE: Jakarta Commons Structure rehashed

[Simon Kitching]

On Mon, 2004-12-20 at 08:36, Tim O'Brien wrote:
>  
> > -Original Message-
> > From: Martin Cooper [mailto:[EMAIL PROTECTED] 
> 
> > I think we're trying to find a compromise that satisfies 
> > both. As long as someone can come up with a way to do the 
> > equivalent of the '*' URL I mentioned above, I'd be happy 
> > with A + that script / tool / method.
> 
> Add, externals definitions to that list.
> 
> Assume that /jakarta/commons/proper/current is just a directory with
> externals to every trunk for components in commons proper, and
> /jakarta/commons/sandbox/current is just a directory with externals to
> every trunk for sandbox components.  I could also see someone wanted to
> checkout only the current production release of every component, we
> could similarly have a /jakarta/commons/proper/production which would
> contain externals pointing to the latest official release tag.
> 
> See section 7.3 "External Definitions" of Version Control with
> Subversion by Collins-Sussman, Fitzpatrick, and Pilato.  You can read
> that book on Safari or online for free here:
> http://svnbook.red-bean.com/.  
> 
> 

+1

That seems like a good solution to me. The projects are then nicely
self-contained, but people learning commons, or tools that scan the
whole of commons (eg automated license checkers or gump-like tools) can
get access to the latest code of all projects via proper/current. 

Setting up a proper/production might be a bit trickier (or at least
ensuring it *stays* pointing to the right target dir).

NB: It was me who raised the issue of "being able to check out HEAD of
all projects" in the first place..

Cheers,

Simon


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

Re: [logging] ECL: Log interface vs. abstract class

[Simon Kitching]

On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote:
> In  my last  message, I  failed to  emphasize the  brittleness  of the
> "break  into  interfaces" hypothesis.   Even  if  at  a high-level  of
> abstraction two  APIs perform the same  task, this does  not mean that
> they can be abstracted away by a thin facade (or bridge). For example,
> all the attempts  made at bridging X.25 and  TCP/IP, both well defined
> and  stable protocols,  have  failed miserably,  even  if both  stacks
> supposedly fit into layers 1-4 of the 7 layer OSI network model.

I quite agree with this. 

And I don't think the approach of providing multiple optional interfaces
in commons-logging to support "advanced" features that various logging
libraries implement is useful either. As I've written in previous
emails, I do *not* like the idea of an application failing to start
because an appropriate logging implementation is not present.

I think commons-logging should be a *simple* API that abstracts only the
*basic* functionality of logging. The current API is fine; log strings
at various priority levels to a single named category. Any reasonable
log implementation will be able to provide a sane mapping for these
concepts.

But I don't think it is worth trying to extend JCL much beyond this. As
Ceki says, logging libraries can provide widely varying features and it
is not productive to try to map these to portable APIs.

JCL does a very useful job for jakarta-commons libraries: provide a
means for the commons libraries to implement logging without enforcing a
logging implementation on the larger app which uses the library. Note
that the kind of log messages generated by commons components are of
course implementation-related and are therefore aimed at the *developer*
not the user. For this reason, i18n support is not terribly useful for
commons component logging.

However I'm not convinced that for *applications* (rather than
libraries) it is sensible to use JCL at all; why not just pick a
concrete logging implementation and use that? You get all the necessary
features, and apps can deploy whatever logging implementation they want.

The only awkward situation is container frameworks like J2EE. In this
case, you may want logging to be redirected to the container's logging
implementation so that logging from all apps within the framework is
treated consistently. I can see some kind of common API cabable of
generating i18n messages being useful here. 

After all the discussion on logging recently, I'm coming to the
conclusion that Richard's original proposed features (i18n, discovery
changes) should *not* be included in JCL. None of these features help
commons components with their logging requirements, and these features
*are* going to make JCL significantly more complex and controversial. It
would be better to start a separate project. If this project can
successfully resolve the issues then maybe it could be merged back in to
JCL.

To summarize, my (non-binding) votes are:
  -1 to adding extra *optional* features to JCL that fail if the
"discovered" logging implementation doesn't suport them. This
includes Richard's EnterpriseLog class, and Matt Scarlata's
proposals too.
  -1 to *mandatory* configuration for JCL
  +1 to keeping JCL as a least-common-denominator logging API that
can be used for commons components.

Regards,

Simon


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

Re: new joinee!!

[Simon Kitching]

On Thu, 2005-01-06 at 14:00 +1100, [EMAIL PROTECTED] wrote:
> Hi Guys,
> 
> I just joined this community and I would like to contribute also, but not 
> sure how to start.
> 
> If there is any piece of work, please let me know.

Hi Ankur,

Welcome to jakarta commons.

Regarding "projects to work on", you will find commons a bit different
from other open-source projects, mostly because "commons" isn't actually
a project at all; it's a collection of (mostly unrelated) useful
libraries.

Because of this, commons isn't really about completing some standard
API, or implementing some grand project design. Instead, development is
much more driven by specific needs people have in their day-to-day work
(open-source or commercial). And in general, code is not added to
commons unless there is going to be at least one immediate user of that
code; putting stuff in "because it might be useful sometime" is not
generally regarded enthusiastically here at jakarta-commons.

So in short, you may or may not get a response to your offer of help.

Please don't be disappointed if no-one suggests something. Instead, get
familiar with the existing commons libraries (and while you're doing
that by reading javadoc and unit tests, patches for those unit tests,
javadoc, etc would be very welcome). After that, look at the other
projects you are currently working on; are there pieces of code in there
that fit well with one of the commons libs and are likely to be useful
to many different programs? If so, then that is a good time to post a
proposal in commons-dev to enhance that commons library, but only if you
also intend to migrate that project to *use* the commons code.

One other place to look is in the bugzilla/Jira bugtracker system, which
lists both bugs and requested enhancements. But if you are thinking
about helping out with one of these, I suggest posting on the list first
before spending too much time on one; sometimes enhancement requests
suggest things the commons maintainers for the project don't agree with,
or would prefer to tackle in a different manner.

In general, I believe the way developers generally end up involved here
is because they are *users* of a commons library, and need extra
functionality or need bugs fixed, contribute for that specific purpose,
and just never leave :-). Alternatively, many have developed code that
they found themselves using in multiple projects, offered to move that
useful code to a commons library, and remained here as one of the
maintainers. 

So once you're familiar with commons, it might be better to get involved
with some other project that interests you and which *uses* a commons
lib (eg tomcat, slide, maven, jedit, ...). Those projects generally do
have long lists of "required features" or "unfixed bugs" that are
awaiting keen developers. And you may then find that some of those
bugs/features are best implemented by fixing/enhancing a commons
library!

Regards,

Simon



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

Re: [digester] Problem building javadoc w/ Ant on Windows

[Simon Kitching]

On Mon, 2005-01-17 at 19:06 -0700, Wendy Smoak wrote:
> From: "simon" <[EMAIL PROTECTED]>
> > It does seem
> > weird that this doesn't work on Windows, as the xml spec is *very* clear
> > about the fact that xml attributes can be quoted using '...' or "...",
> > so having a simple testcase that shows the problem would reassure me
> > that the problem really is what we think it is..
> 
> We're talking about this section of build.xml:
> 
>  bottom='Copyright (c) 2001-2004 - Apache Software 
> Foundation '>
> 
> First, without the quotes around "AS IS", the generated HTML source has only 
> one line for me when viewed with FireFox and IE, so all the white space and 
> formatting doesn't seem useful.  The quotes around the word "License" do not 
> cause a problem, *but* they do not make it into the generated HTML either.
> 
> Can someone build the docs with Linux and confirm that the formatting and 
> the quotes around "License" and "AS IS" actually make it into the generated 
> HTML?  Because if not, the quotes can be removed from build.xml without 
> affecting the output.
> 
> Given that this build.xml isn't actually used to build the documentation 
> that goes on the website, and that the HTML comment that's causing the 
> problem doesn't even appear in the current Javadoc (such as 
> http://jakarta.apache.org/commons/digester/apidocs/org/apache/commons/digester/Digester.html
>  )
> how important are those quotes?

In versions prior to 1.53, the "bottom" text was just a simple copyright
statement. In 1.53.2.3, Robert Donkin added the extra text to this
attribute.

As you can see, all the additional text is actually wrapped within xml
, so it isn't visible when viewing the javadoc from a
browser. But it is visible if you use "view frame source", or load
the .html file in an editor.

And for me, the quotes present in the text are preserved. The formatting
isn't, but that isn't really important. The important point is,
presumably, to ensure a proper licence statement is present in each
generated javadoc page.

See the source for this page:
http://jakarta.apache.org/commons/digester/commons-digester-1.6/docs/api/overview-summary.html
for an example of what I get when generating the javadoc.

> 
> Attempting to fix the problem, once I get rid of the quotes around "AS IS" 
> then I start getting these warnings:
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: warning - Multiple sources of package comments found 
> for package "org.apache.commons.digester"
>   [javadoc] javadoc: warning - Multiple sources of package comments found 
> for package "org.apache.commons.digester.parser"
>   [javadoc] javadoc: warning - Multiple sources of package comments found 
> for package "org.apache.commons.digester.plugins"
>   [javadoc] javadoc: warning - Multiple sources of package comments found 
> for package "org.apache.commons.digester.plugins.strategies"
>   [javadoc] javadoc: warning - Multiple sources of package comments found 
> for package "org.apache.commons.digester.substitution"
>   [javadoc] javadoc: warning - Multiple sources of package comments found 
> for package "org.apache.commons.digester.xmlrules"
>   [javadoc] javadoc: warning - Multiple sources of package comments found 
> for package "org.apache.commons"
>   [javadoc] javadoc: warning - Multiple sources of package comments found 
> for package "org.apache"
>   [javadoc] javadoc: warning - Multiple sources of package comments found 
> for package "org"
>   [javadoc] Standard Doclet version 1.5.0_01
> 
> I have no idea what it's talking about.

I'm not sure what the "multiple sources" messages are either. But they
don't seem to cause any problems, so I have just been ignoring them.

> 
> > Ok, so can this be fixed by escaping the quotes in the problem text, eg 
> > using "?
> 
> Using "AS IS" doesn't work, I get the same error as with the 
> original "AS IS".
> 
> Chalk this one up to annoying but easily fixable.  Other than deleting the 
> quotes around "AS IS" (which might annoy the lawyer types) I don't see what 
> else to do with it.
> 

First up, I guess the question is whether this extra text *needs* to be
present at all. I'm no lawyer, but it seems rather redundant to me,
given it has been generated from a source that does have copyright info
on it, that the javadoc is not useful as a stand-alone product, and that
APIs c

Re: [digester] Problem building javadoc w/ Ant on Windows

[Simon Kitching]

On Tue, 2005-01-18 at 08:40 +0100, Dennis Lundberg wrote:
> I did some digging in the mail-archives and found the thread I was 
> talking about earlier. It can be found here:
> 
> http://mail-archives.apache.org/eyebrowse/[EMAIL 
> PROTECTED]&by=thread&from=666491
> 
> Note that eyebrowse sorts the e-mails with newest-first, so start 
> reading from the bottom up...
> 
> Let me know if there's anything I can do to help.

That's very useful indeed.

So "escaping" of quotes in the "bottom" text for javadoc is necessary on
Windows but not on Linux or Mac. And escaping the quotes can be done
with backslashes, but if you do that then those come through to the
generated html page on Linux. Yecch.

Well, I think I'll raise a bugzilla entry with this info, as a reminder
to think about this further. But for the moment, I'm inclined to leave
digester as it is, until Robert Donkin reappears and lets us know why
this was added in the first place.

Maybe a comment in the build.xml would be useful too...

Anyone got any alternative suggestions?

Regards,

Simon


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

Re: [all][poll] svn conversion

[Simon Kitching]

On Wed, 2005-01-19 at 00:21 -0500, Henri Yandell wrote:
> My opinion is that we should call a vote asap, and anyone who is -1's
> should use the test to prove their point. While we still have the test
> up.
> 
> I'd suggest a 1 week vote. Any -1 with worthy reason is enough to stop
> it, but we would be aiming to come up with solutions to any -1's (in a
> different email thread).

Sounds good to me



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

Re: [logging][PROPOSAL] 1.0.5 release

[Simon Kitching]

On Wed, 2005-01-19 at 22:49 +, robert burrell donkin wrote:
> IMO the first step before any work can begin on any improvements is to 
> release the current code (this contains an important enhancement 
> improving memory release in the 1.0.x series of releases).  therefore, 
> i propose that we should start the release process for 1.0.5 by 
> electing a release manager and formulating a release plan.
> 
> i'm willing to act as release manager for this release. my vision would 
> be that a release branch would be taken as soon as possible but with a 
> long release candidate phase would follow to allow the release to be 
> tested.

+1



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

[digester][VOTE] Remove licence text from javadoc

[Simon Kitching]

Hi,

In August 2004, the build.xml file was modified so that when generating
Javadoc a copy of the apache licence was inserted as an xml comment into
the footer of generated pages.

Unforunately, this has caused complications, because javadoc appears to
have cross-platform issues with the quote marks in the text; on
MS-Windows, the quotes need to be escaped or a javadoc error is
reported, but if they are escaped then the escape marks get copied
verbatim to the output under Linux.

In addition, this change makes the build.xml file a bit clumsy; the
license is quite a lot of text to fit into an xml attribute!

Yes, it would be possible to have separate footer text for windows vs
linux, but that would make build.xml even uglier.

The licence text seemed unnecessary to me, as:
* Javadoc is not useful as a "stand-alone" product; 
* Javadoc is generated from source files which *do* have complete
license text within them; and
* the output documents an API, with APIs not being copyrightable

I posted a question to [EMAIL PROTECTED] re this, and got this
reply:
=
On Thu, 2005-01-20 at 07:58 -0800, Brian Behlendorf wrote: 
> On Wed, 19 Jan 2005, Jeffrey Thompson wrote:
> > Interesting question.  First, a perspective point.  The copyright notice in
> > the file is primarily for Apache's benefit.  It puts people on notice that
> > Apache claims copyright on the material.
> 
> Well, first, it really should be:
> 
>   Copyright [] The Apache Software Foundation or its licensors, as
>   applicable.

[snip]

> 
> > On the other hand, the license (though it does have some benefit to Apache)
> > is primarily for the user's benefit.  Without it, the user has no license
> > at all.
> >
> > So, is the user put at a disadvantage in any way because the license isn't
> > embedded in the JavaDoc?  Wouldn't anyone who understands how JavaDoc works
> > know exactly how to find out what license is available for that material?
> 
> My sense is that this is splitting hairs a bit and that the full license, 
> or even the reference to it, doesn't need to be included in the javadoc 
> output - just as we don't embed it as a string in compiled code when we 
> distribute binaries.  

=
So in summary:

I propose that the build.xml footer text be modified to contain:
 
  Copyright 2001-2004 The Apache Software Foundation 
  or its licensors, as applicable.

And that the licence text be removed.

You can see the entire thread at:
http://mail-archives.eu.apache.org/mod_mbox/www-legal-discuss/200501.mbox/index.html
with subject: "Licence required in Javadoc output?"

Regards,

Simon


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

Re: [all][VOTE] svn migration

[Simon Kitching]

On Sat, 2005-01-22 at 13:31 -0500, Tim O'Brien wrote:
> Alright a sufficient amount of time has passed for public comments and
> testing.
> 
> This is a vote thread for migrating commons to SVN.  If this vote
> passes, I'll contact Justin and schedule the least disruptive migration
> time possible.

+1



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

Re: [i18n,xmlio] current class diagrams

[Simon Kitching]

On Wed, 2005-01-26 at 05:08 -0800, Anaximandro (Woody) wrote:
> >Is your server up? I wanted to have a look at your diagrams, but the
> >request timed out :(
> >Oliver
> 
> Well, I´m in Brazil. This server is not so good ...
> Please, can you try more one time and reply to me knows?

Are you a commons committer? If so, are you aware that apache provides
each committer a homepage available that you can use for this sort of
stuff?

Regards,

Simon


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

Re: [i18n,xmlio] current class diagrams

[Simon Kitching]

On Wed, 2005-01-26 at 06:52 -0800, Anaximandro (Woody) wrote:
> >Are you a commons committer? If so, are you aware that apache provides
> >each committer a homepage available that you can use for this sort of
> >stuff?
> 
> Simon, I´m not a commiter yet, maybe soon. Who knows?

Then if the files you want to distribute aren't *too* large, another
option is to open a bugzilla enhancement request, and attach the files
there. That is probably better than emailing attachments that go to
every person subscribed here...

Regards,

Simon


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

Re: [vfs] proposal: MemoryFS

[Simon Kitching]

I can definitely see this being useful for unit-tests. I was working on
some code a while ago that manipulated files, and found it very hard to
write unit tests, particularly ones that could be run cross-platform.
Having an in-memory filesystem available for unit tests to "store" files
on would have been great..

On Wed, 2005-01-26 at 18:07 -0600, Jeffrey D. Brekke wrote:
> It may be useful for testing also.
> 
> B. K. Oxley (binkley) wrote:
> > I'm thinking of implementing a "memory filesystem" with VFS as a 
> > demonstration.  The demo filesystems for local files and URLs are fine 
> > and good, but they are not very pedagogic for implementing virtual 
> > features.  For example, they do not do much with attributes.  A 
> > filesystem implementation which stored everything in memory would permit 
> > demonstration of the full range of features for VFS.
> > 
> > I suppose there might be practical use as well as a scratch filesystem 
> > which does not use the disk (unlike tempfs).  One might also provide 
> > layering ala BSD's union filesystem so that one could rollback changes 
> > just by removing the most recent layer (I believe this is how ClearCase 
> > works, IIRC).
> > 
> > And it would be fun.  :-)
> > 
> > 
> > Cheers,
> > --binkley
> > 
> > 
> > -
> > 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: Having trouble with svn checkout

[Simon Kitching]

On Sun, 2005-01-30 at 10:02 -0700, Wendy Smoak wrote:
> I'm having trouble checking out a single Commons project:
> 
> $ svn co 
> http://svn.apache.org/repos/asf/jakarta/commons/proper/lang/trunk/commons-lang
> svn: URL 
> 'http://svn.apache.org/repos/asf/jakarta/commons/proper/lang/trunk/commons-lang'
>  
> doesn't exist


As Henri has noted, he got the URL a bit wrong.

However I have just added some info in the wiki about using 'svn ls' to
explore the svn repository:
  http://wiki.apache.org/jakarta-commons/UsingSVN
See section 1, "Misc Info".

I hope this helps..

Regards,

Simon


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

subversion: thanks for the hard work!

[Simon Kitching]

As the subversion changeover for jakarta-commons has gone remarkably
smoothly, I would just like to say thanks to all those who made it
happen, in particular:

  Justin Erenkrantz
  Tim O'Brien
  Henri Yandell

Guys, your hard work is greatly appreciated, and I'm looking forward to
using a 21st-century version control system!

Regards,

Simon


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

Re: Removing Graduated Components from trunks-sandbox

[Simon Kitching]

On Sun, 2005-01-30 at 15:10 -0500, Tim O'Brien wrote:
> I agree with this commit.  
> 
> I think once a component has graduated it should no longer be a part of
> the sandbox, but we might need to make some exceptions for things like
> CLI.  I believe CLI2 was developed in the sandbox eventhough CLI was in
> proper.
> 
> Anyone else have any strong feelings here?
> 
> Someone had mentioned that it would be valuable to preserve history by
> copying sandbox tags and branches to an "archives" directory for each
> component at the same level as branches and tags?  Anyone?

Hmm.. you are proposing that when something gets promoted from sandbox,
that the original sandbox code for {project} should be moved into this
dir?
  commons/proper/{project}/archives

Well, I do agree that code that has been promoted from sandbox should be
removed from the sandbox, leaving the sandbox with only "active"
projects. However I can't see what else would ever live in that
"archives" directory; if there is to be a directory whose only contents
will be the old sandbox stuff (including its own tags, branches, etc),
then perhaps "commons/proper/{project}/sandbox-promoted" might be a
better name than 'archive'?

Alternatively, archives of promoted stuff could be stored externally to
the related projects, eg "commons/sandbox-promoted/{project}" or
"commons/sandbox/promoted/{project}.

If a sandbox project should be declared "dead", then I think it also
should be moved, to commons/sandbox-dormant (or commons/sandbox/dormant)
or similar. Given this, it might make more sense to put promoted
projects in "commons/sandbox-promoted/{project}" than to put them under
the standard project dir.

This would ensure the sandbox contains only "active" projects.

Thoughts?

Regards,

Simon


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

[digester] initial code for Digester2.0

[Simon Kitching]

Hi,

As I mentioned a few months ago, I've been working on some ideas for
Digester 2.0. I've put some code and notes up on 
  http://www.apache.org/~skitching

Comments from all commons-dev subscribers are welcome, but particularly
from Craig and Robert.

The RELEASE-NOTES.txt file gives a brief overview of what I've done so
far, and what I personally would like to see. 

This is *not* intended to be final code, but rather to solicit yes/no
feedback on what people like/dislike about the posted code. As you will
see, many parts are still missing and I personally would still like to
see significant changes even to parts already included (see
RELEASE-NOTES.txt). However the basic structure is there, including a
number of controversial (I expect) name changes.

Once we get the general opinions out, and I have massaged the code into
something that meets general concensus I hope to then add it to the
sandbox for everyone to hack away at.

Cheers,

Simon


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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Mon, 2005-01-31 at 22:20 +, robert burrell donkin wrote: 
> hi simon
> 
> my main development machine blew up last week and i'm still struggling 
> to get up and running on a secondary one.
> 
> i haven't had a chance to look at the code yet (and it might be a fair 
> while before i do) but i'd like to suggest that (when the time comes) 
> you consider developing in proper rather than the sandbox. subversion 
> provides a number of options which weren't available in cvs.

No hurry on having a look at the code. However I have posted javadoc for
the new code here:
  http://www.apache.org/~skitching/digester2-javadoc/api/index.html

So while you're waiting for your new machine, you've now got something
to do Robert :-)


Re developing digester2 in proper: well, it really depends upon whether
there is consensus on the ideas I am putting forward. If people are
unsure, and want to see a more complete framework before saying yea/nay
then sandbox might be more appropriate. If we all agree on the basics,
then proper would be fine.

But yes, it's so much easier to manage branches with svn. Of course
there's no problem either with using "svn cp" to copy from
digester-proper into the sandbox, ie make the sandbox contain a branch
of Digester, right? [go subversion!]


Cheers,

Simon




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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Mon, 2005-01-31 at 11:23 +0100, Emmanuel Bourg wrote:
> "XXXRule --> ActionXXX for all XXX
>By using a prefix instead of a suffix, all the Action classes group
>nicely together in the javadoc."
> 
> I tend to prefer the type as a suffix,

Ok, we'll see what the general consensus is. I happen to personally like
prefixes rather than suffixes, but will go with the majority opinion.

>  to keep them grouped in the 
> javadoc I would rather use an "action(s)" subpackage. With or without 
> 's' is another debate ;)

That sounds reasonable. However I do dislike having mutual dependencies
between java packages; a DAG (directed acyclic graph) is good for a
number of reasons. 

So if we have an "o.a.c.d.actions" package for the standard actions,
then we probably need an "o.a.c.d.factory" package so the ActionFactory
class (which now holds the old Digester.addXXXRule factory methods) can
be pushed down into it. We would then have dependencies of:
 o.a.c.d.actions --> o.a.c.d
 o.a.c.d.factory --> o.a.c.d.actions, o.a.c.d
which is acceptable.

Thoughts?

Regards,

Simon


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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Mon, 2005-01-31 at 21:43 -0700, Wendy Smoak wrote:
> From: "Simon Kitching" <[EMAIL PROTECTED]>
> 
> > Ok, we'll see what the general consensus is. I happen to personally like
> > prefixes rather than suffixes, but will go with the majority opinion.
> 
> Another vote for suffix - I prefer CallMethodAction to ActionCallMethod.

Ok. 

Does this mean you prefer Action to Rule? I certainly expect to hear
from people who want to keep the current names...

> 
> Will ActionFactory have all of the available Action constructor signatures?

Yes. I just don't want to implement them all until the final names have
been decided on...

Regards,

Simon


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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Mon, 2005-01-31 at 21:43 -0700, Wendy Smoak wrote:
> From: "Simon Kitching" <[EMAIL PROTECTED]>
> 
> > Ok, we'll see what the general consensus is. I happen to personally like
> > prefixes rather than suffixes, but will go with the majority opinion.
> 
> Another vote for suffix - I prefer CallMethodAction to ActionCallMethod.

BTW, should we contact the car companies, and tell them their customers
prefer suffixes?
  "Focus Ford"
  "Mustang Ford"
  "Thunderbird Ford"

(I'm mostly kidding...)

Regards,

Simon


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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Tue, 2005-02-01 at 20:40 +0100, Ceki Gülcü wrote:
> On 2005-01-31 9:59:52, Simon Kitching wrote:
> 
>  > As I mentioned a few months ago, I've been working on some ideas for
>  > Digester 2.0. I've put some code and notes up on
>  >   http://www.apache.org/~skitching
> 
> Simon,
> 
> Joran classes and documentation mention that it is influenced by
> Digester. Is your design for Digester 2.0 influenced by Joran? If it
> is, this should be mentioned as a matter courtesy.

Hi Ceki,

The only influence so far is the use of the word Action instead of Rule.
I gave credit to Joran for this influence in my email to the dev list,
but don't think a single name is quite enough to earn credit in the
documentation. And anyway, I'm still waiting to see if people are happy
changing name Rule -> Action.

I did read the Joran code about 12 months ago. I should take time to
look back at Joran again to see if there are any ideas that are suitable
for borrowing for digester 2.0; if this does happen I promise I will
give due credit. If you are aware of anything that might be of use to
Digester, then it would be great if you could point it out...

Regards,

Simon

PS: How's the skiing this season? That's something I really miss after
leaving Switzerland...


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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

Hi Oliver, 

On Tue, 2005-02-01 at 18:04 +0100, Oliver Zeigermann wrote:
> I very much like that and think it really is straight forward.
> 
> Comments:
> - Why is Action an abstract class?

So that we can later add new functionality to Action without breaking
custom Action subclasses that users have written. As long as we can
provide a suitable default implementation in the Action abstract class,
everything runs smoothly.

One example is the "bodySegment" callback that is now in Action. In
Digester 1.x we could not have added this to Rule without breaking all
custom Rule classes. But if digester2.0 had been released without it, we
could have added it later with no source or binary compatibility
problems.

Of course because of Java's single-inheritance policy, it would be
impossible for a class to extend both Action and some other class. But
(a) this is extremely unlikely, and (b) using an "adapter" class works
around this anyway if it absolutely has to be done.

> - Wouldn't it be possible (and even desirable) to have a more general
> Pattern class instead of a String in Digester#addRule?
Can you explain more?

> - I like the bodySegment vs. body design :)
Cool. Now I just have to implement it :-)

The inspiration can be found in the digester 1.6
"src/examples/api/document-markup" example, where the code has to go to
great lengths to handle XHTML-style input.

> - I like the no dependency and digester2 package approach

Ok. I really thought people wouldn't like "o.a.c.digester2". In fact,
I'm not sure I like it myself. The main reasons are:
(1) that I don't know any other projects that do this. Tomcat, struts,
   commons-collections, etc, don't do this.
(2) that upgrading an application using digester 1.x to digester2.x 
requires changes to all the import statements.

As noted, there is still currently a dependency on BeanUtils; digester
uses too much from that package to copy the classes into digester. But
as noted I would like to experiment with accessing BeanUtils
functionality via a custom classloader so that if people have problems
with clashing lib versions there is a solution.

> - It's no secret that I am no fun of reflection stuff: is it really
> necessary to have the subclasses of Action be part of the *very*,
> *very* digester *core*?

Sorry, I don't follow this. Could you explain?

One thing the proposed code does do is separate ActionFactory from
Digester, so the Digester class doesn't have compile-time dependencies
on any Action subclasses.

I quite like Emmanuel Bourg's suggestion of an "actions" subpackage to
hold the subclasses of Action, which would show that they aren't tightly
coupled to the Digester "core" classes.

Or are you by chance referring to my suggestions for xml-rules?

> 
> If so I would be more than happy to abandon xmlio (in) as - apart from
> philosophical considerations - it would be superfluous and I would
> offer development support for digester if that is welcome.

You would be very welcome indeed to work on digester if you wish. 

My memory of our discussions about xmlio/digester is a little vague now,
but I remember coming to the conclusion that their concepts were
different in some fundamental ways. If we *can* find some way to merge
the two projects, though, I'm all for it. Does the fact that Digester
and SAXHandler have been split apart make this possible now?

Regards,

Simon


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

RE: [digester] initial code for Digester2.0

[Simon Kitching]

On Wed, 2005-02-02 at 15:04 +1300, Sharples, Colin wrote: 
> > > - Why is Action an abstract class?
> > 
> > So that we can later add new functionality to Action without breaking
> > custom Action subclasses that users have written. As long as we can
> > provide a suitable default implementation in the Action 
> > abstract class,
> > everything runs smoothly.
> > 
> > One example is the "bodySegment" callback that is now in Action. In
> > Digester 1.x we could not have added this to Rule without breaking all
> > custom Rule classes. But if digester2.0 had been released 
> > without it, we
> > could have added it later with no source or binary compatibility
> > problems.
> > 
> > Of course because of Java's single-inheritance policy, it would be
> > impossible for a class to extend both Action and some other class. But
> > (a) this is extremely unlikely, and (b) using an "adapter" class works
> > around this anyway if it absolutely has to be done.
> 
> I prefer interface + default abstract implementation, the way Swing provides 
> e.g. Action* and AbstractAction. That way a class can still implement the 
> interface even if it extends from something else, and use a delegate to 
> implement the interface. You can still evolve the interface without 
> breaking existing classes that extend the abstract class. Of course, there 
> is nothing to force people to extend the abstract class, but you can make 
> it clear in the doco for the interface that not to extend the abstract 
> class is an explicit design choice that may have dire consequences.

Interesting. 

Extending an interface by adding methods causes source and binary 
incompatibility with all
*implementers* of the interface, but not with *users* of the interface. 

So it is not a problem if classes like SAXHandler reference Action; user 
subclasses
will still work fine with the new interface [1].

[1] Though if they override methods that have been modified in SAXHandler to 
*use* the
new methods, then things might get hairy...


My major concern is that if we are going to warn people not to implement the 
Action interface,
then what really is the point of providing it in the first place? As I said 
above, I just cannot
think of any situation where a class would want to be an Action *and* extend 
some other class.

Nevertheless, there are definite benefits to following a standard convention...

> 
> * yes, the name Action is quite overused. Not that I can think of a better 
> alternative... ;-)

Yep :-(

Rule is at least different - but unfortunately can be misleading. A
tough choice..

Regards,

Simon



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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Tue, 2005-02-01 at 16:20 +0100, Emmanuel Bourg wrote:
> Reid Pinchback wrote:
> 
> > I strongly agree.  Cyclic package dependencies seem
> > unimportant when you only have a few classes, but as the
> > amount of code grows, you quickly find that testing and
> > refactoring because much more difficult than it had to be.
> 
> Can you give an example of a difficult refactoring due to a cyclic 
> dependency between 2 packages ? I'm not sure to understand the practical 
> issue.

Well, I don't know about the refactoring issues. But I prefer avoiding
cyclic dependencies because:

* You can learn the classes in packages in order, without bouncing back
and forth between packages
* javac, javadoc, UML diagramming tools, etc. can process code in
directory order without having to bounce back and forth. This just has
to improve performance and reliability.
* you can trim down a distribution by progressively leaving out packages
* when porting code or revising code (including refactoring) you can do
  this in a progressive manner, starting with the package at the root of
  the dependency tree and working forward rather than having to migrate
  classes scattered across a selection of packages.
* having clean package dependencies encourages lower code coupling. 
  Quite often I find it prompts me to create clean interfaces to break
  inter-package dependencies, and I then find those interfaces are 
  sensible for many reasons.

Regards,

Simon



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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

Hi Oliver,

On Wed, 2005-02-02 at 15:22 +0100, Oliver Zeigermann wrote:
> On Wed, 02 Feb 2005 14:48:42 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > > - Wouldn't it be possible (and even desirable) to have a more general
> > > Pattern class instead of a String in Digester#addRule?
> > Can you explain more?
> 
> Well, RuleManager is an abstract class (discussion abstract class vs.
> interface applies here as well) with a default implemenation, but
> Pattern is a String. Wouldn't it be more flexible with little extra
> cost to have a Pattern interface with a default String Path
> implementation like the current one?

Well, I would prefer to avoid having users do:
  addRule(new Pattern("/foo/bar"), )
as this is just more readable:
  addRule("/foo/bar", ...)

However if we ever do find that there are some patterns that just can't
be represented nicely as a string, then we could simply add a new
method:
  addRule(Pattern p, ...) { }
and reimplement addRule to preserve compatibility:
  addRule(String s, ... ) { addRule(new Pattern(s), ...); }

So in short, I would prefer [1] to keep the current String pattern as
one of the options, for user convenience, but I don't see any major
issue with adding Patterns later if we need them. I guess it would break
custom subclasses of RuleManager, but that would be a very rare thing to
do.

And right now, DefaultRuleManager definitely needs its patterns to be
strings, so if we had a Pattern class as the pattern, we would be
forcing users to create an instance just so the DefaultRuleManager could
turn it back into a string.

>  
> > > - I like the bodySegment vs. body design :)
> > Cool. Now I just have to implement it :-)
> 
> Ooops, doesn't it work, yet? 

Minor detail. I just need to merge the code from the example I
referenced into the core. Why are there never enough hours in a day?

> 
> > 
> > The inspiration can be found in the digester 1.6
> > "src/examples/api/document-markup" example, where the code has to go to
> > great lengths to handle XHTML-style input.
> 
> I was also wondering, there may be occasions where it is desirable to
> have the full body *including tags*  passed in a call back. This would
> mostly apply in mixed context tags where text is mixed with style
> information that do not need processing like with XTHML.

You mean stringify the child elements too, like XSLT does if you ask for
the text of a mixed-content element?

I suppose we could do this, though I am not entirely sure how much use
this would be. Can you think of a use-case?

If you mean pass a DOM tree into the Action to represent the "full body"
content, I think not :-).


> > > - I like the no dependency and digester2 package approach
> > 
> > Ok. I really thought people wouldn't like "o.a.c.digester2". In fact,
> > I'm not sure I like it myself. The main reasons are:
> > (1) that I don't know any other projects that do this. Tomcat, struts,
> >commons-collections, etc, don't do this.
> 
> Tomcat does not need to as it is no library. commons-collections
> should better have done this - for more details have a look at the
> thread all this was discussed in recently.

Yes, I remember that thread. I'll re-read it.


> > As noted, there is still currently a dependency on BeanUtils; digester
> > uses too much from that package to copy the classes into digester. But
> > as noted I would like to experiment with accessing BeanUtils
> > functionality via a custom classloader so that if people have problems
> > with clashing lib versions there is a solution.
> 
> Could you elaborate this?

Suppose digester requires beanutils 1.7, but a user wants to call
digester from an app that is using beanutils 1.6 (or 1.8) or similar,
and the beanutils lib versions are incompatible. 

In this situation, the user is currently out of luck (or at least there
is no documented solution).

But using classloaders it is possible to access classes different from
the classes available to other parts of an app. For example, webapps in
tomcat have their own private libs that are not available to either
tomcat or sibling webapps. Using this sort of trick, we could arrange
for digester to access all the beanutils classes via a user-provided
classloader, which accesses a beanutils-1.7.jar that is not in the
classpath for the rest of the app.

I haven't really thought about this in detail; it's just an idea at the
moment. I'm vaguely envisaging a method
   Digester.setLibraryClassLoader(ClassLoader cl)
or
   Digester.setLibraryClasspath(String customClasspath)

It might end up better to load the whole of Digester in a custom
classloader, in which case the problem is pushed back up to th

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Wed, 2005-02-02 at 06:04 -0800, Reid Pinchback wrote:
> --- Oliver Zeigermann <[EMAIL PROTECTED]> wrote:
> > On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching <[EMAIL PROTECTED]> 
> > wrote:
> > > My major concern is that if we are going to warn people not to implement 
> > > the Action interface,
> > > then what really is the point of providing it in the first place? As I 
> > > said above, I just
> > cannot
> > > think of any situation where a class would want to be an Action *and* 
> > > extend some other class.
> >
> > I am +1 for using an interface and the default (why abstract?)
> > implementation like with Swing or SAX.
> 
> I don't get why we would ever warn people not to implement the interface

We (digester developers) want the ability to add methods to Action in
minor releases. But adding methods to an interface breaks all classes
that directly implement that interface.

So people should not extend an Action interface because their classes
could be broken by a minor-version update of Digester, eg 2.0 -> 2.1.

They wouldn't be forbidden from implementing Action, just warned about
the consequences.

By encouraging users to extend AbstractAction instead of implementing
Action, we have the chance to provide default implementations for new
functionality, and thereby give ourselves the chance to improve digester
in minor releases without breaking user code.

> Here is a concrete example of why you could want to implement the interface
> and extend another class, I've actually had situations with the existing
> Digester where I'd wished I could do that.  The one that I can recall now
> was an instrumentation issue.  Doing debugging and performance tuning of
> a suite of rules can be tedious because, currently, the only options are
> either to watch a spew of logging messages or single-step your way through
> all the callbacks in a debugger (PAIN).  If the major coupling points
> in the Digester had been abstracted by interfaces, it would have been
> easier to insert instrumentation proxies or EasyMock'd test implementations 
> of classes at key points.

I don't know much about EasyMock, and have only rarely used
java.lang.reflect.Proxy.

But if having an Interface rather than an abstract class makes it easier
to use these, then that's a very good point in favour of Colin Sharples'
recommendation to create Action (interface) + AbstractAction (class).
Normal code extends AbstractAction, but instrumentation code can proxy
the interface if it really needs to.

And as these uses of the interface are "transient", we don't have to
worry about "breaking" code when the interface is modified, right?



Does this satisfy your concerns?


Regards,

Simon


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

Re: [svn][ot] How to move a tag?

[Simon Kitching]

Hi Oliver,

I don't quite understand what you are trying to do. I hope the following
helps (though I'm not an SVN guru, so others might correct this).

Normally CVS "tags" are simply used to mark a set of files so that you
can retrieve that same set later. In this case, the equivalent in
subversion is just to use
  svn cp {from} {to}
eg
  svn cp https:///trunk  https://.../tags/beta1
to save the current state of the trunk as a directory "beta1". The copy
command makes a "light-weight copy", essentially a sort of hard link
with copy-on-write so updates don't affect the original source.

If the trunk versions move on, and you later want beta1 to include one
of the updated files, then update what "beta1" refers to by relinking
from the beta1 directory to the version you really want:
  * removing the file (link) you no longer need from the "tag" dir
 eg  svn rm https://../tags//foo.txt [1]
  * copying back in (ie link to) the version you want
 eg svn cp 
  -r 100 https:///trunk/.../foo.txt  [2]
  https:///tags/.../foo.txt   [3]

[1] or if you have a working copy of the tag dir, you can 
do svn rm and svn commit
[2] if you want the latest version, just omit the -r 100.
[3] or if you have a working copy of the tag, copy to your working
copy then svn commit it.

Performing the copy again (ie linking to the *updated* file [together
with its history] from the tag) is what Brett means by "copy with
history again". Using "svn merge" doesn't do the same thing, because it
is effectively generating a patch file then applying it to your version;
the differences get merged in, but not the history.

Alternatively, if the "updated" tag is meant to look mostly or
completely like the new trunk, then just use "svn update" to ensure your
trunk working copy looks like the stuff you want to tag, then delete the
old "beta1" directory, and recreate it. Copies are cheap!

There isn't any difference between a directory created with the intent
of just using it as a "tag" and a directory created with the intent of
using it as a branch. The convention of putting the scn copy into
subdirs "{project}/branches" and "{project}/tags" are traditionally used
to *indicate the intent* of the copy, but they are functionally
identical.

For some other traditional uses of CVS tags, it might be better to use
subversion "properties" (see svn set-prop).

I suggest you read the subversion manual, particularly the section on
branches. It is very well written..
   http://svnbook.red-bean.com/

Regards

Simon

PS: Bottom-posting would have made this thread much more readable!

On Thu, 2005-02-03 at 01:44 +0100, Oliver Zeigermann wrote: 
> Yes, that's what I was trying. However, merging the new stuff in
> generated a new trunk inside the tag (which seems to be just like a
> branch). Isn't there anything similiar to CVS moving a tag?
> 
> Thanks anyway :)
> 
> Oliver
> 
> 
> On Thu, 03 Feb 2005 06:32:26 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > You mean retag a file that has already been tagged?
> > 
> > You can probably copy with history again. If that doesn't work, it's
> > probably a matter of essentially merging the changes since the file was
> > "tagged".
> > 
> > Remember, svn doesn't really tag anything and there is nothing magic
> > about the trunk, branches and tags directory. They are all just copies
> > (with history).
> > 
> > - Brett
> > 
> > Oliver Zeigermann wrote:
> > 
> > >Folks,
> > >
> > >sorry, this is a bit OT, but I am struggeling how to move a tag in SVN.
> > >
> > >Any hints?
> > >
> > >Thanks in advance,



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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Thu, 2005-02-03 at 02:11 +0100, Oliver Zeigermann wrote:
> On Thu, 03 Feb 2005 11:39:01 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > > I was also wondering, there may be occasions where it is desirable to
> > > have the full body *including tags*  passed in a call back. This would
> > > mostly apply in mixed context tags where text is mixed with style
> > > information that do not need processing like with XTHML.
> > 
> > You mean stringify the child elements too, like XSLT does if you ask for
> > the text of a mixed-content element?
> 
> Yes.
>  
> > I suppose we could do this, though I am not entirely sure how much use
> > this would be. Can you think of a use-case?
> 
> Think of the transformation of our web pages. There is structure
> information wrapping pure XHTML. You would not want a callback for all
> formatting tags, would you? Maybe this is not a very common use of
> Digester, though...

Ok, I see. It would be reasonably simple to implement; we already
calculate the full text for each element (so we can pass it to the body
methods) in the SAXHandler class; we just need to keep appending these
instead of discarding them when the element ends.

One issue, I guess, is that by the end of the document we have a
StringBuffer that contains the entire text for the entire document -
which might take up a bit of memory. So maybe we need some mechanism for
an Action to tell the SAXHandler [from its begin() method, via a mixin
interface, or otherwise] that it wants a full text tree. The SAXHandler
can then start accumulating.

If you wished to contribute such a patch, I think I'd be in favour of
it.

> 
> > If you mean pass a DOM tree into the Action to represent the "full body"
> > content, I think not :-).
> 
> Certainly not. I think there is no place for the DOM in Digester.

Phew! :-)

> 
> > > > Or are you by chance referring to my suggestions for xml-rules?
> > >
> > > No, what are they?
> > 
> > I was puzzled about your reference to "reflection" in the previous
> > email, as accessing Rule (now Action) classes is never done via
> > reflection. However in the RELEASE-NOTES.txt I do discuss possible
> > updates to the classes in the xmlrules package to use reflection to make
> > Action classes accessable via the xmlrules mapping file rather than have
> > the xmlrules java code contain an explicit mapping class for each Action
> > as is currently done.
> 
> Is that so? I have no internal knowlede of beanutils, but I thought
> there is no other way of calling a parameterized method than by
> refelection methods. But I am happy to learn something here :)

Just some minor misunderstanding I think..

The digester framework invokes Rule (Action) classes directly. There is
no reflection involved in the invocation of Rule (Action) classes.

I am proposing that xmlrules actually uses reflection to generate a set
of Action objects when parsing its rule configuration input file. Of
course the parsing of the actual user input would then be done in the
normal manner (with the digester framework calling the Actions
directly).

The Rule (Action) classes interact with domain-specific (user) classes
via BeanUtils and reflection. I don't see any alternative, except for
the "pre-processor" type xml mapping tools, or runtime bytecode
generation, neither of which are really Digester's domain.

> > 
> > I remember the main issue being that Digester is built around the
> > concept of having patterns control what operations were executed for
> > each xml element, and having the invoked logic partitioned into many
> > small Rule classes.
> > 
> > You wished the user to write a big switch statement in Java to determine
> > what operations were executed, as you felt that this was more natural to
> > people used to writing SAX code by hand.
> > 
> > We did briefly discuss ways of layering the code so that these were two
> > possible options the user could choose between, but I couldn't see then
> > how this would be possible.
> 
> Thanks for reminding me of my reservations :) Now I remember!
> Especially when writing rahter simply import code I think it is much
> easier and obvious to have all the code at one position instead of
> having it distributed into many classes. However, this seems to be
> rather simple to accomplish. You just register a single action to be
> matched for all elements and then access the context to tell you the
> path of the current element. Maybe having a conveniece method to match
> paths to the current element directly.
> 
> Wouldn't this work?

Hmm.. If we had a class that implements RuleManager that always returns

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Wed, 2005-02-02 at 05:48 -0800, Reid Pinchback wrote:
> One section of the release notes says:
> 
> The Digester now *always* uses a namespace-aware xml parser.
> 
> I was wondering why this is.  There are a lot of XML parsers
> out there, and some of them have done things like trade
> namespace awareness for performance.  If somebody has a
> application where namespaces aren't an issue, why should
> they be limited to only using a namespace-aware parser?
> Not something that seems like an important issue if you are
> just using a Digester to process some kind of app config
> file, but is an issue if processing streams of XML data
> is fundamentally what the app is about.
> 

Supporting namespaces in an xml parser seems very simple to me. I think
it much more likely that only antique and unmaintained parsers fail to
support namespaces. And people who are determined to use antique and
unmaintained parsers can just stick with digester 1.x as far as I am
concerned. I'm not pushing for digester to remove non-namespace-aware
support - just digester2!

Removing code that handles non-namespace parsers from digester
simplifies the code and reduces the library size. It also pushes users
to write their code correctly; code that processes XML and doesn't
handle namespaces is fundamentally broken and we shouldn't be providing
tools that encourage people to write broken code.

However if you can give an example of a modern and maintained xml parser
that deliberately doesn't support namespaces in order to improve
performance or reduce footprint, I will gladly reconsider.

Or of course the consensus here favours supporting broken parsers :-)


Regards,

Simon




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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Wed, 2005-02-02 at 20:45 -0800, Reid Pinchback wrote:
> --- Simon Kitching <[EMAIL PROTECTED]> wrote:
> 
> > Supporting namespaces in an xml parser seems very simple to me. I think
> > it much more likely that only antique and unmaintained parsers fail to
> > support namespaces. And people who are determined to use antique and
> > unmaintained parsers can just stick with digester 1.x as far as I am
> > concerned. I'm not pushing for digester to remove non-namespace-aware
> > support - just digester2!
> 
> Wow, that is an unexpectedly harsh reaction.  My reason for asking 
> was simple, and I believe not unreasonable.   You were the one asking
> for feedback on your proposal. 

Sorry, Reid. I didn't mean it that way. I apologise for any offense.
I was just stating my personal opinion - that every app eventually drops
support for obsolete technologies, and I think it's time to drop support
for non-namespace-aware parsers. 

I was serious, too, about users of old technology sticking with digester
1.x. I'm aware that upgrading core libs can sometimes be a pain, but
digester1.x is still there and isn't going away (I'm one of the
maintainers for that code, and have every intention of continuing that
even when 2.0 is out). I just don't see the point of migrating the
"backwards compatibility" code from the 1.x series. 

Of course if someone can demonstrate that non-namespace-aware parsers
*are* still useful then I'll change my mind.


> Using the namespace-based API of an XML parser is known throughput 
> substantially, 
> covered in a host of Java xml mag articles, available from google searches, 
> and
> one or two of the Java performance tuning books still in distribution.  XML 
> performance tuning is a tough area, and people continually struggle with it.
> I don't recall the SAX-only stats, but I know that for DOM parsers you can 
> shoot for an increase XML processing bandwidth by an order of magnitude 
> through 
> a change in parser and not using NS.  Antiqueness of parsers isn't the issue.

Is there any chance you could provide a reference to such an article?

I still find it hard to believe that leaving out namespace support makes
a performance difference. The parser needs to keep a map of
   prefix->(stack of namespace)
and that's about it. Surely that's a fraction of a percent of the parser
performance, memory usage, and processing time. So why wouldn't a parser
do it?

Leaving out *validation* would improve performance and footprint
significantly, but validation and namespace support are unrelated.

I had a quick look for high-performance/small-footprint xml parsers:
 parser  NS-support maintained?
 Piccolo   y  y
 Aelfred   y  y
 ElectrixXML   y  n? (can't find a current website)
 MinML n  n (last release nov 2001)
 NanoXML   y  n (last release april 2002)
 JapiSoft  y  y (commercial)

I also googled for "xml parser performance namespace" but didn't get
anything relevant.

> I think it helps to keep in mind that NS was intended as a way of creating 
> name-resolution scopes that allow the merging of document structures from 
> different origins that otherwise could experience element and attribute
> name clashes.  When somebody has an application that doesn't require that 
> kind of merging, and they aren't using a namespace-dependent XML technology 
> like Soap or XMLSchma, then using using NS features of an NS parser can
> be a burden without corresponding benefit.  Under the hood, that parser has 
> to do a lot of work to continually manage the NS resolution of the node names.
> It has no way of knowing that the work is pointless - you've told it to
> assume that there is a point when you use the NS features.

True. Namespaces are not relevant in many contexts. But as noted above,
I do find it hard to believe that "parser has to do a lot of work to
manage NS resolution". If you can show me I'm wrong, I'll buy you a
beer ;-)

Regards,

Simon


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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

Hi Oliver,

I look forward to seeing your ideas on stringifying trees of elements.

> > 
> > The Rule (Action) classes interact with domain-specific (user) classes
> > via BeanUtils and reflection. I don't see any alternative, except for
> > the "pre-processor" type xml mapping tools, or runtime bytecode
> > generation, neither of which are really Digester's domain.
> 
> Well, there it is, my reflection. So we had a misunderstanding. The
> options you name are worse than refelection, I agree, but why using
> the BeanUtils in the first place? Isn't plain refelction sufficient?

Well, I don't believe pre-processing is "worse" than digester; it can be
a great solution in some situations. And for the rest, there's
Digester :-)

Digester uses BeanUtils to do type-conversion (via its ConvertUtils
component), converting the strings extracted from the xml to whatever
types the target methods take.

BeanUtils also treats DynaBean classes as if they were normal Java
classes, which is needed for at least one very important Digester user:
struts.

The reflection stuff we use from BeanUtils is only a few dozen lines so
I guess we could import that into Digester itself. However the
ConvertUtils stuff has a lot of code for typeconversion that I would be
reluctant to duplicate. Maybe it's worth having a look at the new
"morph" project as an alternative; it's more tightly focussed on
typeconversion than BeanUtils.

> > 
> > Hmm.. If we had a class that implements RuleManager that always returns
> > a custom Action no matter what the path, then all events would be
> > forwarded to the user-provided action, where the user can call
> >context.getMatchPath()
> > to access the current path, and determine from there what operations to
> > perform.
[snip]
> > 
> > Thoughts?
> 
> Looks good. However, we would need code that does the same as the
> default rule manager  in getMatchingActions to match relative paths as
> well. xmlio uses the same path syntax as digester2 anyway.
> 
> I will provide something for this as well.

Excellent!

> > I've not thought too much about obj->xml, and anyway Betwixt has that
> > reasonably well covered as far as I know.
> 
> The xmlio out part is much less than obj->xml, but rather a set of
> helpers on a low level. It also addresses byte encodings which has not
> been thought of in many XML printing solutions.

Hmm.. not sure what to do with this code, then. But I'm pretty sure
Digester is not the right home for it...

> 
> > If you mean having some debug Action that is triggered *for every
> > element seen* in addition to the ones whose patterns actually match,
> > then that can be done fairly easily by subclassing a Rules (in
> > digester1.x) or RuleManager (in digester2.x) class. I guess we could
> > build it in to the default class though...
> 
> This would fit into the xmlio matching above: have an action that is
> called unconditionally. This could be useful in many scenarios.
> Shouldn't this be part of the default rule manager?
>  

There are usecases for having a set of actions that is returned if no
pattern is matched. In particular, it is nice to be able to generate an
error, "unrecognised element", if you are very fussy about the input. I
would definitely like to add this to DefaultRuleManager. And this
feature would fit the xmlio scenario fine.

Having a set of actions that are returned *in addition to* any others is
possibly more controversial. There was someone looking for exactly that
on the digester user list a while ago, wanting to execute
SetNestedPropertiesRule for each element. I'm not so convinced this is a
good idea, though: seems awful easy to shoot yourself in the foot!

Apart from the "debugging" scenario you mention, I can't see a usecase
for having an action that is returned *in addition to the other matching
actions*. And I generally do debugging by enabling commons-logging
output rather than write custom debugging actions anyway. Can you think
of some usecases where this would be useful?

Note also that currently RuleManager can return prebuilt lists when
match is called; no List object needs instantiating. However if "always
present" actions have to be inserted into each list, then a new List
object is required to be created for each match call.

Cheers,

Simon


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

maven: where does javadoc footer come from?

[Simon Kitching]

Hi,

When I run "maven javadoc" for the digester project, each generated page
gets given the following footer text:

  Copyright © 2001-2005 The Apache Software Foundation. 
  All Rights Reserved.

Does anyone have any idea where this text is coming from? I've grepped
through the digester code, and through commons-build, and not found
anything.


Thanks,

Simon



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

[digester] initial code for digester2 checked in

[Simon Kitching]

Hi,

As there appear to be no objections to starting development of a
digester 2.0 release, and there were no significant objections to the
initial code I proposed, that code has been added to subversion at the
URL:
  http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/
branches/digester2

As the code is such a significant refactoring of the original, it seemed
easier to start from fresh rather than branch the old code. Therefore,
the new dir is not actually a physical branch (more of a "logical" one),
and so this location might not be entirely appropriate - but we can move
it later if anyone cares.

My apologies to those whose CVS commit history gets lost as a result of
committing this code afresh rather than branching; I intend to preserve
the authors/contributors info from the 1.x series, and give appropriate
credit in the docs somewhere to those who worked on 1.x to compensate.

Thanks very much to all those who commented on the original code; you'll
see that many of those changes have been incorporated.

And of course any and all features of this new code are up for debate. I
don't expect this development cycle to be a short one!

Now hack away :-)

Regards,

Simon


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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Thu, 2005-02-03 at 23:36 +0100, Oliver Zeigermann wrote:
> Hi Simon!
> 
> On Thu, 03 Feb 2005 23:57:30 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > I look forward to seeing your ideas on stringifying trees of elements.
> 
> Isn't it about time to give Digester2 a place in SVN, so I can either
> create patches against it or  directly commit to it. What about a
> branch in commons proper? Or at least the sandbox?

Done. 

Do you have commit rights to Digester? If not, I'd be happy to propose a
vote...

> > actions*. And I generally do debugging by enabling commons-logging
> > output rather than write custom debugging actions anyway. Can you think
> > of some usecases where this would be useful?
> 
> Hmmm, using SAX it always is a bit tricky to get a good idea how your
> XML document that is being parsed *really* looks like. commons-logging
> is no good in that case. If you have something that collects the whole
> document and regenerates it this can be a very valuable debug
> information. Consider the stuff you parse is not in your file system,
> but comes from a stream from a remote server it isn't all obvious what
> is looks like.

Good point.

>  
> > Note also that currently RuleManager can return prebuilt lists when
> > match is called; no List object needs instantiating. However if "always
> > present" actions have to be inserted into each list, then a new List
> > object is required to be created for each match call.
> 
> I understand what you say, but do not understand why a new list would
> have to be build with each match call. Why can't you statically addd
> the "always present" action into the list? Coul you explain?

Possible, I guess. Just a bit tricky...

Regards,

Simon



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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Fri, 2005-02-04 at 08:57 +0100, Oliver Zeigermann wrote:
> On Fri, 04 Feb 2005 15:52:16 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > Do you have commit rights to Digester? If not, I'd be happy to propose a
> > vote...
> 
> Well, not quite sure, how this is handled, but as I have commit access
> to commons transaction, I should have rights on Digester as well.

Ah yes .. I forgot that karma for commons covers all projects..

>  But
> I seem to remember that it is polite to have some sort of vote done by
> the current committers.

Yes. 

> 
> Who are the current committers? Is there anyone other than you?

Robert Donkin also keeps an eye on Digester, though he's been more
involved in Betwixt than Digester recently.

Craig McC certainly qualifies as a committer, but appears to be kept
busy by other projects.

Otherwise, it's just me.

Digester2 is just me so far, though. I'm happy for you to commit to the
digester2 directory, and don't think there is anyone else you need to
ask.

Cheers,

Simon



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

Re: [Digester 2] SAX version

[Simon Kitching]

On Fri, 2005-02-04 at 09:19 +0100, Oliver Zeigermann wrote:
> I have just check out Digester 2 and tried to compile it using Java
> 1.4.2_05 and to my big surprise it failed because of the SAX version
> that comes with Java 1.4.2_05. It has not empty ctor for SAXException
> (commented out in the source!) and resolveEntity in DefaultHandler no
> longer throws an IOException.
> 
> I am a bit helpless now.
> 
> Simon, which JDK are you using?

Well, I am using java 1.5. It certainly wasn't my intention to add
1.5-specific code, so if you spot a problem, please go ahead and fix it.


Cheers,

Simon


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

Re: [digester] initial code for Digester2.0

[Simon Kitching]

On Fri, 2005-02-04 at 10:45 -0700, Wendy Smoak wrote:
> (oops, wrong button)
> > Not sure if it's been discussed already, but I'm very much in favor of
> this
> > (from the Wiki):
> 
> '  It would be nice for SetProperties and SetNestedProperties rules to
> automatically map xml attributes and element names like "foo-bar" to bean
> properties of form "fooBar".  '
> 
> It's actually listed as a possible enhancement for 1.7, but wherever it ends
> up, it will be appreciated.  (Assuming it isn't there already and I missed
> it...)
> 

Thanks for the feedback Wendy. I added that "to-do" item, so I'm sure it
will get added eventually :-).

If you feel like having a go at this yourself, I would be very happy to
see a patch. Otherwise, it is lower on my priority list than getting the
basic digester2 structure sorted so may be quite a while away from being
implemented.

Regards,

Simon


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

Re: [digester2] performance of ns-aware parsing

[Simon Kitching]

On Thu, 2005-02-03 at 07:52 -0800, Reid Pinchback wrote: 
> --- Simon Kitching <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, 2005-02-02 at 20:45 -0800, Reid Pinchback wrote:
> > Of course if someone can demonstrate that non-namespace-aware parsers
> > *are* still useful then I'll change my mind.
> 
> Just to clarify, since I was being sloppy before (I gotta
> stop typing in shorthand) there is an important distinction:
> 
> a) having NS-aware parser, always using NS-aware API methods
> b) having NS-aware parser, selectively using NS-aware API methods
> c) having non-NS-aware parser (and obviously never using NS-aware API methods)
> d) having NS-aware parser where the developer fixes a grammar that
>ignores any NS distinctions
> 


> Even for Sax the performance difference between (a) and (b) is roughly 
> a factor of 2 across all parsers when processing small (typical 
> message-sized) 
> docs that don't use NS. 

I would *really* love to see some actual measurements on this if you can
find some. You seem to be quoting from some study you have done or read
- it would be great to have this. [See comments on Piccolo below]


>  Mucking with (d) is supposed to result in significant
> wins when you tune the grammar handling to your app, but I haven't tried it 
> myself and I've never seen timing differences quoted.  
> 

I don't quite understand what (d) means, but is it actually relevant?
Again, we are talking about *namespaces* not validation.

The w3c namespaces spec clearly makes a distinction between namespaces
and whether or not the namespace URI "means" anything:

http://www.w3c.org/TR/xml-names11/";>
Note also that the Namespaces specification says nothing about what
might (or might not) happen if one were to attempt to dereference a
URI/IRI used to identify a namespace.


What I'm trying to achieve is to avoid having actions or patterns deal
with element-names containing prefixes, eg stating that an element's
name is "foo:item". This is just broken; the item's name is really the
tuple (some-namespace, item).

Grammars/schemas can optionally be bound to namespaces, but namespaces
themselves are a lower layer that can be used without any of these
things. I'm talking here about requiring the parser to convert
 into (namespace, item) but do not intend to imply that any
kind of schema should be loaded for the specified namespace. 

The XMLReader.setNamespaceAware(true) method does exactly this; enables
mapping of prefixes -> namespaces, but does not enable processing of
either DTDs or schemas.


> I'm not trying to advocate any approach except to notice that, since your 
> README mentioned requiring a namespace-aware parser, it sounded like 
> there was a potential for options (b), (c), and (d) to become unintentionally
> closed to developers in Digester2 when they weren't in Digester1. 

Well, I did intend to close options (b) and (c) as I didn't believe
there was any reason at all to support them. Some real measurements
showing the kind of performance you quote would definitely change my
mind.

>  I agree
> that old parsers providing (c) aren't particularly interesting, but
> if you spend any time tracing through the guts of the parsing, particularly
> when you see how DTDs are loaded for entity resolution, you begin to see 
> (d) as having potential.  Throwing (b) away may result in less code in
> Digester2, but it may be worth doing some timing tests to see if that 
> code reduction is consequence-free.

What does loading DTDs have to do with namespaces?


> > I still find it hard to believe that leaving out namespace support makes
> > a performance difference. The parser needs to keep a map of
> >prefix->(stack of namespace)
> > and that's about it. 
> 
> Actually the XML spec distinguishes between the default namespace
> and all other namespaces, so parsers can reasonably make the same
> distinction and try to avoid a bunch of per-entity operations and 
> temporary object creations in the case where there is no namespace.

Sorry, what per-entity operations, and what temporary object creations?

> Look at the piccolo stats published on Sourceforge.  Compare Soap, 
> Soap+NS, and random XML-no NS timings and it suggests that NS 
> ain't free.
> 
> Useful links:
> 
>   Jade (now part of Javolution) http://javolution.org/api/index.html,
>   look at the javolution.xml package (trades String for CharSequence
>   to increase performance, but keeps NS)

Hmm.. I've added a reference to javolution to the wiki. 

However I couldn't find any info on the performance of namespaceAware vs
nonNamespaceAware...

> 
>   Picollo you probably already have the link for, but for anybody
>   else interested: ht

Re: [digester2] performance of ns-aware parsing

[Simon Kitching]

On Sat, 2005-02-05 at 21:02 -0800, Reid Pinchback wrote:
> --- Simon Kitching <[EMAIL PROTECTED]> wrote:
> > >  Mucking with (d) is supposed to result in significant
> > > wins when you tune the grammar handling to your app, but I haven't tried 
> > > it 
> > > myself and I've never seen timing differences quoted.  
> > > 
> > 
> > I don't quite understand what (d) means, but is it actually relevant?
> > Again, we are talking about *namespaces* not validation.
> 
> Yes... and every entity (Element and Attribute) is jammed through a
> resolution process first.  Remember XML attributes with default values?
> Guess where those values are identified and handed to the parser - during
> the resolution process.  Namespaces just add more data to shuffle
> around during the resolution process.

Well, in a document that doesn't use namespaces, the penalty is zero.

In a document that uses namespaces, there are a few xmlns:... attributes
floating around. But these have to be handled by the DTD processor
regardless of whether namespace processing is enabled or not, yes?

I don't see where namespaces adds any extra data for a DTD processor to
deal with during the "infoset augmentation" stage.


> 
> > What I'm trying to achieve is to avoid having actions or patterns deal
> > with element-names containing prefixes, eg stating that an element's
> > name is "foo:item". This is just broken; the item's name is really the
> > tuple (some-namespace, item).
> > 
> > Grammars/schemas can optionally be bound to namespaces, but namespaces
> > themselves are a lower layer that can be used without any of these
> > things. I'm talking here about requiring the parser to convert
> >  into (namespace, item) but do not intend to imply that any
> > kind of schema should be loaded for the specified namespace. 
> 
> That sounds sensible.
> 
> > The XMLReader.setNamespaceAware(true) method does exactly this; enables
> > mapping of prefixes -> namespaces, but does not enable processing of
> > either DTDs or schemas.
> 
> I don't think it actually has any impact at all on DTD processing.
> DTDs, if declared, are always processed unless you install an entity 
> resolver that excises that activity out.

You are right; DTDs get processed in the same manner regardless of
whether the parser is namespace-aware or not. What I meant was
namespaceAware does not affect the parser's handling of DTDs or schemas
(though it is a prerequisite for schema validation).

> 
> > >  I agree
> > > that old parsers providing (c) aren't particularly interesting, but
> > > if you spend any time tracing through the guts of the parsing, 
> > > particularly
> > > when you see how DTDs are loaded for entity resolution, you begin to see 
> > > (d) as having potential.  Throwing (b) away may result in less code in
> > > Digester2, but it may be worth doing some timing tests to see if that 
> > > code reduction is consequence-free.
> > 
> > What does loading DTDs have to do with namespaces?
> 
> As you said, the XML spec doesn't require that the namespaces mean
> anything, and hence it is possible that a parser won't try to resolve
> and validate against multiple DTDs, but I haven't ever traced through
> the code in a situation where there were multiple namespaces to
> resolve against, so I don't know if there is relationship there or not.
> In general, if a parser thinks it needs a DTD in order to understand
> a document, it tends to grab it.  

I presume you're using "DTD" as a general term covering both traditional
DTDs (which are not namespace-aware) and w3c schemas?

An xml parser does need to read a DTD regardless of whether validation
is enabled or not, for the reasons you pointed out: default attributes,
entity definitions etc.

But w3c xml schemas deliberately don't have any functionality that
affects the infoset of the document. So if you're not validating you can
completely ignore any xml schema - and parsers do. To double-check, I
tested this today, and verified the entity resolver isn't called to
resolve xsi:schemaLocation references unless validation is enabled.

> I don't know if there are situations
> where it tries to interpret namespace declations as public ids for DTDs.
No, xml parsers never dereference namespace-uris to load either DTDs or
schemas. The only way to reference a schema from an xml document is via
  xsi:schemaLocation="namespace url"

I think some XML editing programs do try to load schemas based upon the
namespace URI (eg jEdit, XMLSpy) but this is quite different (and
probably against th

Re: [digester2] performance of ns-aware parsing

[Simon Kitching]

On Sun, 2005-02-06 at 13:02 -0800, Reid Pinchback wrote:
> --- Simon Kitching <[EMAIL PROTECTED]> wrote:
> > > I stopped using belief as a measurement of code a long time
> > > ago.  Usually only works when I wrote all the code.  :-)
> > > I'll cook up an experiment and see what I can come up with
> > > in the way of timing information.
> > 
> > That would be excellent. I look forward to seeing the results..
> 
> Actually, an experiment implies a question to be answered, and
> while this has been an interesting back-and-forth, not sure
> we really have a question to answer.  This whole thing began
> with me simply asking a question about something you'd
> put in your readme file on the upcoming work.  Practically
> I don't see you not expecting a namespace-aware parser, the
> question is really more one of the user of Digester2 deciding
> if they are using namespace features.  While we could do
> timing tests to help people understand what the impact may
> or may not be of using NS in the documents they parse, it
> obviously has nothing to do with whether or not you are
> going to expect a parser to handle NS if the docs contain NS.
> That will be the developer's problem, not yours, yes?

Hi Reid,


I don't quite understand the above.

You mean these are the questions?
* should people avoid creating xml documents that use namespaces
  if they care about the performance of later parsing the doc?
* Is there a significant performance benefit in parsing 
  non-namespaced xml with a non-namespace-aware parser?
* Is there a significant performance benefit in parsing
  namespace-using-xml with a non-namespace-aware parser
  (yecch!).

The first is an interesting question, and is partially related to the
third one in that it gives people an *option* (though not a good one
IMHO) to parse the document fast. But mostly I agree this is the
developer's problem, not digester's. Tf we can give a hint somewhere in
our docs about parser performance with/without ns, though, I'm sure
people would appreciate it.

For either of the second, the answer is relevant to digester; if the
answer to either is yes, then I would support allowing a
non-namespace-aware parser to be used with digester. By support, I mean
writing code that allows instantiation of ns-aware or non-ns-aware
parser, code that looks for localname/qname, support in the RuleManager
classes for matching such elements, and unit tests to test it all.

Currently, I'm not hugely motivated to test either of the last two
scenarios, as I *believe* the answer to both is no, but if someone else
does I'll look at the results with interest.

Is this what you meant?

Regards,

Simon


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

Javadoc formatting style

[Simon Kitching]

Hi All,

I have seen two basic approaches to applying formatting to javadoc text
in source files:

(a) XHTML-style
  /**
   *This is the first paragraph.
   *
   *And this is the second.
   */

(b) HTML-style
  /**
   * This is the first paragraph.
   * 
   * And this is the second.
   */

I would certainly like to pick one or the other for Digester2. What
conventions have other commons projects adopted? Are there any good
reasons to pick one over the other?

Thanks,

Simon



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

Re: Javadoc formatting style

[Simon Kitching]

On Sun, 2005-02-06 at 17:18 -0800, Craig McClanahan wrote:
> As should be evident from my own recent practice :-), I'm also +1 on
> the first (XHTML) approach.

Can I ask those supporters of the XHTML style why they prefer it?

Personally I think it:
* increases the text size of the source file
* is harder to write manually (and harder to write correctly)
* makes the docs in the source file harder to read
* might be easier for the javadoc app to parse, but that
  makes no difference to us users of javadoc; the javadoc
  tool support for HTML-style isn't going away.
and
* has no effect whatsoever on the generated html pages


Not that it's a *huge* deal, but HTML-style just seems a bit better all
around. Yet quite a few people obviously do prefer XHTML-style. Is it
just for the "purity"?


Regards,

Simon


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

Anyone here from Vienna?

[Simon Kitching]

Hi All,

I'm going to be in Vienna, Austria for a few weeks. I just wondered if
anyone here is from thereabouts, as it would be great to meet up with
some fellow jakarta types.

Cheers,

Simon


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

Re: Javadoc formatting style

[Simon Kitching]

On Sun, 2005-02-06 at 18:59 -0800, Craig McClanahan wrote:
> On Sun, 6 Feb 2005 21:45:08 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > My reason is quite a lot simpler than Craig's.
> > 
> > I think of  as a container tag and not a separator tag, so I never
> > even think of the other way of doing it.
> > 
> > I guess we could do:
> > 
> > /**
> >  * first
> >  * 
> >  * second
> >  */
> > 
> > and still be XML compliant (assuming an automatic root of some kind),
> > but it would seem just as wrong to me.
> 
> It would be valid only if the element that the Javadoc doclet happens
> to place around your Javadoc comments accepts mixed content, *AND* if
> the nested content is itself well formed.  Java developers who count
> on that are, IMHO, making a mistake.

I was under the impression that "doclet" plugins to javadoc are always
fed properly structured data, in the same way that the Necko
html-parsing library presents its input data to its users as if it were
well-formed xml, and therefore don't need to worry about whether the
original javadoc text was HTML or XHTML style.

Is this not the case? If doclets are exposed to the raw javadoc text
then I would definitely agree XHTML is the way to go...

> Of course, I feel the same way about developers creating static HTML
> pages that create non-well-formed markup :-).

For HTML I agree; XHTML is the way to go. But isn't javadoc is a bit
different? In particular, it is read much more frequently in its raw
form, and always written by hand. And it is also expected to be accessed
via the javadoc "doclet" api rather than read directly(?).

Regards,

Simon


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

[lang] 2.1

[Simon Kitching]

Hi,

Firstly, in RELEASE-NOTES.txt:
  "DEPRECTAIONS:" should be "DEPRECATIONS:"

There was some discussion a while ago about having a "variable
substitution" utility available to handle strings like 
  "Hello, ${name}"

I seem to remember some code I wrote for Digester was adopted into Lang
for this, but I now see no trace of it. Was there a problem with it? (Or
was it some other commons project - my memory is pretty bad :-)

If it has been deliberately left out, that's fine - I wasn't pushing for
it to be included. But if there was just some minor issue (like no unit
tests) I would be happy to try to resolve it.

Thanks,

Simon


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

RE: concurrency and starting a synchronized block

[Simon Kitching]

On Thu, 2005-02-10 at 14:20 +0100, Jörg Schaible wrote:
> Torsten Curdt wrote on Thursday, February 10, 2005 2:07 PM:
> 
> > Guys, forgive me if this too off topic...

I think this list is a perfectly good place to ask this sort of thing..

> > 
> > ...but I thought it is somehow related to
> > collections that's why I am bringing it up
> > here anyway. I bet someone of you will know
> > 
> > Consider this code...
> > 
> >   Object o = map.get(key);
> >   if (o == null) {
> > synchronized(map) {
> >   map.put(key,new Object());
> > }
> >   }
> > 
> > 99% of the time the "get"s on the map are going
> > to return an object. That's why I would like
> > to avoid synchronizing the "get" access.
> > Now since a "put" might corrupt the data it
> > has to be synchronized.
> 
> then get() twice:
> 
> Object o = map.get(key);
> if (o == null) {
>   synchronized(map) {
> o = map.get(key);
> if (o == null) {
>   map.put(key,new Object());
> }
>   }
> }
> 
> since 99% of the time it will not enter the block, the second lookup does not 
> matter ...
> 
> Regards,
> Jörg

Well, I personally would be very reluctant to adopt this kind of
solution. 

Firstly, I believe that if you never synchronise on the get, then there
is no guarantee the reading thread will ever see data put into the map
by other threads. Having a synchronize around the get forces the cpu to
synchronise its cache or some-such. 

And secondly, I believe there are many other traps out there for code
that tries to play tricks with synchronization.

Synchronisation is a fiendishly difficult subject, involving CPU cache
coherence mechanisms, etc., and there are many traps to fall into. Many
of these are described in the articles about why "double checked
locking" is broken.

I think someone mentioned just a week or two ago on this list that Doug
Lea's concurrency library is available under a BSD-ish license. If
that's the case, I would look there for a fast hashmap implementation
first...

Cheers,

Simon


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

Re: [digester2] Additions

[Simon Kitching]

Hi Oliver,

On Thu, 2005-02-10 at 19:08 +0100, Oliver Zeigermann wrote:
> Folks,
> 
> as I noticed Simon has done so much work on Digester2, I just wanted
> to be sure that my scheduled additions still are appropriate and
> aligned to the overall design. Here they are:
> 
> (1) XMLIORuleManager: A rule manager that takes an action and
> unconditionally calls it on any event. It's useful to imitate xmlio
> style processing, but not limited to this. One application might be
> logging. As it is more general any proposal for a better name?
> 
> Quoting code sample from Simon:
> 
> > // xmlio-style digester
> > Action myHandler = new AbstractAction() {
> >   public void begin(
> >Context context,
> >String namespace, String name,
> >Attributes attrs) {
> >
> > String path = context.getMatchPath();
> > if (path.equals("..")) {
> > 
> > } else {
> > 
> > }
> >   }
> >
> >   public void body(...) {
> >   }
> > }
> >
> > RuleManager xmlioRuleManager = new XMLIORuleManager(myHandler);
> > Digester d  = new Digester();
> > d.setRuleManager(xmlioRuleManager);
> >
> 
> As an option it might be possible to register an action with any rule
> manager that gets called unconditionally - epsecially for logging and
> debugging this can be really helpful. However,  I wasn't quite sure if
> Simon was happy with that.
> 

Adding functionality to DefaultRuleManager that returns a set of default
actions *if no other action matches the current path* is not a problem.
I'm all for it. And this would meet your requirements, yes? So I'm happy
for you to go with this if you agree. And as a bonus, implementation
should be trivial: a dozen lines or so. I'm not sure whether this API
should then be exposed via the RuleManager interface (ie required for
all RuleManagers) or just left on DefaultRuleManager.

Adding functionality that returns a set of actions *in addition to* the
actions that match the current path is trickier. In what order are they
returned? And can we avoid instantiating a new List object each time
getMatchingActions is called? I'm not saying I'm opposed to it, I'm just
not sure right now.

> (2) Next to the body and bodySegment call back methods there might be
> one that gives you the complete body of an element as a string
> composed of all character and markup data. This might be useful when
> you want to verbosely take over formatted mixed content like in XHTML.
> 
> For performance reasons there should be some mechanism that tells
> digester when such content is needed on an element basis. Maybe
> something returned by the begin method or - maybe cleaner - something
> returned by an additional call back directly called after begin like
> boolean requiresComposedBody(String namespace, String name) or
> anything similar. This method could alternatively be part of an
> additional or extended interface.

Yep. I'm in favour of this. I would prefer an eye to be kept on
performance; the "requiresComposedBody" solution doesn't tempt me
greatly as that is a call that must be made on each Action each time it
matches, and 99.999% of those calls will return false. I could live with
it if there is no better alternative. However if an action's begin
method could enable the body text collection and the end method disable
it then wouldn't that have the same effect without additional work when
the feature isn't being used? I agree it's a little less intuitive for
Action writers though...and I haven't thought it through fully.


Note that I am tentatively planning to do some significant rework of the
DefaultRuleManager class. But that certainly won't be for some weeks so
hack away! I guess you'll also be wanting to work on the Path class, so
the custom Action class can more easily test the current path? I'll make
sure I check on this list before altering this class (though I've got no
plans to do so).

Cheers,

Simon


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

Re: concurrency and starting a synchronized block

[Simon Kitching]

On Thu, 2005-02-10 at 21:59 -0500, WHIRLYCOTT wrote:
> There's also the original version here:
> 
> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
> 
> What does the backport offer that the original util.concurrent lib 
> doesn't offer?

The JSR process made some minor alterations to the API provided by the
original lib, left out a few minor classes, etc.

By using the backport, updating to the "real" java.util.concurrent is
just a matter of changing the import statements in your code. Coding to
Doug's original API means your code isn't quite compatible with the
java.util.concurrent implementation provided by java 1.5.

The site you reference also implies that performance was improved in
some places in the java.util versions.


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

[digester2] should useContextClassLoader be true by default?

[Simon Kitching]

Hi y'all,

The discussion associated with commons-configuration bugzilla entry
http://issues.apache.org/bugzilla/show_bug.cgi?id=33475
has made me wonder why useContextClassLoader is false by default.

Can anyone see a reason why it should not be *true* by default in
digester2? (I think it's too big a jump to change the default behaviour
of digester 1.x...).

In other words, in what circumstances would a thread have a
context-class-loader set, but not want to use it to load user objects?
If they are rare, then true would seem a better default.


I would appreciate comments from people who are familiar with frameworks
that manipulate classloaders, esp. Tomcat (and that definitely includes
you, Craig!).

Thanks,

Simon


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

[digester2] general development strategy

[Simon Kitching]

Hi to all Digester types,

You may have seen a fair few commits to digester2 recently that change
fundamental stuff. I just want to point out that it is not my intention
to charge ahead with this without anyone's input; it's just that I don't
see anyone else who really cares to debate these changes with me at the
moment, so it's easier to commit them and see if people shout.

If someone wants to query or debate a change, I'm always happy to have
that discussion and potentially back out or change stuff that's been
committed. And of course when things stabilise more, I'll transition to
a "propose/commit" strategy rather than "commit/commit-more/..." :-)

The changes still generally follow the TO-DO list that's been here for
many months:
  http://wiki.apache.org/jakarta-commons/Digester/TODO

Regarding the current plans: I still have some work to do cleaning up
CallMethodRule and its CallParam associates. But that should then be the
bulk of the radical changes; the rest is just filling in the bits that
haven't yet been carried over from digester1. In other words, in a week
or so would be a good time for people to have a look at what's there if
they care, as things will be reasonably stable from then on.


Cheers,

Simon


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

Re: Need karma for commons proper...

[Simon Kitching]

On Fri, 2005-02-11 at 11:47 -0800, Kevin A. Burton wrote:
> I'm trying to import feedparser from the sandbox and into commons proper 
> and I get:
> 
>  > svn move 
> https://svn.apache.org/repos/asf/jakarta/commons/sandbox/feedparser 
> https://svn.apache.org/repos/asf/jakarta/commons/proper/feedparser
> Authentication realm:  ASF Committers
> Password for 'burton':
> Authentication realm:  ASF Committers
> Username: burton
> Password for 'burton':
> Authentication realm:  ASF Committers
> Username: burton
> Password for 'burton':
> svn: CHECKOUT of '/repos/asf/!svn/ver/153448/jakarta/commons/proper': 
> authorization failed (https://svn.apache.org)
> svn: Your commit message was left in a temporary file:
> svn:'svn-commit.2.tmp'
> 
> I assume this is because I need karma to commons proper?

It's probably because you haven't run svnpasswd. See the first paragraph
of the "Committer Subversion Access" section:
  http://www.apache.org/dev/version-control.html

Regards,

Simon


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

Re: [digester2] Additions

[Simon Kitching]

On Sat, 2005-02-12 at 08:28 +0100, Oliver Zeigermann wrote:
> Hi Simon,
> 
> I have now committed the first proposal for the XMLIO like rule
> manager called SupplementaryRuleManager. I also added a very basic
> test for it. I had to make a minor visibility change in
> DefaultRuleManager that it extends. Path now has match methods.
> 
> All this isn't perfect, especially Javadoc is missing and tests need
> to be extended, but I wanted to make this public for discussion as
> soon as possible.
> 
> So, comments?


One design goal was to avoid using protected members. The problem here
is that using protected for a *member variable* locks us into an
implementation forever (a protected member is part of the "external" api
that users can access). I think it preferable to add a public or
protected method that provides access to the member rather than exposing
the member directly. The method can later get the data in some manner
other than reading from a member if we change the implementation. Note
that having a method that returns a Map isn't a *whole* lot better. I
think what we need is a "copy-helper" type method rather than exposing
the namespace member just so a subclass can copy it. I can't think what
the best solution is at the moment, but I feel there's an elegant (and
probably fairly well known) solution nearby. How does clone() solve this
issue?

Note that I have (I think) been rigorous about avoiding protected
members in the o.a.c.digester2 package, but not so rigorous in the
action subpackage. I think it probably is a good idea to apply this to
the action package too, though.

=== 

I would suggest that the match method be placed somewhere other than on
the Path class. Digester could well provide multiple different matching
implementations in future. I think a static method on some XMLIOUtils
class might be appropriate. The user's hand-written Action can then
choose whether to use that matching algorithm or some other. All that
Path currently does is return a String representing the "canonical form"
of the Path, and that seems clean & focussed to me.

=== 

This bit in SupplementaryRuleManager will cause problems I think:
public List getMatchingActions(String path) {
List actionList = super.getMatchingActions(path);
...
if (supplementaryAction != null) {
actionList.add(supplementaryAction);
}
The list the RuleManager returns should not be modified; it is actually
an internal data structure. This does point out that DefaultRuleManager
should be a little more defensive, perhaps returning 
  Collections.unmodifiableList(actionList)
which would cause the above add call to fail and throw an exception.
That would, however, cause an object to be created on each
getMatchingActions call, which I would prefer to avoid if possible.
How about this instead?
public List getMatchingActions(String path) {
List actionList = super.getMatchingActions(path);
...
if (supplementaryAction != null) {
newActionList = new ArrayList(actionList);
newActionList.add(supplementaryAction)
}

I suppose this could be done instead:
if (supplementaryAction != null) { 
if (actionList.contains(supplementaryAction) {
  // nothing to do, we must have added the
  // supplementary action to this list earlier
} else {
  // permanently modify DefaultRuleManager's 
  // internal data structure; yecch!
  actionList.add(action)
}
}
but as the comments indicate, I think that having one class manipulate
another's internal data is not in terribly good taste, nor easy to
maintain.

=== 

As I mentioned earlier, I'm happy to put the "fallbackAction"
functionality into DefaultRuleManager. 

=== 

Why is there only facility for one fallback action, and one
supplementary action? Wouldn't having a List of actions for each be no
more difficult and potentially more useful?

=== 

On a minor SVN note, the SVN property "svn:keywords" needs to be set on
a file in order to enable expansion of $Id$ into the appropriate text.
This can be done manually via:
  svn propset svn:keywords "Id" filename
It takes a commit to update the repository. I suggest this would be nice
to do next time you update the SupplementaryRuleManager class, otherwise
that text in the first line of the file will never change. Adding the
following to your ~/.subversion/config file will ensure that each .java
file that you add to subversion automatically gets $Id$ expansion
enabled:
  [auto-props]
  *.java = svn:keywords=Id



> And, by the, now that I have done some work and I came across some new
> questions. Maybe they are just dumb, but what do you think about this?
> 
> (1) Why aren't relative paths to actions also cached?

The current DefaultRuleManager implementation is straight from the old
RulesBase class, except that absolute paths are expected to start with
"/".

I hav

[digester] BeanPropertySetterRule: why wait until end to set property?

[Simon Kitching]

Hi all [esp. Robert Donkin],

The BeanPropertySetterRule takes the body content of an xml element and
calls a property setter method on the object on the top of the stack, eg
   myname
causes setName("myname") to be called.

My question is: why does BeanPropertySetterRule wait until the end()
method to actually invoke the setter method, when it could invoke the
setter method from the rule's body(..) method?

I'm considering having digester2 make the call direct from body; it's
easier to implement and I can't see any potential problems. After all,
SetPropertiesRule calls the setter methods from begin()...


The original author of this Rule appears to be Robert Donkin. Robert,
can you remember code from Nov 2001? :-)

Thanks,

Simon



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

Re: concurrency and starting a synchronized block

[Simon Kitching]

On Fri, 2005-02-11 at 16:53 -0800, David Graham wrote:
> --- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> 
> > From: "Torsten Curdt" <[EMAIL PROTECTED]>
> > >Regarding the FastHashMap: since the
> > use is more or less discouraged ...why
> > not deprecate it?
> > 
> > Because it works on everything that its been tried on. 
> 
> It's more like no one has ever noticed it breaking.  I'm not certain
> whether we know it actually works.

In fact, it's more like "no-one has ever been sure enough that
FashHashMap has broken their app to file a bug report". If an
application misbehaves once in a while, it's almost impossible to
determine what the cause was, and therefore no bug report would ever get
filed. 

I think FastHashMap should definitely be deprecated if there is a
possibility of intermittent failure.

Regards,

Simon


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

Re: [Subversion] Revision Keyword

[Simon Kitching]

Just to expand on Brett's reply:

Keywords in subversion files are not expanded unless that file has the
keyword-name in the svn:keywords property associated with that file. The
svn:keywords property can be set using:
  svn propset svn:keywords "Id Rev " filename
  svn commit filename
I presume you can update multiple files at the same time; I just haven't
tried 

You can automatically ensure the svn:keywords property gets set on files
you add to subversion by editing your ~/.subversion/config file:
[miscellany]
enable-auto-props = yes
[auto-props]
*.java = svn:keywords=Id Rev

And you can get subversion commands to ignore certain files by setting
the global-ignores entry in ~/.subversion/config. I have the following:
[miscellany]
global-ignores = *.o *.lo *.la .*~ *~ .#* *.class .*.marks


Subversion keywords are described in the subversion documentation:
  http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.4

Regards,

Simon



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

Re: [digester2] Additions

[Simon Kitching]

Hi Oliver,

On Mon, 2005-02-14 at 08:16 +0100, Oliver Zeigermann wrote:
> [update]
> 
> - now all member variables of DefaultRuleManager are private -
> introduced copy ctor for copying members from subclasses

thanks - that looks good to me.

> - DefaultRuleManager now returns an unmodifiable list upon getMatchingActions

I'm not so sure about this one. 

This change means a new object is created each time getMatchingActions
is called, and that is once for every xml element in the input document.
And in addition, each method call is "relayed" by the UnmodifiableList
wrapper to the underlying one, resulting in a performance hit too. Is
this significant in the context of parsing an xml document? I don't
know; maybe it's not measurable. 

However the benefits of this change are really limited only to
preventing bad code in SAXHandler or RuleManager classes. Cases where
users write their own versions of those will be extremely rare. And
mistakes in the core digester classes are, I think, likely to be picked
up by our unit tests.

So my current feeling is that while the above change **is theoretically
correct**, I would leave it out and return the actual list, just
documenting that it should be treated as unmodifiable.

Comments?

> - created a new FallbackRuleManager class that only takes care about
> fallback actions

[see my comments at end first!]

Have you considered writing this class as a *decorator* rather than a
subclass of DefaultRuleManager? If it was a decorator, it could then be
applied to any rulemanager class, not just the default. It would be used
as follows:
  RuleManager realrm = new DefaultRuleManager(); // or any other type
  RuleManager rm = new FallbackRuleManagerDecorator(realrm);
  Digester digester = new Digester(rm);

The disadvantage would be that it would be necessary to implement
each of the RuleManager methods in order to forward them to the
decorated instance, together with the performance hit that would entail.
[ah, if only this were Ruby]

> - SupplementaryRuleManager now takes account of the explicitely
> unmodifiable list returned by DefaultRuleManager and does a wild
> mixture of caching and concatenating the list returned from
> DefaultRuleManager and its own list of supplementary actions

[see my comments at end first!]

The ReadOnlyConcatList is cute. I don't think it would save any time or
effort over
  List list = new ArrayList(l1.size() + l2.size());
  list.appendAll(l1);
  list.appendAll(l2);
but I guess the unmodifiable feature is thrown in for free.

I've been thinking about the caching and see a mild problem. If wildcard
pattern "a" (equivalent to "*/a" in digester1), and  elements are
scattered around in various places in the input document, then the cache
is going to grow fairly large.

So basically, whether caching improve things or not depends upon whether
the input xml is simple and repetitive (caching wins) or reasonably
unstructured (caching loses). And given we can't tell which is more
likely over the set of digester users (at least I don't have a clue) I
would probably prefer the simplest solution - not to cache.

I'm also thinking about the possibility that we may move to a
RuleManager style that matches based on much richer state than just the
current path. FOr example, if we want to support patterns like this:
 "/foo/[EMAIL PROTECTED]'me']/baz[pos()==last()]"[1]
then getMatchingActions will definitely not be taking a String path any
more, but instead an array of w3c.dom.Element objects or similar so it
has sufficient info to decide whether the pattern matches or not. That
won't affect many places in the code, but would make this caching
impossible to implement so we'd have to take it out then anyway.

[1] sorry my xpath is a bit rusty - this is probably not valid

> - Both FallbackRuleManager and SupplementaryRuleManager now can have
> several callback actions
> - Still docs and tests need improvement - will do so once the code
> seems somewhat stable
> 
> Comments?

You're probably going to hit me for this :-)

After some thought, I think my preferred option would be to include
"fallback" and "supplementary" features as standard, ie define them in
the RuleManager interface, provide an implementation in the
DefaultRuleManager class, and to remove the FallbackRuleManager and
SupplementaryRuleManager classes completely.

I've always said I'm happy for fallback features to be in
DefaultRuleManager, and after thought I believe it ought to be defined
as part of the main RuleManager interface. And as you're so keen for
supplementary actions, I'm ok with adding them too as long as there is
no performance hit for people who don't use them. Note that this would
definitely be the easiest solution from the user point of view, with no
special classes required in order to use "supplementary" actions.

And I would go for the simplest implementation of "supplementary"
actions, by simply creating a new list each time getMatchingActions is
called when one or mor

Re: [digester2] Additions

[Simon Kitching]

On Mon, 2005-02-14 at 17:24 +0100, Oliver Zeigermann wrote:
> On Tue, 15 Feb 2005 01:08:53 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > > - DefaultRuleManager now returns an unmodifiable list upon 
> > > getMatchingActions
> > 
> > I'm not so sure about this one.
> > 
> > This change means a new object is created each time getMatchingActions
> > is called, and that is once for every xml element in the input document.
> > And in addition, each method call is "relayed" by the UnmodifiableList
> > wrapper to the underlying one, resulting in a performance hit too. Is
> > this significant in the context of parsing an xml document? I don't
> > know; maybe it's not measurable.
> > 
> > However the benefits of this change are really limited only to
> > preventing bad code in SAXHandler or RuleManager classes. Cases where
> > users write their own versions of those will be extremely rare. And
> > mistakes in the core digester classes are, I think, likely to be picked
> > up by our unit tests.
> > 
> > So my current feeling is that while the above change **is theoretically
> > correct**, I would leave it out and return the actual list, just
> > documenting that it should be treated as unmodifiable.
> > 
> 
> Well, think of the situation where people inherit and do things like I
> have done on my first try. So, I would be all for keeping it in, but
> would not protest if you removed it.

I said above: "Cases where users write their own versions of those will
be extremely rare". I really believe that the number of people writing
their own custom RuleManager class will be about 3, worldwide, over the
next decade. But the number of people who get impacted by the
(admittedly small) performance hit for the proposed change is 100% of
users.

I guess we have a tie here: +1 from you, and -1 from me. The best thing
would be if we got a third opinion from either Craig or Robert.

Otherwise, we could just have a remote game of bzflag
(http://bzflag.org/screenshots/bzfi0026.jpg) or something, with winner
takes all :-)

[snip]

> > 
> > The ReadOnlyConcatList is cute. I don't think it would save any time or
> > effort over
> >   List list = new ArrayList(l1.size() + l2.size());
> >   list.appendAll(l1);
> >   list.appendAll(l2);
> > but I guess the unmodifiable feature is thrown in for free.
> 
> ReadOnlyConcatList certainly would be faster and have a smaller memory
> footprint.

Can you describe why ReadOnlyConcatList is faster and smaller?

The array list is (in c terms) just an array of pointers to Actions.

To create a new one, I am sure the ArrayList constructor does:
 * malloc a "manager" object with a few ints (size, capacity) 
   and a reference to the data block.
 * malloc the data block, which is capacity*sizeof(reference)
 * for each entry in the source list, copy reference to new list [1] [2]
Once the new ArrayList has been created, access is very fast.
[1] The list is likely to be 1, 2, or 3 elements. Having more than 3
Actions match a particular input xml element would be very unusual..
[2] There is even the possibility that ArrayList has been optimised to
do a "memcpy" if its source is an ArrayList.

With the ReadOnlyConcatList, the work done is:
 * malloc a block of data for the ReadOnlyConcatList, which contains one
int and the two references to ArrayList objects.
 * copy 2 references and call size once
And accesses are fractionally slower, because get invokes the
ReadOnlyConcatList, which performs an if-statement then invokes the get
method on the appropriate underlying list.


So on the positive side I think that ReadOnlyConcatList is marginally
smaller (it doesn't need the data block, which is typically 4-12 bytes),
and slightly more efficient to create (one less malloc, a few less
copies of references)

On the negative, the get method is slightly slower to use. It also adds
a dozen lines to the source and an extra .class file to the jar.

All in all, we are debating microseconds and handfuls of bytes here.
Both seem *acceptable* solutions to me, though I do prefer simple in
this case. And like the Unmodifiable discussion, the easiest resolution
would be if some other Digester developer (eg Robert or Craig) would
give their call, then we could get on with it.


>  
> > I'm also thinking about the possibility that we may move to a
> > RuleManager style that matches based on much richer state than just the
> > current path. FOr example, if we want to support patterns like this:
> >  "/foo/[EMAIL PROTECTED]'me']/baz[pos()==last()]"[1]
> > then getMatchingActions will definitely not be taking a String path any
> > more, but instead an array of w3c.dom.Element objects o

Re: [digester2] Additions

[Simon Kitching]

On Tue, 2005-02-15 at 01:35 +0100, Oliver Zeigermann wrote:
> After I have thought about it, I am +1 to do it the way you proposed
> initially: have it all in one class. That's not because I am
> frustrated or am no longer interested, but I think that's a good
> solution and causes the least controversy. Go ahead with it please.

Ok, done.

I've used the term "mandatoryAction" rather than "supplementaryAction"
as it's equivalent, shorter and hopefully more familiar to non-english
speakers.

I've moved the path-matching functionality from SupplementaryRuleManager
into a new class SimpleMatchUtils. And of course new class 
  SimpleMatchUtilsTestCase
now contains the basic xmlio demonstration adapted from the old
  SupplementaryRuleManagerTestCase.

Cheers,

Simon



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

Re: a commons-lang patch.

[Simon Kitching]

On Mon, 2005-02-14 at 16:44 -0700, Travis Stevens wrote:
> I just added a Bugzilla entry which includes a patch.  What do I need to 
> do to persuade someone to look at the bug and apply the patch?
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=33574
> 

Just creating the bugzilla entry sends an email to this list. If there
is no response, then a polite reminder every week or two is probably
acceptable.

However there's no way to "force" someone to look at the patch - nor is
there any need to, as you are of course free to use and redistribute
your patched version of lang.

Regards,

Simon


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

Re: [Subversion] Conversion Error - Revision Keyword

[Simon Kitching]

On Tue, 2005-02-22 at 20:21 +0100, Dirk Verbeeck wrote:

> I will also remove the .cvsignore files in the same update.
> Is there a good reason to set the svn:ignore property?
> I just use global-ignores svn config option and not a property for 
> each directory.

There was a thread just recently on this subject, and some people
clearly preferred to have data in svn:ignore rather than a local config
file. I'm not one of them, but I don't think there's a consensus for
removing all svn:ignore properties from the repository.

The thread subject was:
 [subversion] Revision Keyword

Cheers,

Simon


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

Re: [chain] steps towards 1.0.1 release?

[Simon Kitching]

On Tue, 2005-02-22 at 22:30 -0600, Joe Germuska wrote:
> So, as we move towards a Struts 1.3.0 release depending on 
> commons-chain, it seems that it would be nice to get a minor release 
> of commons-chain to go with it.  It would be nice for Struts to be 
> able to support the compound String representation of a 
> catalog/command combination, and I would like to be able to use the 
> (just-committed) change to LookupCommand which allows you to ignore a 
> "true" returned from a looked up command.
> 
> Is there anything else people would want to see in a minor release? 
> Any reason to choose any version number other than 1.0.1?

If there are new features, why not 1.1? Incrementing the third digit
usually indicates (to me anyway) that the release was made to fix an
important bug..


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

Re: [digester] Patches to xmlrules : NodeCreateRule addon + namespace prefix support

[Simon Kitching]

Hi Kristian,

On Mon, 2005-02-28 at 17:43 +0100, Kristian Mandrup wrote:
> Added PREFIX namespace support for NodeCreateRule: Can now parse a XML Schema 
> correctly â
> Tested (see Junit TestCase below). Works fine!

[snip]

> if ((localName == null) || (localName.length() == 0)) { 
> top = doc.createElement(qName);
> } else {
> top = doc.createElementNS(namespaceURI, localName);
> }
> String prefix = qName.split(":")[0];
> if (prefix != null) {   
> top.setPrefix(prefix);
> }

This seems to ensure that if an xml document containing namespaces is parsed 
with
a non-namespace-aware xml parser (ie localName is not defined), then a DOM-1 
(ie non-namespace-aware) element node is created ("createElement"), but then
the namespace-aware "setPrefix" method is called on it.

It seems to me that if the createElement (ie non-namespace-aware) method
is called to create the attribute, then calling setPrefix (ie a
namespace-aware method) is a bad idea. A prefix is being set, but there
is no namespace URI associated with the node...


> for (int i = 0; i < atts.getLength(); i++) {
> Attr attr = null;
> String attQname = atts.getQName(i);
> prefix = null;
> if (attQname.contains(":"))
> prefix = attQname.split(":")[0];
> if ((atts.getLocalName(i) == null) ||
> (atts.getLocalName(i).length() == 0)) {
> attr = doc.createAttribute(attQname);
> attr.setNodeValue(atts.getValue(i));
> if (prefix != null) {
> attr.setPrefix(prefix);
> }

This seems to have the same issue as described above; it seems to me
that if the createAttribute (ie non-namespace-aware) method is called to
create the attribute, then calling setPrefix (ie a namespace-aware
method) is a bad idea. A prefix is being set, but there is no namespace
URI associated with the node...


If I have misunderstood your patch, please let me know.

What is the problem that you are encountering with the current code that
this patch is intended to remedy?

Regards,

Simon


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

Re: [digester] Patches to xmlrules : NodeCreateRule addon + namespace prefix support

[Simon Kitching]

On Tue, 2005-03-01 at 14:15 +1300, Simon Kitching wrote:
> Hi Kristian,
> 
> On Mon, 2005-02-28 at 17:43 +0100, Kristian Mandrup wrote:
> > Added PREFIX namespace support for NodeCreateRule: Can now parse a XML 
> > Schema correctly â
> > Tested (see Junit TestCase below). Works fine!
> 
> [snip]
> 
> > if ((localName == null) || (localName.length() == 0)) { 
> > top = doc.createElement(qName);
> > } else {
> > top = doc.createElementNS(namespaceURI, localName);
> > }
> > String prefix = qName.split(":")[0];
> > if (prefix != null) {   
> > top.setPrefix(prefix);
> > }
> 
> This seems to ensure that if an xml document containing namespaces is parsed 
> with
> a non-namespace-aware xml parser (ie localName is not defined), then a DOM-1 
> (ie non-namespace-aware) element node is created ("createElement"), but then
> the namespace-aware "setPrefix" method is called on it.
> 
> It seems to me that if the createElement (ie non-namespace-aware) method
> is called to create the attribute, then calling setPrefix (ie a
> namespace-aware method) is a bad idea. A prefix is being set, but there
> is no namespace URI associated with the node...

Ok, I've had another look and think I understand at least part of your
patch.



First, you've added support for NodeCreateRule to the xmlrules module.
That's fine - though providing an explicit patch to do *just* this
(including a patch to the dtd and some unit tests) would be preferable
to including this as part of a larger and more complex patch. By "patch"
I mean a file generated by "svn diff ", which generates a diff file
between your local version (with the changes in it) and the current
version in the apache subversion repository. I would also recommend
leaving out the rather complex code that allows the xmlrules to specify
configuration for a custom DocumentBuilderFactory; I'm not convinced
that this is necessary or useful, and leaving it out of your initial
patch will make it more likely that the initial patch will be merged in
a timely manner.



You're then trying to parse a document containing namespaces, using a
namespace-aware parser. But a pattern can never match an xml element
which has a namespace unless the "setNamespaceURI" method has been
called on the Rule object (either directly, or indirectly via
Rules.setNamespaceURI or Digester.setRuleNamespaceURI).

Note that the setRuleNamespaceURI method used in your testcase has no
effect:
Digester d = DigesterLoader.createDigester(rules);
d.setNamespaceAware(true);
d.setRuleNamespaceURI("www.diku.dk");
That method only affects rules added after the call is made; but by the
time you call it here, all the rules have already been added. In fact,
there is currently no way to use the "setNamespaceURI" functionality
with xmlrules as far as I can see. If you would like to provide a patch
to add that to xmlrules somehow, that would be nice. I can't suggest
how, though. And you'd certainly need to read the RulesBase
implementation of the match(namespace, name) method to understand how
Digester's horribly hacky implementation of namespace support currently
works.


I still don't understand the point of the changes to the NodeCreateRule;
see my comments in the previous email.



Regards,

Simon


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

Re: jsvc problem

[Simon Kitching]

On Fri, 2005-03-04 at 15:37 +0200, Vasiliy Keretsman wrote:
> Hello!
> 
> I have some problem with JSVC using commons-daemon-1.0.
> It seems to me it can not find DaemonLoader class. But
> commons-daemon.jar is in classpath
> 
> 
> jsvc.exec debug: Java VM created successfully
> jsvc.exec error: Cannot find daemon loader 
> org/apache/commons/daemon/support/DaemonLoader
> jsvc.exec error: Service exit with a return value of 1
> 
> Command line is
> #jsvc -debug -home $JAVA_HOME -cp commons-daemon.jar MAIN_CLASS
> 
> Can anybody help me?

Perhaps $JAVA_HOME has a space in it? You could try:
  jsvc -debug -home "$JAVA_HOME" -cp commons-daemon.jar MAIN_CLASS

Regards,

Simon



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

Re: [configuration]License issues

[Simon Kitching]

On Sat, 2005-03-05 at 11:42 +0100, Oliver Heger wrote:
> Emmanuel Bourg wrote:
> 
> > Oliver Heger wrote:
> >
> >> I noticed that in some of our files the license header is missing, 
> >> especially in the xdocs files. Does it have to be added or is it not 
> >> needed in those files?
> >
> >
> > Not sure, what's the rule for the other commons projets ?
> >

It was pointed out on the legal-discuss list that if there is a
copyright statement in a file but no license then theoretically people
other than the copyright owner cannot use the file; the license is what
grants them the right to use, modify and distribute the file.

As we *want* people to be able to use the xdocs, we really need to have
a license in them.

I do have an outstanding request for the issue of license text in
*javadoc output* to be clarified, ie whether it is necessary to ensure
the .html files generated by the javadoc tool contain the license or a
reference to it. My personal view is that it is *not* necessary, but
IANAL and all that.

Cheers,

Simon


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

[beanutils] patch for test case failures under maven

[Simon Kitching]

Hi,

I have found that running "maven test" for beanutils reports a failure
of 3 test cases.

(a) BeanificationTestCase and LocaleBeanificationTestCase both fail to
load a test class using the code:
   ClassLoader loader = new ClassLoader() {};
   Class myClass = loader.loadClass(
 "org.apache.commons.beanutils.BetaBean");

I believe the problem is that maven runs the unit tests within a custom
classloader or somesuch, and so the above code which creates a
classloader whose parent is the *system* classloader can't find the test
case classes.

Changing the above to:
   ClassLoader loader = new ClassLoader(
 this.getClass().getClassLoader()) {};
   ...
resolves the issue.

(b) in the test/.../locale/converters directory, file
"BaseLocaleConverterTestCase.java" doesn't actually define any test
cases at all; it is just intended as a base class for the other tests to
extend. But junit regards it as an error for a TestCase class not to
have any tests. Simply adding a dummy test method resolves this. (NB:
the alternative would be to rename the class [eg to
"BaseLocaleConverterTester"] and then change each class that inherits
from it to match the new name which is probably a "purer" solution but
much more hassle.



Are there any objections to me committing these changes to beanutils?

I have also been working on bug# 18294. Are the beanutils maintainers ok
with me adding myself to the "developers" list for beanutils and
applying the necessary changes for that?

Thanks,

Simon



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

[logging] 1.0.5: WeakHashtable

[Simon Kitching]

Hi,

Here are a few comments on logging-1.0.5-alpha1. More to come..

===

Should the WeakHashtable class be rolled into commons-logging.jar?
It seems easier for users than remembering to deploy the extra jar, and
should be feasable by having something like this in 
   Hashtable foo;
   String version = System.getProperty("java.vm.specification.version");
if (versionLessThan(version, "1.3")) {
  foo = new Hashtable();
} else {
  // use reflection to create instance
  foo = createWeakHashtable();
}
  
Or is the reason for having it separate because there is a performance
hit when using it? If that is so, then file guide.xml should document
that rather than saying "always deploy it when using java 1.3 or later".


===

The current javadoc for the WeakHashtable class doesn't include a
description of the general problem it's trying to solve (though this is
well described in the guide.xml).

I found it rather difficult to understand the description of the
remaining issue that this class still doesn't handle.

So attached is a proposed patch to the javadoc for the WeakHashtable
class.

BTW, is there a maven command that will actually generate the javadoc
for the optional classes? 

Regards,

Simon
Index: WeakHashtable.java
===
--- WeakHashtable.java	(revision 156470)
+++ WeakHashtable.java	(working copy)
@@ -22,47 +22,68 @@
 import java.util.*;
 
 /**
- * Implementation of Hashtable that uses WeakReference's
- * to hold it's keys thus allowing them to be reclaimed by the garbage collector.
- * This class follows the symantics of Hashtable as closely as possible.
- * It therefore does not accept null values or keys.
- * 
- * This implementation is also tuned towards a particular purpose: for use as a replacement
- * for Hashtable in LogFactory. This application requires
- * good liveliness for get and put. Various tradeoffs
- * have been made with this in mind.
- * 
- * 
- * Usage: typical use case is as a drop-in replacement 
- * for the Hashtable use in LogFactory for J2EE enviroments
- * running 1.3+ JVMs. Use of this class in most cases (see below) will
- * allow classloaders to be collected by the garbage collector without the need 
- * to call [EMAIL PROTECTED] org.apache.commons.logging.LogFactory#release(ClassLoader) LogFactory.release(ClassLoader)}.
- * 
- * 
- * In a particular usage scenario, use of WeakHashtable alone will
- * be insufficent to allow garbage collection of a classloader without a call to
- * release.  If the abstract class LogFactory is 
- * loaded by a parent classloader and a concrete subclass implementation of 
- * LogFactory is loaded by a child classloader, the concrete
- * implementation will have a strong reference to the child classloader via the
- * chain getClass().getClassLoader(). The WeakHashtable
- * will have a strong reference to the LogFactory implementation as
- * one of the values in its map. This chain of references will prevent 
- * collection of the child classloader.
- * 
- * 
- * Such a situation would typically only occur if commons-logging.jar were
- * loaded by a parent classloader (e.g. a server level classloader in a
- * servlet container) and a custom LogFactory implementation were
- * loaded by a child classloader (e.g. a web app classloader).  If use of
- * a custom LogFactory subclass is desired, ensuring that the
- * custom subclass is loaded by the same classloader as LogFactory
- * will prevent problems.  In normal deployments, the standard implementations 
- * of LogFactory found in package org.apache.commons.logging.impl 
- * will be loaded by the same classloader that loads LogFactory 
- * itself, so use of the standard LogFactory implementations
- * should not pose problems.
+ * Implementation of Hashtable that uses WeakReferences
+ * to hold its keys thus allowing them to be reclaimed by the garbage collector.
+ * The associated values are retained using strong references.
+ *
+ * This class follows the symantics of Hashtable as closely as
+ * possible. It therefore does not accept null values or keys.
+ *
+ * Class org.apache.commons.logging.LogFactory looks to see whether this 
+ * class is present in the classpath, and if so then uses it to store
+ * references to the LogFactory classes it loads, rather than using a standard
+ * Hashtable instance. Having this class used instead of Hashtable solves
+ * certain issues related to dynamic reloading of applications in J2EE-style
+ * environments. However this class requires java 1.3 or later, due to its use
+ * of java.lang.ref.WeakReference and related class, and therefore cannot be
+ * included in the main logging distribution which supports JVMs prior to 1.3.
+ * And by the way, this extends Hashtable rather than Hashmap because of 
+ * LogFactory's desire to be compatible with 1.1 JVMs. See the documentation
+ * for method LogFactory.createFactoryStore for more details.
+ *
+ * The reason a

Re: [logging] distribution packaging

[Simon Kitching]

On Wed, 2005-03-09 at 22:18 +, robert burrell donkin wrote:
> On Wed, 2005-03-09 at 07:24, Torsten Curdt wrote:
> > TBH I am pretty much sick of those discussion
> > whether to use JCL or not that come up in other
> > projects. IMHO it would be great to fix (as
> > good as possible) what people are complaining
> > about.
> 
> JCL lacks energy and community. it's a tough project to work on and it's
> a pretty thankless task. i think that there's hope but only if the
> community can rally round. 

Well, by my count the following people are actually willing to work on
fixing JCL:
 * Robert Donkin
 * Richard Sitze
 * Torsten Curdt?
 * Brian Stansberry
 * Simon Kitching (me).

 + Ceki offering his views
 + Tomas Znamenacek ?

I think that is sufficient to get some momentum on this - particularly
if tomcat/geronimo/other teams are willing to do some testing of
releases to make sure we don't break anything badly.

As you say, it's a tough and tricky project. But I expect we all work
with container-style projects on a regular basis so it's in our own
interests to get this right :-).

And intellectually I find it an interesting project to get to grips with
- I expect we'll all be experts on classloaders + related issues by the
time this is sorted!


What I'm trying to do at the moment is actually put together a
"requirements document" for logging, after which I intend to see how
UGLI fits the requirements so I can understand how static resolution
fares versus the current dynamic stuff. If anyone's already created a
list of logging requirements (including required behaviour when
classloaders are involved), then please point me at the info so I can
save my time!


Cheers,

Simon


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

[logging] parent-first classloaders

[Simon Kitching]

Hi Ceki,

You mentioned in your page on JCL
(http://www.qos.ch/logging/classloader.jsp):


Jake also keeps reminding us on the log4j-dev mailing list that the
child-parent delegation model is not the only model out there and that
parent-first delegation model is alive and well.


Are you able to provide the names of some frameworks that use
parent-first classloading? I'm curious to find out whether these are
large + well-used frameworks or whether these are experimental and/or
obsolete systems.

I find it odd that a container would make it impossible for a contained
application to override libraries that the parent provides. This seems
rather fragile and inflexible to me; maybe reading the documentation for
some projects which "Jake" has referred to will help me understand the
reasons for using parent-first delegation.

Regards,

Simon


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

Re: [logging] parent-first classloaders

[Simon Kitching]

On Thu, 2005-03-10 at 16:25 +1300, Simon Kitching wrote:
> Hi Ceki,
> 
> You mentioned in your page on JCL
> (http://www.qos.ch/logging/classloader.jsp):
> 
> 
> Jake also keeps reminding us on the log4j-dev mailing list that the
> child-parent delegation model is not the only model out there and that
> parent-first delegation model is alive and well.
> 
> 
> Are you able to provide the names of some frameworks that use
> parent-first classloading? I'm curious to find out whether these are
> large + well-used frameworks or whether these are experimental and/or
> obsolete systems.
> 
> I find it odd that a container would make it impossible for a contained
> application to override libraries that the parent provides. This seems
> rather fragile and inflexible to me; maybe reading the documentation for
> some projects which "Jake" has referred to will help me understand the
> reasons for using parent-first delegation.

I received the following email from Paul Smith ([EMAIL PROTECTED]) which
did not get to this list because, apparently, the moderator rejected it.
It's certainly on-topic and useful so I presume this was just a slip of
the mouse on the moderator's part. Anyway, here's Paul's email:


Resin's default class loader behaviour is parent first.  In Resin 2 to 
emulate the "true" specifaction, one has to:

false  [1]

Which shows you what the Caucho folks think of child-first
delegation :)

[1] - http://www.caucho.com/support/resin-interest/0403/0132.html

Paul Smith


Following the email thread referred to above:

* Joseph Dane recommends using Resin's default parent-first classloading
but ensuring that the Resin classloader actually has no jars in the path
(ie nothing in resin/lib).
Well, if there is nothing in the parent classloader, then
parent-first and child-first are effectively equivalent, yes? So this
advice is not bad, but doesn't shed any light on why Resin goes with
parent-first

* Eric Hauser recommends using a Resin-proprietory extension to
classloading, which involves putting
  
in the web.xml file.
I'll try to track down exactly what exactly this does with
respect to class-loaders and CLASSPATHs


NB: in Resin 3.0, the  feature still exists,
but has been moved in the config file to "class-loader/servlet-hack".


I've done a fair bit of research in the hope of finding additional info
on resin's classloading policy:

* The Resin docs for the servlet-classloader-hack config element:
http://www.caucho.com/products/resin/ref/http-config.xtp#servlet-classloader-hack
Nope, no clues there

* Hmm..here's a reply to a question from one Torsten Curdt; now where
have I seen that name lately? :-)
http://www.caucho.com/support/resin-interest/0305/0223.html
In the end, though, it doesn't shed a lot of light on why Resin doesn't
wish to follow the java spec...

The "resin-reference.pdf" file has a fraction more information. It
states that using child-first loading "can cause surprising
ClassCaseExceptions". Yep, that's the full description of why they
reject the sun recommendation.

The resin source code doesn't hold any clues either. No comments at all
on why they prefer parent-first.


So I'm still looking for someone to suggest why anyone would not use
child-first


Regards,

Simon


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

RE: [PATCH][commons-daemon]Setting the process name

[Simon Kitching]

On Mon, 2005-03-07 at 19:12 -0400, Derek Lohnes wrote:
> Has anyone had a chance to look at this?  Also did anyone get the patch
> file attached to the email?  I'm sure I attached it, but I just noticed
> that the attachment I got with the email was a file containing this
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> Thanks
> 
> 
> 
> -Original Message-
> From: Derek Lohnes [mailto:[EMAIL PROTECTED] 
> Sent: Monday, February 28, 2005 11:46 AM
> To: commons-dev@jakarta.apache.org
> Subject: [PATCH][commons-daemonSetting the process name
> 
> I'm using the JSVC to run multiple java processes.  I would like to be
> able to tell them apart when viewing the process list.  Currently they
> all display as jsvc-exec.  The patch contains a new command line
> argument called procname.  If procname is passed as an argument to jsvc
> it is as the process name instead of the hardcoded 'jsvc.exec'.
> 
> Also could you tell me when the next release would be available I'd
> prefer to use a released version of jsvc then a locally modified
> version, assuming this patch is accepted.

Hi Derek,

As there has not been any immediate response to this, I would suggest
that you creat a bugzilla entry and attach your patch there. That way
things won't get lost, and the issue will be visible whenever anyone
does a search on open bugs for commons-daemon.

I expect that commons-daemon has a fairly small pool of committers (it
involves JNI code which is not a hugely popular area) and I suspect
building/testing new releases is a significant effort as it involves
getting access to multiple OSes. Because of these, I would guess that
response to your patch may be slow.

After the bugzilla entry has been created, I recommend posting a polite
reminder every fortnight or so (to the bugzilla entry or direct to this
list).


Regards,

Simon



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

Re: [logging] is setting context classloader correctly mandated by J2EE container specifications?

[Simon Kitching]

On Sat, 2005-03-12 at 18:20 +, robert burrell donkin wrote:
> i've been doing some digging today. i've been trying to find a sun
> specification (other than the J2SE javadocs) that mandates the context
> classloader is set appropriately. this is something which J2EE
> containers generally do but i was wondering whether this was actually
> mandated or not.
> 
> anyone know?

I've been doing quite a lot of research into this sort of thing over the
last couple of days.

The official spec is:
  http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf

Section 6.2.4.8:

This specification requires that J2EE containers provide a per thread
context class loader for the use of system or library classes in
dynamicly loading classes provided by the application.  The EJB
specification requires that all EJB client containers provide a per
thread context class loader for dynamicly loading system value classes.
The per thread context class loader is accessed using the Thread method
getContextClassLoader.

The classes used by an application will typically be loaded by a
hierarchy of class loaders. There may be a top level application class
loader, an extension class loader, and so on, down to a system class
loader.  The top level application class loader delegates to the lower
class loaders as needed.  Classes loaded by lower class loaders, such as
portable EJB system value classes, need to be able to discover the top
level application class loader used to dynamicly load application
classes.

We require that containers provide a per thread context class loader
that can be used to load top level application classes as described
above.



The authors appear to have made a huge effort to produce
incomprehensible specs.

In a normal stand-alone java application, there are three classloaders
in operation when main(String[]) is called:
 * the "top-level application class loader", which loads rt.jar etc, and
   is referred to using "null" as the classloader reference.
 * its direct child the "extension class loader", which loads stuff
   from $JAVA_HOME/ext/lib
 * its direct child the "application class loader", which loads stuff
   from $CLASSPATH.

So while this section does say that   
   Thread.currentThread().getContextClassLoader() 
must return *some* classloader, it doesn't appear to mandate that there
is a unique classloader created for each deployed component within a
j2ee environment.

The sentence "Classes loaded by lower class loaders..." seems to be
talking about per-component classloaders. But the text doesn't
explicitly say that they must exist. And doesn't say that this
classloader is what thread context-classloader points to when running
the component.

The term "system value class" does not appear to be defined anywhere in
the document, and damned if I know what it means. The term "top level
application classes" is not defined either.

The text isn't even spelled correctly in places. Sigh.


And besides, commons-logging and commons-beanutils and similar don't
just need to work in j2ee-compliant frameworks; they need to work in all
*real-world* frameworks. And as can be seen from replies to my earlier
question about parent-first vs child-first classloading, popular tools
such as Resin and Websphere provide deployment options that violate the
j2ee spec anyway.


I've come to the realisation that what we are trying to achieve, both in
commons-logging and in commons-beanutils, is an implementation of the
Singleton pattern which works properly in systems that fiddle with
classloaders. And I've come to the conclusion that it is *extremely*
hard to do so correctly given java's approach to classloading.

BTW, sections 8.2 through 8.4 are also relevant to classloading
behaviour of j2ee environments. I'm pretty sure this mandates
child-first classloading (though the specs are just as badly written
here as they are in 6.2.4.8). I'll send a separate email on that topic
soon.

Regards,

Simon


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

Re: [logging] is setting context classloader correctly mandated by J2EE container specifications?

[Simon Kitching]

On Sun, 2005-03-13 at 10:40 +1300, Simon Kitching wrote:
> In a normal stand-alone java application, there are three classloaders
> in operation when main(String[]) is called:
>  * the "top-level application class loader", which loads rt.jar etc, and
>is referred to using "null" as the classloader reference.
Oops .. I meant the "system class loader" as used in the spec
terminology of course. Though ClassLoader.getSystemClassLoader()
actually returns what I believe the spec refers to as the "top-level
application classloader".

All in all, a complete balls-up of terminology in this spec..

Regards,

Simon


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

[beanutils] j2ee unit tests added: memory leak demonstrated (?)

[Simon Kitching]

Hi,

I've just added a unit test o.a.c.beanutils.converter.MemoryTestCase.
This test case currently fails, demonstrating (I believe) that there is
a serious memory leak in beanutils in j2ee-like environments when
components are "undeployed".

The tests show that if a Converter is registered while
Thread.getContextClassLoader is set to a component-specific classloader,
then when the component is "undeployed" that classloader cannot be
garbage-collected.

The problem is: I can't spot what is *causing* this bug. It would be
great if someone else could have a look too.

Given the new code in commons-logging that is intended to address a
similar issue, I think this is worth resolving before releasing
commons-logging 1.0.5

Regards,

Simon


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

RE: Logging: SimpleLog not thread-safe

[Simon Kitching]

It might do; not sure what the performance of ThreadLocal is. However
the price is extra memory usage: a DateFormatter for every thread in the
system that ever logs a message.

On Wed, 2006-10-11 at 17:42 -0400, Kenneth Xu wrote:
> Hi,
> 
> I think a thread local formatter will give us better performance than
> creating one new in every log invocation.
> 
> Just my 2 cents,
> 
> Thanks,
> Ken
> 
> -----Original Message-
> From: Simon Kitching [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, October 11, 2006 5:05 AM
> To: Jakarta Commons Developers List
> Subject: Re: Logging: SimpleLog not thread-safe
> 
> Hi Martin,
> 
> Thanks very much for letting us know about this. I think you're right
> about there being a thread-safety issue. 
> 
> SimpleLog is definitely in use, but obviously this bug will only be
> triggered under pretty rare conditions, and I expect would usually just
> result in a malformed date string which may not be noticed anyway.
> 
> But it should be fixed; I'll try to do that this weekend.
> 
> Regards,
> 
> Simon
> 
> On Fri, 2006-10-06 at 17:15 +0100, Martin Wilson wrote:
> > Hi,
> >  
> > I'm not sure if anyone else uses the SimpleLog class - anyway I've
> > noticed that SimpleLog.log is not thread-safe. The following code
> > (starting on line 282):
> >  
> > if(showDateTime) {
> > buf.append(dateFormatter.format(new Date()));
> > buf.append(" ");
> > }
> >  
> > makes an unsynchronized call to dateFormatter.format. As dateFormatter
> > is an instance variable, and DateFormat.format is not thread-safe, this
> > will cause problems if more than one thread tried to log at the same
> > time.
> >  
> > Solution: remove the dateFormatter instance variable and instantiate a
> > new DateFormat each time in the log method, e.g.
> >  
> > DateFormat dateFormatter = null;
> > try {
> > dateFormatter = new
> > SimpleDateFormat(dateTimeFormat);
> > }
> > catch(IllegalArgumentException e) {
> > dateFormatter = new
> > SimpleDateFormat(DEFAULT_DATE_TIME_FORMAT);
> > }  
> >  
> > Is anyone available who could make this change?
> >  
> > Thanks, 
> > Martin
> 
> > ___
> > 
> > Martin Wilson
> > [EMAIL PROTECTED]
> > 
> > Bright Interactive: successfully delivering interactive websites and
> > business applications
> >  <http://www.bright-interactive.com/> http://www.bright-interactive.com
> > 0870 240 6520
> >  
> 
> 
> -
> 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: SimpleLog not thread-safe

[Simon Kitching]

HI,

On Fri, 2006-10-13 at 00:10 -0400, Kenneth Xu wrote:
> Yes, it'll be GC'ed when thread is. And initialized when first use in a new
> thread. Here is the test code:

But if an application has long-running threads then the object won't be
recycled until the thread dies. So an app with 100 threads has 100
SimpleDateFormat objects long-term. 

And as James noted, when using frameworks like Application Servers,
threads could be pooled in unexpected ways.

I also suspect that in order to fetch data from a ThreadLocal, the JVM
effectively performs a get on a synchronised map, ie that ThreadLocal is
not much more efficient than having a synchronised static DateFormat on
SimpleLog (nb: I have no proof of this, just a hunch).

I think the easiest & most reliable solution is to simply create a
SimpleDateFormat object in the method that needs it. Note that this is
only done after it has been determined that a message *will* be output,
which in most cases means that there will be disk io that will have far
more impact on the system than creating a simple object. Optimising the
path in commons-logging that determines *if* a message is to be logged
is important; optimising the actual logging operation is much less
critical.

Of course I'm open to persuasion on this (eg performance stats)..

Cheers,

Simon


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

Re: Logging: SimpleLog not thread-safe

[Simon Kitching]

On Sat, 2006-10-14 at 08:07 -0400, James Carman wrote:
> Tomcat had this same issue a while back.  It was trying to use a single
> SimpleDateFormat object to parse/format date-valued HTTP headers.  I
> submitted the patch for it and I think we decided to just instantiate as
> needed.  Local variables are garbage collected much more reliably from
> what I understand.  And, as Simon pointed out, the probable disk i/o would
> be the big bottleneck, not the object instantiation.

Ok, so next issue: this member is declared protected:
 static protected DateFormat dateFormatter = null;
(and initialised via a static block on the class).

This means that removing it is a binary-incompatible change; any
subclasses will be broken. Sigh. Once again we learn the lesson that
protected members should be avoided just like public ones, as the
binary-compatibility issue they cause are exactly the same.

I'd be willing to bet money that no-one in the world has ever subclassed
SimpleLog, but the issue is there. And of course binary compatibility is
a very big issue for such a core lib as logging.

Options:
 (1) leave this member here, but don't use it.
 (2) remove it, and release as 1.1.1
 (3) remove it, and increment logging version to 1.2

This option does mean that code will continue to run, but if anyone
*had* subclassed SimpleLog then they would get output in the default
format, not their customised format. As they presumably had a good
reason for customising the output, their app may misbehave due to a
bugfix-level change.

Option 2 could potentially cause an existing application to throw an
exception when the SimpleLog subclass tries to access member
dateFormatter.

Option 3 is the theoretically correct one, but is rather overkill for
such a small change.

I'm tempted to choose (1), though none of the options are terribly
appealing.

Comments anyone?

Cheers,

Simon


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

Re: Logging: SimpleLog not thread-safe

[Simon Kitching]

After some thought, I've changed my mind about the solution.

I think the best choice is instead to use a synchronized block:

   // Append date-time if so configured
if(showDateTime) {
Date now = new Date();
String dateText;
synchronized(dateFormatter) {
dateText = dateFormatter.format(now);
}
buf.append(dateText);
buf.append(" ");
}

This:
(a) Avoids any binary-compatibility issues, as the member is still
present and still used. There is a potential race condition in that
subclasses of SimpleLog theoretically need to synchronize on the object
if they access it, which is a new requirement. However as there is
*currently* a thread race condition I don't feel we've made anything
worse in that area.
(b) works correctly if a subclass replaces the dateFormatter with some
other object; creating the SimpleDateFormat object in the log method
would break that.
(c) Avoids creating the SimpleDateFormat object. In cases where the
format string is complicated, this construction might actually take some
significant time. Performing synchronization should actually be faster.

I've committed R464108 which implements the synchronized fix.
All comments welcome.

Regards,

Simon


On Sun, 2006-10-15 at 15:50 +1300, Simon Kitching wrote:
> On Sat, 2006-10-14 at 08:07 -0400, James Carman wrote:
> > Tomcat had this same issue a while back.  It was trying to use a single
> > SimpleDateFormat object to parse/format date-valued HTTP headers.  I
> > submitted the patch for it and I think we decided to just instantiate as
> > needed.  Local variables are garbage collected much more reliably from
> > what I understand.  And, as Simon pointed out, the probable disk i/o would
> > be the big bottleneck, not the object instantiation.
> 
> Ok, so next issue: this member is declared protected:
>  static protected DateFormat dateFormatter = null;
> (and initialised via a static block on the class).
> 
> This means that removing it is a binary-incompatible change; any
> subclasses will be broken. Sigh. Once again we learn the lesson that
> protected members should be avoided just like public ones, as the
> binary-compatibility issue they cause are exactly the same.
> 
> I'd be willing to bet money that no-one in the world has ever subclassed
> SimpleLog, but the issue is there. And of course binary compatibility is
> a very big issue for such a core lib as logging.
> 
> Options:
>  (1) leave this member here, but don't use it.
>  (2) remove it, and release as 1.1.1
>  (3) remove it, and increment logging version to 1.2
> 
> This option does mean that code will continue to run, but if anyone
> *had* subclassed SimpleLog then they would get output in the default
> format, not their customised format. As they presumably had a good
> reason for customising the output, their app may misbehave due to a
> bugfix-level change.
> 
> Option 2 could potentially cause an existing application to throw an
> exception when the SimpleLog subclass tries to access member
> dateFormatter.
> 
> Option 3 is the theoretically correct one, but is rather overkill for
> such a small change.
> 
> I'm tempted to choose (1), though none of the options are terribly
> appealing.
> 
> Comments anyone?
> 
> Cheers,
> 
> Simon
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

Re: Three votes of PMC members required

[Simon Kitching]

+1

On Sun, 2006-10-15 at 15:44 +0200, Jochen Wiedmann wrote:
> Hi,
> 
> AFAIK the policy is still that three votes of PMC members are
> required. In other words, may I point you to
> 
> http://marc.theaimsgroup.com/?t=11606631873
> 
> and ask kindly for positive votes? (Unless you have reason for
> negative votes, of course.)
> 
> Jochen
> 


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

[general] good maven2 pom.xml to copy?

[Simon Kitching]

Hi,

I'd like to enable building of digester with maven2. Any suggestions as
to which commons project's pom.xml I should base it on? I know some work
has been going on for maven2 support recently..

Thanks,

Simon


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

Re: [VOTE] Release commons-proper POM 1

[Simon Kitching]

On Thu, 2006-10-12 at 22:02 +0200, Jochen Wiedmann wrote:
> Currently there is only a SNAPSHOT POM for commons proper: In other
> words, a release of commons-fileupload can only choose to ignore the
> hierarchy and derive from the Apache POM directly or it can wait for
> an official release of the commons-proper POM, it's natural parent.
> The latter is what we vote about.

This thread from 12 October 2006 appears to have tailed off without
conclusion:
  http://marc.theaimsgroup.com/?t=11606631873&r=1&w=2

As far as I can see, all the issues that were raised were fixed thanks
to hard work by Jochen Wiedmann. People were sounding pretty positive
about the final state of this file. Rahul suggested starting a new Vote
thread for clarity as the first one had a lot of discussion happening
but I can't see that one occurred.

See also:
http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-parent/trunk/

I'm hoping to get a release of commons-digester out sometime soon, and
it would be good to have maven2 support. However it's pretty ugly to
point at a parent pom with SNAPSHOT version, as builds of that release
aren't repeatable; the parent pom can change.

There is also work currently going on for a Betwixt release. It would be
nice to have maven2 support for that too...

Cheers,

Simon


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

Re: [VOTE] Release commons-parent pom

[Simon Kitching]

On Mon, 2006-11-06 at 18:47 +0100, Dennis Lundberg wrote:
> Hello
> 
> This is a new vote following up on the failed vote [1] that was held 
> previously.
> 
> As far as I can tell, all the issues that were raised in the earlier 
> vote has been addressed. So please cast your votes.
> 
> This vote will be open for 72 hours and I will tally the votes no 
> earlier than 19:00 GMT+1 on November 9th.

+1   (pmc member)



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

Re: svn commit: r472006 - /jakarta/commons/proper/commons-parent/trunk/pom.xml

[Simon Kitching]

This is the old-style license header. The new style is as shown at the
top of this file:
http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/trunk/build.xml

Regards,

Simon

On Tue, 2006-11-07 at 06:39 +, [EMAIL PROTECTED] wrote:
> Author: jochen
> Date: Mon Nov  6 22:39:17 2006
> New Revision: 472006
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=472006
> Log:
> Adding the ASLv2 header.
> 
> Modified:
> jakarta/commons/proper/commons-parent/trunk/pom.xml
> 
> Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml
> URL: 
> http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diff&rev=472006&r1=472005&r2=472006
> ==
> --- jakarta/commons/proper/commons-parent/trunk/pom.xml (original)
> +++ jakarta/commons/proper/commons-parent/trunk/pom.xml Mon Nov  6 22:39:17 
> 2006
> @@ -1,3 +1,20 @@
> +



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

Re: [VOTE] Release commons-parent pom

[Simon Kitching]

On Tue, 2006-11-07 at 07:43 +0100, Jochen Wiedmann wrote:
> On 11/7/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> > c) The svn log is confident [1] the antrun bit is needed due to a bug
> > in the source plugin, but subsequent conversations not so [2]. What is
> > it, IYO? Figure you're as good a resource for this question.
> 
> Sorry, but my english language parser (an ancient german model from
> 1963, so please bear with me) can't understand your question?
> 
My reading of the email referred to at [2] is confirmation that the
antrun bit *is* needed.


> 
> P.S: I never experienced votes with so much considerations. Perhaps we
> should hide the POM in a zip file and add thousands of .java files, so
> that people don't look so much ... ;-)

Releases of other projects have gone through quite a few cycles too.
It's just fortunate that in this case we don't need to build RC bundles
each time :-)


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

Re: [digester] Time for 1.8? (was: DIGESTER-107)

[Simon Kitching]

Hi Rahul,

On Thu, 2006-11-09 at 13:44 -0500, Rahul Akolkar wrote:
> > On 9/25/06, Simon Kitching (JIRA) <[EMAIL PROTECTED]> wrote:
> 
> >
> > > It's probably a good time; a couple of minor bugfixes/enhancements have 
> > > been made that deserve release (see RELEASE-NOTES.txt).
> > >
> 
> 
> Coming back to this thread, couple of quick comments before we hit an
> RC (no rush, but wanted to get to this before a RC was cut):
> 
> a) Lets wean digester off of collections (and upgrade beanutils to 1.7)

Not sure.

If you're talking about the dependency declarations in the pom.xml, it's
the way it is at the moment because I just based the maven2 pom on the
maven1 stuff; I'm more focused at the moment on getting the maven2 build
working than updating the maven1 stuff.

Historical note:
Digester doesn't have a dependency on Collections directly.
Unfortunately, Digester does need Beanutils, and Beanutils has a
collections class in its public API. What Robert Donkin did in the 1.7
release of Beanutils was bundle the necessary collections class in the
Beanutils library. It's a little ugly but it was a very stable class and
breaks the dependency from BeanUtils on Collections. That's why the
release notes state that Digester's dependency is *either* beanutils1.6
+ collections or beanutils1.7 (no collections).

Unfortunately maven has no way of expressing this either/or dependency,
so we have to choose one or the other. 

If we go for the beanutils1.7 option, then people wanting to use
Digester in an app that needs beanutils 1.6 are out of luck. However if
we leave things as they are (collections+beanutils) they can just use a
maven2 dependency exclusion to suppress the collections dependency and
all will be well, no?

On the other hand, declaring both deps makes everyone's app larger than
it needs to be if they don't otherwise need collections.

> 
> b) We're missing a few serial version UIDs (adding those might
> unnecessarily break some serialization contracts though)

I would lean towards adding the UID on any class we change, and leaving
it alone on anything we haven't modified. I'll look to see if any of the
classes changed since 1.7 have a missing UID. And of course we should
check that the UID on any changed class has been updated!


> WDYT?
> 
> If theres anything I can help with for the release, let me know.

If you want to get stuck in to the pom.xml file, please go ahead. What
I've committed so far is just an initial stab; there is still 1 unit
test failure when running under surefire and I haven't got to testing
the distribution step yet.

Or you could look at the UID stuff, if you agree with my comments above.

Otherwise I think things are pretty good to go.

Cheers,

Simon


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

Re: [Digester] Maven2 POM Questions and Proposals

[Simon Kitching]

On Wed, 2006-11-15 at 22:20 -0500, Rahul Akolkar wrote:
> On 11/14/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

> > I was going to try it myself but I get a test failure, see below, so I
> > haven't been able to try it myself.
> >
> >
> > ---
> > Test set: org.apache.commons.digester.NodeCreateRuleTestCase
> > ---
> > Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.062
> > sec <<< FAILURE!
> > testNonNamespacedAttribute(org.apache.commons.digester.NodeCreateRuleTestCase)
> >   Time elapsed: 0 sec  <<< FAILURE!
> > junit.framework.AssertionFailedError
> > at junit.framework.Assert.fail(Assert.java:47)
> > at junit.framework.Assert.assertTrue(Assert.java:20)
> > at junit.framework.Assert.assertNotNull(Assert.java:220)
> > at junit.framework.Assert.assertNotNull(Assert.java:213)
> > at
> > org.apache.commons.digester.NodeCreateRuleTestCase.testNonNamespacedAttribute(NodeCreateRuleTestCase.java:437)
> >
> 
> 
> Hmm, cannot reproduce the failure locally. The nightlies seem to be
> happy too (though they're running the test under m1). Any more details
> about your setup or other clues?

Works for me too (Sun java 1.5.0 on Linux).

Initially it would look like the xml parser in use is behaving
differently from what most people get.

What JVM are you using - not gcj by any chance?

Cheers,

Simon


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

Re: [all] Digester 1.8-RC1 available

[Simon Kitching]

On Fri, 2006-11-17 at 17:39 -0500, Rahul Akolkar wrote:
> On 11/17/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > On 11/17/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> > >
> > > http://people.apache.org/~rahul/commons/digester/
> > >
> > > Notes:
> > > * The site requires manual "installation" of the 1.8 directory on the
> > > webserver; since this can't/shouldn't be done until the release vote
> > > actually passes, there are several 404s on the site home page (that
> > > will get filled in)
> > > * Going to JCL 1.1 we should be aware of  MEV-392 [1], and whether
> > > that warrants staying at 1.0.4
> >
> >
> > Or maybe just do a C-L 1.1.1 that fixes this, and depend on that instead?
> > Digester is certainly not the only downstream C-L user this would affect.
> >
> 
> 
> Correct, though that needs a separate discussion (which we should
> probably be having anyway) and a release. What do others think?

I'm keen to see a JCL 1.1.1 release out if there is enthusiasm for
others to work on this. There are a couple of minor bugfixes since 1.1
that are also worth pushing out (see the release notes). The problem
with JCL releases is that they are hard to do and hard to test, so take
quite a bit of time to get done.

http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt

Cheers,

Simon


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

Re: sorry to bother - can't build Jelly

[Simon Kitching]

Hi Darryl,

In future, please send emails to the user list rather than this one (see
the jelly home page for mailing list details):
  http://jakarta.apache.org/commons/jelly/
ie please don't reply to this; if you have any further questions start
an email on the user list. When posting to that list, please put the
commons component in the subject line, eg 
  [jelly] need help building from source

Jelly doesn't support maven 2.x yet (pom.xml file), just maven 1.x
(project.xml).

And the command you want is:
   maven package
or
   maven install
not
   maven jar

Regards,

Simon

On Wed, 2006-11-15 at 15:16 -0800, Darryl Fenwick wrote:
> 
> I'm writing to the "nag" e-mail address with the (perhaps vain) hope 
> that someone can help me.  I have followed the instructions for 
> building Jelly on the web page but can't get anywhere.  I am 
> completely inexperienced with maven so perhaps I am doing something wrong.
> 
> (1)  I downloaded maven-2.0.4 binary distribution
> (2)  I downloaded with svn the latest code from the cvs repository
> (3)  I cd'd to the Jelly directory, where there is a project.xml
> (4)  I set MAVEN_HOME to where I installed maven
> (5)  I call %MAVEN_HOME%\bin\mvn jar
> 
> I get the following message
> 
> [INFO] Scanning for projects...
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Invalid task 'jar': you must specify a valid lifecycle phase, 
> or a goal in the format plugin:goal or pluginGroupI
> d:pluginArtifactId:pluginVersion:goal
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Wed Nov 15 15:14:51 PST 2006
> [INFO] Final Memory: 1M/2M
> [INFO] 
> 
> 
> what am I doing wrong?  I'd love to start testing out Jelly because I 
> think it is an answer to a very specific problem I am having.
> 
> Many thanks,
> 
> Darryl
> 
> 
> Darryl Fenwick
> Senior Product Manager
> Streamsim Technologies, Inc
> 204 Ramona St
> Palo Alto, CA 94301
> +1 650 557 2196 
> 
> 
> 
> 
> 
> -
> 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] Maven2 POM Question

[Simon Kitching]

On Fri, 2006-11-17 at 18:52 -0800, Craig McClanahan wrote:
> The pom.xml file for Commons Logging in the trunk has an "interesting"
> approach to declaring dependencies, based on the existence or non-existence
> of a file named "commons-logging-README.txt".  AFAICT, the purpose for this
> is to make the dependencies non-optional when you are building Commons
> Logging itself, but optional for downstream users.
> 
> Is that a correct understanding of the purpose?  If so, we should really
> document this in the pom.xml file, so others don't have to puzzle out the
> thinking.

Sorry :-). That's exactly the purpose. I'll add a comment now.



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

Re: svn commit: r476429 - /jakarta/commons/proper/logging/trunk/pom.xml

[Simon Kitching]

On Fri, 2006-11-17 at 20:53 -0700, Wendy Smoak wrote:
> On 11/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: skitching
> > Date: Fri Nov 17 19:41:32 2006
> > New Revision: 476429
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=476429
> > Log:
> > Add comments about unusual dependency-handling approach.
> ...
> > if we declare them optional then
> > +- when JCL is *compiled* we get none of them in the classpath.
> 
> Are you saying that if you mark the dependencies optional, you get
> compilation errors?  That doesn't sound right.

Well, that's exactly what happens.

[INFO] Compilation failure

/home/simon/apache/commons-svn/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4JLogger.java:[23,24]
 package org.apache.log4j does not exist

etc

> 
> If you mark it optional, it will be excluded from transitive
> dependency resolution when a project depends on commons-logging.  But
> it should be on the compile-time classpath.
> 

That's what I'd like to see happen, but it doesn't appear to (using
maven 2.0.4 on Linux).

Regards,

Simon


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

[logging] Re: svn commit: r476429 - /jakarta/commons/proper/logging/trunk/pom.xml

[Simon Kitching]

On Fri, 2006-11-17 at 21:19 -0700, Wendy Smoak wrote:
> On 11/17/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
> 
> > > Are you saying that if you mark the dependencies optional, you get
> > > compilation errors?  That doesn't sound right.
> >
> > Well, that's exactly what happens.
> 
> Found it.  Optional is not a scope, it's a separate element.
> 
> Instead of optional, use true.
> 

Thank you Wendy! That makes a whole lot more sense.

It would be really nice if Maven would report an error if the scope
value is invalid rather than silently ignoring the dependency completely
(as 2.0.4 evidently does). I'll try to check with mvn trunk and request
an enhancement if this behaviour is still the same (unless someone has
the latest maven trunk checked out and can check more easily?).

Regards,

Simon


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