You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Proctor <li...@markproctor.com> on 2005/11/08 14:52:17 UTC
[jci] patches
http://issues.apache.org/bugzilla/show_bug.cgi?id=37394 Groovy no longer
allows null CompilerConfiguration
I'm also just writting a simple CompilerFactory class. Once that is done
I'll weigh up either ripping jci into the Drools tree sans
common-logging requirement or build an event model instead.
Mark
Torsten Curdt wrote:
> What about a filter? ;)
>
>> No not subscribed to commons dev - would have done if you had a
>> mailing list just for JCI but don't wan't all the other crap that
>> comes through.
>>
>> Mark
>> Torsten Curdt wrote:
>>>> Oh missed this one out:
>>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=37394 Groovy no
>>>> longer allows null CompilerConfiguration
>>>> Mark Proctor wrote:
>>>>> Torsten,
>>>>>
>>>>> I've done a fair bit of work on jci tonight, trying to get it ship
>>>>> shape for Drools. Can you commit these asap so that I can do
>>>>> further work with a clean checkout.
>>>>>
>>>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=37389 Optional
>>>>> ClassLoader
>>>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=37390 implement
>>>>> removeResourceStore
>>>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=37391 add
>>>>> System.gc() to ReloadingClassLoaderTestCase tea...
>>>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=37393
>>>>> AbstractCompilerTestCase hard codes .java but Groov...
>>>>>
>>>>> I'm on http://irc.codehaus.org #drools (aka conan) if you need to
>>>>> chat.
>>>
>>> I'll try to look into that tonight.
>>>
>>> Mark, are you subscribed to commons dev?
>>>
>>> cheers
>>> --Torsten
>>>
>>
>
Re: [jci] c#
Posted by Torsten Curdt <tc...@apache.org>.
> Sorry I forgot that.
> http://tinyurl.com/cqn75
http://svn.plexus.codehaus.org/trunk/plexus-components/plexus-
compiler/plexus-compilers/plexus-compiler-csharp/src/main/java/org/
codehaus/plexus/compiler/csharp/CSharpCompiler.java?rev=2723&view=markup
Cool will have a look
> I was trying to avoid getting involved in that :)
hehe :)
Re: [jci] c#
Posted by Mark Proctor <li...@markproctor.com>.
true
Brett Porter wrote:
> That might be nice, but I think both implementations are necessary.
> Not all of us want to run our Java in IKVM.
>
> Mark Proctor wrote:
>> The plexus example uses a command line compiler, would be nice if we
>> could use IKVM and use an embedded c# compiler - for much the same
>> reason why its nice to use Janino or Eclipse JDT over javac.
>>
>> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jci] Compiling with MemoryReader and MemoryStore
Posted by Torsten Curdt <tc...@apache.org>.
> Is it possible for JCI to be totally in memory? using a memory
> reader and a memory store?
I should :)
> I notice that there is currently no MemoryReader implementation.
Feel free to implement it ...I just haven't come across the need yet.
> Also I thought it would be nice if the store implementations have a
> list() method.
Hm... can you explain why you would like to have that?
That would add a lot more complexity to certain store implementations.
cheers
--
Torsten
[jci] Compiling with MemoryReader and MemoryStore
Posted by Mark Proctor <li...@markproctor.com>.
Is it possible for JCI to be totally in memory? using a memory reader
and a memory store? I notice that there is currently no MemoryReader
implementation.
Also I thought it would be nice if the store implementations have a
list() method.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jci] c#
Posted by Brett Porter <br...@apache.org>.
That might be nice, but I think both implementations are necessary. Not
all of us want to run our Java in IKVM.
Mark Proctor wrote:
> The plexus example uses a command line compiler, would be nice if we
> could use IKVM and use an embedded c# compiler - for much the same
> reason why its nice to use Janino or Eclipse JDT over javac.
>
> Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jci] c#
Posted by Mark Proctor <li...@markproctor.com>.
The plexus example uses a command line compiler, would be nice if we
could use IKVM and use an embedded c# compiler - for much the same
reason why its nice to use Janino or Eclipse JDT over javac.
Mark
Brett Porter wrote:
> Torsten Curdt wrote:
>>> Some time back (and I'm still trying to get around to it), I talked
>>> about merging plexus-compiler with JCI.
>>>
>>> plexus-compiler has a basic c# interface (as well as eclipse,
>>> javac, jikes).
>>
>>
>> For convenience - could you send us a URL to the repository location
>
> Sorry I forgot that.
> http://tinyurl.com/cqn75
>
>>
>>> I also talked about removing the commons-logging dependency (which
>>> seemed to be in agreeance at the time), as at least in our
>>> environment we don't use it.
>>
>>
>> please see other thread
>
> I was trying to avoid getting involved in that :)
>
> I'll move it over there, but this really isn't a comment on
> commons-logging at all.
>
>>
>>> I'm able to help anyone that wants to work on this effort - which
>>> would avoid duplicating the work.
>>
>>
>> That would be great, mate
>>
>> cheers
>> --
>> Torsten
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jci] c#
Posted by Brett Porter <br...@apache.org>.
Torsten Curdt wrote:
>> Some time back (and I'm still trying to get around to it), I talked
>> about merging plexus-compiler with JCI.
>>
>> plexus-compiler has a basic c# interface (as well as eclipse, javac,
>> jikes).
>
>
> For convenience - could you send us a URL to the repository location
Sorry I forgot that.
http://tinyurl.com/cqn75
>
>> I also talked about removing the commons-logging dependency (which
>> seemed to be in agreeance at the time), as at least in our
>> environment we don't use it.
>
>
> please see other thread
I was trying to avoid getting involved in that :)
I'll move it over there, but this really isn't a comment on
commons-logging at all.
>
>> I'm able to help anyone that wants to work on this effort - which
>> would avoid duplicating the work.
>
>
> That would be great, mate
>
> cheers
> --
> Torsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jci] c#
Posted by Torsten Curdt <tc...@apache.org>.
> Some time back (and I'm still trying to get around to it), I talked
> about merging plexus-compiler with JCI.
>
> plexus-compiler has a basic c# interface (as well as eclipse,
> javac, jikes).
For convenience - could you send us a URL to the repository location
> I also talked about removing the commons-logging dependency (which
> seemed to be in agreeance at the time), as at least in our
> environment we don't use it.
please see other thread
> I'm able to help anyone that wants to work on this effort - which
> would avoid duplicating the work.
That would be great, mate
cheers
--
Torsten
Re: [logging] commons logging stubs [was Re: [jci] c#]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wed, 2005-11-09 at 15:51 +0000, Mark Proctor wrote:
> We've been discussing the logging issue over in the Drools world. We
> have decided not to fight against this, at some point or other as we
> grow our capabilities and depend more on third party libraries we are
> going to find a tool that insists on commons logging - so might as well
> be now. Atleast JCI will only be used at rulebase creation time and
> won't touch any of the core code. But the idea of stubs sounds good,
> especially if its small and users can just rip it into their own jars
> and namespace and thus avoid extra external dependencies.
the required JCL core is very small in any case.
the advantage of stubbing (and static binding in general) is that users
don't have to cope with the nightmare that are the various different
classloading concepts found in sun specifications over the years and
then try to work out what the implementation provided by container
vendor actually does in practise.
dynamic binding may or may not (in theory) be capable of addressing the
required use cases but it's not reasonable for users to digest the
advanced classloader theory required to know which of the various copies
of JCL present in their various classloaders should be removed or
replaced.
FWIW the actual Log interface isn't too bad. the more sophisticated
interface being developed by ceki as a JCL alternative plays better with
modern design ideas but there isn't anything wrong with the interface.
the problems arise with the gymnastics performed in order to get a log
implementation quickly in containers with complex classloaders.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] commons logging stubs [was Re: [jci] c#]
Posted by Mark Proctor <li...@markproctor.com>.
We've been discussing the logging issue over in the Drools world. We
have decided not to fight against this, at some point or other as we
grow our capabilities and depend more on third party libraries we are
going to find a tool that insists on commons logging - so might as well
be now. Atleast JCI will only be used at rulebase creation time and
won't touch any of the core code. But the idea of stubs sounds good,
especially if its small and users can just rip it into their own jars
and namespace and thus avoid extra external dependencies.
Mark
Torsten Curdt wrote:
>> I also talked about removing the commons-logging dependency (which
>> seemed to be in agreeance at the time),
>> as at least in our environment we don't use it.
>
> The more I think about this the more I get the opinion we should
> also provide a commons-logging-stub.jar to satisfy commons-logging
> dependencies if you don't like to use it.
>
> I know there has been put quite some effort in fixing CL
> but I fear fixing the reputation is a different issue.
>
> Can a new release of CL rule out all the classloading problems
> people had before?
>
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] commons logging stubs [was Re: [jci] c#]
Posted by Simon Kitching <sk...@apache.org>.
On Wed, 2005-11-09 at 21:14 +0000, robert burrell donkin wrote:
> i agree with ceki that the future is static (rather than dynamic)
> binding. i prefer bytecode engineering to different compilation.
And I agree with both of you - provided one of the static
implementations provides much of the cleverness of the existing JCL
LogFactory class. People can then choose to use it or not.
I've always felt that webapp deployers get their fingers into the
container configuration far more than they should. A container is an
operating system, and apps shouldn't modify the OS. Simplistic direct
bindings to concrete logging libs tend to force libs, config files, etc.
up into the container lib dirs. However having static binding as a
*base* (ie providing multiple jars that contain classes with the same
names) which supports either simplistic or more dynamic log management
implementations seems to be a good idea.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] commons logging stubs [was Re: [jci] c#]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wed, 2005-11-09 at 12:48 +0100, Torsten Curdt wrote:
> > I also talked about removing the commons-logging dependency (which
> > seemed to be in agreeance at the time),
> > as at least in our environment we don't use it.
>
> The more I think about this the more I get the opinion we should
> also provide a commons-logging-stub.jar to satisfy commons-logging
> dependencies if you don't like to use it.
IMO the fatal flaw with the original JCL design was that the api jar is
not a minimal functional implementation. we could have developed a
solution if only the original design hadn't suffered from this flaw. the
problem with fixing this is backwards compatibility.
i agree with ceki that the future is static (rather than dynamic)
binding. i prefer bytecode engineering to different compilation.
> I know there has been put quite some effort in fixing CL
> but I fear fixing the reputation is a different issue.
a lot of work has certainly been put into analysing JCL. the problems
are know pretty well understood. those willing to spend time reading the
technical documentation and analysis will find there's quite a lot to
gain.
it a lot of the criticisms were ill-informed. there are a number of
valid criticisms about JCL which apply equally to a vast number of other
libraries created around the same time. there are a number of valid
criticism which are consequences of adopting a dynamic binding policy
but they are in the minority.
at least, ceki was willing to back up his criticisms with illustrations
and code. though he most of his examples could be fixed (and were), it
spurred analytic work to classify the problematic use cases which could
not.
> Can a new release of CL rule out all the classloading problems
> people had before?
the consensus is that these problems arise from the combination of
broken specifications, popularity and ignorance amongst users about
classloading issues.
the current code is provably superior to the existing codebase. most of
the difficult use cases are known and good configurations are know for
the vast majority of reasonable use cases. the memory leaks are fixed
for most reasonable configurations. we've made a lot of progress but the
work is hard and very unrewarding. there are also fundamental issues
with various broken J2SE and J2EE standards which cannot be fixed.
whether that's of any use to a standard user is a moot point. JCL is
tasked with coping with many very obscure classloading use cases. by
very careful arrangement of jars, JCL will now with most - but not all -
of these.
IMO is isn't possible to create a library that 'just works right' in
every possible classloading use case without assuming some level of user
knowledge. there's some demonstration code that illustrates this. the
real question is what level of knowledge is reasonable to expect amongst
users.
but the basic problem remains unsolved. i've seen many alternative
proposals which would have fared as bad or worse when faced with the
problems that come with widespread use.
ceki's approach is (on the other hand) very well informed and analysed.
i suspect that given sufficient popularity, it will encounter some of
the issues as JCL (the ones arising from user ignorance and broken
specifications) but has the advantage of being designed with the
knowledge of those difficulties and has a good team working on it.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-12-11 at 13:47 +0100, Dennis Lundberg wrote:
> Dennis Lundberg wrote:
<snip>
> Just a quick follow-up: log4j 1.2.13 has been released so I ran my tests
> on that version as well with the following results:
>
> 2005-12-11 13:32:57,805 FATAL org.apache.commons.logging.Verify -
> Logging at FATAL level.
> 2005-12-11 13:32:57,825 ERROR org.apache.commons.logging.Verify -
> Logging at ERROR level.
> 2005-12-11 13:32:57,825 WARN org.apache.commons.logging.Verify -
> Logging at WARN level.
> 2005-12-11 13:32:57,825 INFO org.apache.commons.logging.Verify -
> Logging at INFO level.
> 2005-12-11 13:32:57,825 DEBUG org.apache.commons.logging.Verify -
> Logging at DEBUG level.
> 2005-12-11 13:32:57,825 TRACE org.apache.commons.logging.Verify -
> Logging at TRACE level.
>
> As you can see all is well also with the official release.
great :)
thanks
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by Dennis Lundberg <de...@mdh.se>.
Dennis Lundberg wrote:
> robert burrell donkin wrote:
>> On Mon, 2005-11-14 at 00:22 +0100, Dennis Lundberg wrote:
>>
>> <snip>
>>
>>> The logging implementation is selected in commons-logging.properties
>>> like this
>>> org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4J12Logger
>>>
>>> or like this
>>> org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4J13Logger
>>>
>>>
>>> Log4j is configured via a log4j.xml file, except for 1.2.6 which only
>>> supports properties file configuration.
>>>
>>> Here are the (disappointing) results:
>>>
>>> 1.2.6: log4j.rootCategory=TRACE
>>> 2005-11-13 23:51:59,444 FATAL org.apache.commons.logging.Verify -
>>> Logging at FATAL level.
>>> 2005-11-13 23:51:59,444 ERROR org.apache.commons.logging.Verify -
>>> Logging at ERROR level.
>>> 2005-11-13 23:51:59,444 WARN org.apache.commons.logging.Verify -
>>> Logging at WARN level.
>>> 2005-11-13 23:51:59,444 INFO org.apache.commons.logging.Verify -
>>> Logging at INFO level.
>>> 2005-11-13 23:51:59,444 DEBUG org.apache.commons.logging.Verify -
>>> Logging at DEBUG level.
>>> 2005-11-13 23:51:59,444 DEBUG org.apache.commons.logging.Verify -
>>> Logging at TRACE level.
>>>
>>> 1.2.12: <level value ="trace" />
>>> 2005-11-14 00:03:03,919 FATAL org.apache.commons.logging.Verify -
>>> Logging at FATAL level.
>>> 2005-11-14 00:03:03,939 ERROR org.apache.commons.logging.Verify -
>>> Logging at ERROR level.
>>> 2005-11-14 00:03:03,939 WARN org.apache.commons.logging.Verify -
>>> Logging at WARN level.
>>> 2005-11-14 00:03:03,939 INFO org.apache.commons.logging.Verify -
>>> Logging at INFO level.
>>> 2005-11-14 00:03:03,939 DEBUG org.apache.commons.logging.Verify -
>>> Logging at DEBUG level.
>>> 2005-11-14 00:03:03,939 DEBUG org.apache.commons.logging.Verify -
>>> Logging at TRACE level.
>>>
>>> 1.2.13rc1: <level value ="trace" />
>>> 2005-11-14 00:08:13,715 FATAL org.apache.commons.logging.Verify -
>>> Logging at FATAL level.
>>> 2005-11-14 00:08:13,715 ERROR org.apache.commons.logging.Verify -
>>> Logging at ERROR level.
>>> 2005-11-14 00:08:13,715 WARN org.apache.commons.logging.Verify -
>>> Logging at WARN level.
>>> 2005-11-14 00:08:13,715 INFO org.apache.commons.logging.Verify -
>>> Logging at INFO level.
>>> 2005-11-14 00:08:13,715 DEBUG org.apache.commons.logging.Verify -
>>> Logging at DEBUG level.
>>> 2005-11-14 00:08:13,715 DEBUG org.apache.commons.logging.Verify -
>>> Logging at TRACE level.
>>>
>>> 1.3alpha-7: <level value ="trace" />
>>> 2005-11-13 23:52:37,669 FATAL org.apache.commons.logging.Verify -
>>> Logging at FATAL level.
>>> 2005-11-13 23:52:37,669 ERROR org.apache.commons.logging.Verify -
>>> Logging at ERROR level.
>>> 2005-11-13 23:52:37,669 WARN org.apache.commons.logging.Verify -
>>> Logging at WARN level.
>>> 2005-11-13 23:52:37,669 INFO org.apache.commons.logging.Verify -
>>> Logging at INFO level.
>>> 2005-11-13 23:52:37,669 DEBUG org.apache.commons.logging.Verify -
>>> Logging at DEBUG level.
>>> 2005-11-13 23:52:37,669 TRACE org.apache.commons.logging.Verify -
>>> Logging at TRACE level.
>>>
>>>
>>> As you can see above, trace level support is *not* working in either
>>> 1.2.12 or 1.2.13rc1. Am I doing something wrong here?
>>
>> i set up a test harness quickly in eclipse and i get something very
>> similar. i think that this issue is caused by buggy reflection: it's
>> safer to use Level.class than Priority.class.
>>
>> could you give the latest code a try?
>
> I've just tried with the latest code. Trace-level logging is now working
> correctly with log4j 1.2.12 and 1.2.13rc1.
Just a quick follow-up: log4j 1.2.13 has been released so I ran my tests
on that version as well with the following results:
2005-12-11 13:32:57,805 FATAL org.apache.commons.logging.Verify -
Logging at FATAL level.
2005-12-11 13:32:57,825 ERROR org.apache.commons.logging.Verify -
Logging at ERROR level.
2005-12-11 13:32:57,825 WARN org.apache.commons.logging.Verify -
Logging at WARN level.
2005-12-11 13:32:57,825 INFO org.apache.commons.logging.Verify -
Logging at INFO level.
2005-12-11 13:32:57,825 DEBUG org.apache.commons.logging.Verify -
Logging at DEBUG level.
2005-12-11 13:32:57,825 TRACE org.apache.commons.logging.Verify -
Logging at TRACE level.
As you can see all is well also with the official release.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by Dennis Lundberg <de...@mdh.se>.
robert burrell donkin wrote:
> On Mon, 2005-11-14 at 00:22 +0100, Dennis Lundberg wrote:
>
> <snip>
>
>> The logging implementation is selected in commons-logging.properties
>> like this
>> org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4J12Logger
>> or like this
>> org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4J13Logger
>>
>> Log4j is configured via a log4j.xml file, except for 1.2.6 which only
>> supports properties file configuration.
>>
>> Here are the (disappointing) results:
>>
>> 1.2.6: log4j.rootCategory=TRACE
>> 2005-11-13 23:51:59,444 FATAL org.apache.commons.logging.Verify -
>> Logging at FATAL level.
>> 2005-11-13 23:51:59,444 ERROR org.apache.commons.logging.Verify -
>> Logging at ERROR level.
>> 2005-11-13 23:51:59,444 WARN org.apache.commons.logging.Verify -
>> Logging at WARN level.
>> 2005-11-13 23:51:59,444 INFO org.apache.commons.logging.Verify -
>> Logging at INFO level.
>> 2005-11-13 23:51:59,444 DEBUG org.apache.commons.logging.Verify -
>> Logging at DEBUG level.
>> 2005-11-13 23:51:59,444 DEBUG org.apache.commons.logging.Verify -
>> Logging at TRACE level.
>>
>> 1.2.12: <level value ="trace" />
>> 2005-11-14 00:03:03,919 FATAL org.apache.commons.logging.Verify -
>> Logging at FATAL level.
>> 2005-11-14 00:03:03,939 ERROR org.apache.commons.logging.Verify -
>> Logging at ERROR level.
>> 2005-11-14 00:03:03,939 WARN org.apache.commons.logging.Verify -
>> Logging at WARN level.
>> 2005-11-14 00:03:03,939 INFO org.apache.commons.logging.Verify -
>> Logging at INFO level.
>> 2005-11-14 00:03:03,939 DEBUG org.apache.commons.logging.Verify -
>> Logging at DEBUG level.
>> 2005-11-14 00:03:03,939 DEBUG org.apache.commons.logging.Verify -
>> Logging at TRACE level.
>>
>> 1.2.13rc1: <level value ="trace" />
>> 2005-11-14 00:08:13,715 FATAL org.apache.commons.logging.Verify -
>> Logging at FATAL level.
>> 2005-11-14 00:08:13,715 ERROR org.apache.commons.logging.Verify -
>> Logging at ERROR level.
>> 2005-11-14 00:08:13,715 WARN org.apache.commons.logging.Verify -
>> Logging at WARN level.
>> 2005-11-14 00:08:13,715 INFO org.apache.commons.logging.Verify -
>> Logging at INFO level.
>> 2005-11-14 00:08:13,715 DEBUG org.apache.commons.logging.Verify -
>> Logging at DEBUG level.
>> 2005-11-14 00:08:13,715 DEBUG org.apache.commons.logging.Verify -
>> Logging at TRACE level.
>>
>> 1.3alpha-7: <level value ="trace" />
>> 2005-11-13 23:52:37,669 FATAL org.apache.commons.logging.Verify -
>> Logging at FATAL level.
>> 2005-11-13 23:52:37,669 ERROR org.apache.commons.logging.Verify -
>> Logging at ERROR level.
>> 2005-11-13 23:52:37,669 WARN org.apache.commons.logging.Verify -
>> Logging at WARN level.
>> 2005-11-13 23:52:37,669 INFO org.apache.commons.logging.Verify -
>> Logging at INFO level.
>> 2005-11-13 23:52:37,669 DEBUG org.apache.commons.logging.Verify -
>> Logging at DEBUG level.
>> 2005-11-13 23:52:37,669 TRACE org.apache.commons.logging.Verify -
>> Logging at TRACE level.
>>
>>
>> As you can see above, trace level support is *not* working in either
>> 1.2.12 or 1.2.13rc1. Am I doing something wrong here?
>
> i set up a test harness quickly in eclipse and i get something very
> similar. i think that this issue is caused by buggy reflection: it's
> safer to use Level.class than Priority.class.
>
> could you give the latest code a try?
I've just tried with the latest code. Trace-level logging is now working
correctly with log4j 1.2.12 and 1.2.13rc1.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2005-11-14 at 00:22 +0100, Dennis Lundberg wrote:
<snip>
> OK. I've set up a verification environment. I have built JCL 1.1-dev
> from SVN at revision 343981. Also I had to build log4j 1.2.13rc1 from
> SVN as I couldn't find a distribution for it.
great :)
thanks
> The logging implementation is selected in commons-logging.properties
> like this
> org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4J12Logger
> or like this
> org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4J13Logger
>
> Log4j is configured via a log4j.xml file, except for 1.2.6 which only
> supports properties file configuration.
>
> Here are the (disappointing) results:
>
> 1.2.6: log4j.rootCategory=TRACE
> 2005-11-13 23:51:59,444 FATAL org.apache.commons.logging.Verify -
> Logging at FATAL level.
> 2005-11-13 23:51:59,444 ERROR org.apache.commons.logging.Verify -
> Logging at ERROR level.
> 2005-11-13 23:51:59,444 WARN org.apache.commons.logging.Verify -
> Logging at WARN level.
> 2005-11-13 23:51:59,444 INFO org.apache.commons.logging.Verify -
> Logging at INFO level.
> 2005-11-13 23:51:59,444 DEBUG org.apache.commons.logging.Verify -
> Logging at DEBUG level.
> 2005-11-13 23:51:59,444 DEBUG org.apache.commons.logging.Verify -
> Logging at TRACE level.
>
> 1.2.12: <level value ="trace" />
> 2005-11-14 00:03:03,919 FATAL org.apache.commons.logging.Verify -
> Logging at FATAL level.
> 2005-11-14 00:03:03,939 ERROR org.apache.commons.logging.Verify -
> Logging at ERROR level.
> 2005-11-14 00:03:03,939 WARN org.apache.commons.logging.Verify -
> Logging at WARN level.
> 2005-11-14 00:03:03,939 INFO org.apache.commons.logging.Verify -
> Logging at INFO level.
> 2005-11-14 00:03:03,939 DEBUG org.apache.commons.logging.Verify -
> Logging at DEBUG level.
> 2005-11-14 00:03:03,939 DEBUG org.apache.commons.logging.Verify -
> Logging at TRACE level.
>
> 1.2.13rc1: <level value ="trace" />
> 2005-11-14 00:08:13,715 FATAL org.apache.commons.logging.Verify -
> Logging at FATAL level.
> 2005-11-14 00:08:13,715 ERROR org.apache.commons.logging.Verify -
> Logging at ERROR level.
> 2005-11-14 00:08:13,715 WARN org.apache.commons.logging.Verify -
> Logging at WARN level.
> 2005-11-14 00:08:13,715 INFO org.apache.commons.logging.Verify -
> Logging at INFO level.
> 2005-11-14 00:08:13,715 DEBUG org.apache.commons.logging.Verify -
> Logging at DEBUG level.
> 2005-11-14 00:08:13,715 DEBUG org.apache.commons.logging.Verify -
> Logging at TRACE level.
>
> 1.3alpha-7: <level value ="trace" />
> 2005-11-13 23:52:37,669 FATAL org.apache.commons.logging.Verify -
> Logging at FATAL level.
> 2005-11-13 23:52:37,669 ERROR org.apache.commons.logging.Verify -
> Logging at ERROR level.
> 2005-11-13 23:52:37,669 WARN org.apache.commons.logging.Verify -
> Logging at WARN level.
> 2005-11-13 23:52:37,669 INFO org.apache.commons.logging.Verify -
> Logging at INFO level.
> 2005-11-13 23:52:37,669 DEBUG org.apache.commons.logging.Verify -
> Logging at DEBUG level.
> 2005-11-13 23:52:37,669 TRACE org.apache.commons.logging.Verify -
> Logging at TRACE level.
>
>
> As you can see above, trace level support is *not* working in either
> 1.2.12 or 1.2.13rc1. Am I doing something wrong here?
i set up a test harness quickly in eclipse and i get something very
similar. i think that this issue is caused by buggy reflection: it's
safer to use Level.class than Priority.class.
could you give the latest code a try?
TIA
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by Dennis Lundberg <de...@mdh.se>.
robert burrell donkin wrote:
> On Sat, 2005-11-12 at 19:24 +0100, Dennis Lundberg wrote:
>> robert burrell donkin wrote:
>>> On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote:
>>>> On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
>>>>> On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
>
> <snip>
>
>>>> * Verify that TRACE support works for log4j's latest releases.
>>> +1
>>>
>>> volunteers?
>> I can help out with this.
>
> great
>
>> Which versions are we talking about here? Here's a rundown of the ones
>> that should be considered:
>>
>> 1.2.6 seems to be what is required for running JCL
>> 1.2.9 is mentioned in build.xml
>> 1.2.12 implements trace support and is the compilation dependency
>> version in project.xml
>> 1.2.13rc1 was tagged three weeks ago and contains fixes related to TRACE
>> level
>> 1.3.0 is only found in build.xml but it has mention of a more specific
>> version. 1.3alpha-7 is the latest tag I found in Log4Js SVN.
>>
>> If it were up to me I'd pick these:
>> 1.2.6 make sure TRACE goes to debug
>> 1.2.12 make sure TRACE goes to trace
>> 1.3alpha-7 make sure TRACE goes to trace
>>
>> What do you think?
>
> that sounds about right but could do with testing the 1.2.13 release
> candidate as well (just in case).
OK. I've set up a verification environment. I have built JCL 1.1-dev
from SVN at revision 343981. Also I had to build log4j 1.2.13rc1 from
SVN as I couldn't find a distribution for it.
The logging implementation is selected in commons-logging.properties
like this
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4J12Logger
or like this
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4J13Logger
Log4j is configured via a log4j.xml file, except for 1.2.6 which only
supports properties file configuration.
Here are the (disappointing) results:
1.2.6: log4j.rootCategory=TRACE
2005-11-13 23:51:59,444 FATAL org.apache.commons.logging.Verify -
Logging at FATAL level.
2005-11-13 23:51:59,444 ERROR org.apache.commons.logging.Verify -
Logging at ERROR level.
2005-11-13 23:51:59,444 WARN org.apache.commons.logging.Verify -
Logging at WARN level.
2005-11-13 23:51:59,444 INFO org.apache.commons.logging.Verify -
Logging at INFO level.
2005-11-13 23:51:59,444 DEBUG org.apache.commons.logging.Verify -
Logging at DEBUG level.
2005-11-13 23:51:59,444 DEBUG org.apache.commons.logging.Verify -
Logging at TRACE level.
1.2.12: <level value ="trace" />
2005-11-14 00:03:03,919 FATAL org.apache.commons.logging.Verify -
Logging at FATAL level.
2005-11-14 00:03:03,939 ERROR org.apache.commons.logging.Verify -
Logging at ERROR level.
2005-11-14 00:03:03,939 WARN org.apache.commons.logging.Verify -
Logging at WARN level.
2005-11-14 00:03:03,939 INFO org.apache.commons.logging.Verify -
Logging at INFO level.
2005-11-14 00:03:03,939 DEBUG org.apache.commons.logging.Verify -
Logging at DEBUG level.
2005-11-14 00:03:03,939 DEBUG org.apache.commons.logging.Verify -
Logging at TRACE level.
1.2.13rc1: <level value ="trace" />
2005-11-14 00:08:13,715 FATAL org.apache.commons.logging.Verify -
Logging at FATAL level.
2005-11-14 00:08:13,715 ERROR org.apache.commons.logging.Verify -
Logging at ERROR level.
2005-11-14 00:08:13,715 WARN org.apache.commons.logging.Verify -
Logging at WARN level.
2005-11-14 00:08:13,715 INFO org.apache.commons.logging.Verify -
Logging at INFO level.
2005-11-14 00:08:13,715 DEBUG org.apache.commons.logging.Verify -
Logging at DEBUG level.
2005-11-14 00:08:13,715 DEBUG org.apache.commons.logging.Verify -
Logging at TRACE level.
1.3alpha-7: <level value ="trace" />
2005-11-13 23:52:37,669 FATAL org.apache.commons.logging.Verify -
Logging at FATAL level.
2005-11-13 23:52:37,669 ERROR org.apache.commons.logging.Verify -
Logging at ERROR level.
2005-11-13 23:52:37,669 WARN org.apache.commons.logging.Verify -
Logging at WARN level.
2005-11-13 23:52:37,669 INFO org.apache.commons.logging.Verify -
Logging at INFO level.
2005-11-13 23:52:37,669 DEBUG org.apache.commons.logging.Verify -
Logging at DEBUG level.
2005-11-13 23:52:37,669 TRACE org.apache.commons.logging.Verify -
Logging at TRACE level.
As you can see above, trace level support is *not* working in either
1.2.12 or 1.2.13rc1. Am I doing something wrong here?
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-11-12 at 19:24 +0100, Dennis Lundberg wrote:
> robert burrell donkin wrote:
> > On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote:
> >> On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
> >>> On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
<snip>
> >> * Sort out whether we split Log4JLogger into two classes or not.
> >
> > yep needs sorting :-/
>
> There is one more thing to consider here. If we choose two classes, how
> should we name them? This has to do with backward compatibility.
+1
> In SVN there are currently two classes named Log4J12Logger.java and
> Log4J13Logger.java. In configuration terms this means that if a user
> that uses a configuration file to select the logging implementation, and
> wants to upgrade from JCL 1.0.4 to the new version, will need to
> change their configuration. How do we feel about this? In my book that
> means that the new version of JCL is not a drop-in replacement for the
> previous version and would warrant it a 1.1 version number. Thoughts?
>
> One idea would be to rename Log4J12Logger.java back to Log4JLogger.java.
> That would make the upgrade transparent for the previous use-case. But
> there is the chance that this will not work at all for a user that is
> currently using JCL 1.0.4 together with log4jalpha-something and a
> configuration file stating that Log4JLogger should be used.
i would much prefer the next release to be fully semantically compatible
(though perhaps we might decide to call it 1.1). however, users who
configure JCL to use Log4JLogger might reasonably expect JCL to guess
the log4j version and use the correct logger. so, perhaps one option
would be to create a delegating implementation.
> > opinions?
>
> I like the idea of two files. A while back I did a quick analysis of
> what changes has been done in Log4J between 1.2 and 1.3. I could not
> find a way to make it work with just one logging implementation file in JCL.
>
> >> * Verify that TRACE support works for log4j's latest releases.
> >
> > +1
> >
> > volunteers?
>
> I can help out with this.
great
> Which versions are we talking about here? Here's a rundown of the ones
> that should be considered:
>
> 1.2.6 seems to be what is required for running JCL
> 1.2.9 is mentioned in build.xml
> 1.2.12 implements trace support and is the compilation dependency
> version in project.xml
> 1.2.13rc1 was tagged three weeks ago and contains fixes related to TRACE
> level
> 1.3.0 is only found in build.xml but it has mention of a more specific
> version. 1.3alpha-7 is the latest tag I found in Log4Js SVN.
>
> If it were up to me I'd pick these:
> 1.2.6 make sure TRACE goes to debug
> 1.2.12 make sure TRACE goes to trace
> 1.3alpha-7 make sure TRACE goes to trace
>
> What do you think?
that sounds about right but could do with testing the 1.2.13 release
candidate as well (just in case).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by Dennis Lundberg <de...@mdh.se>.
robert burrell donkin wrote:
> On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote:
>> On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
>>> On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
>>>
>>> <snip>
>>>
>>>>> Can a new release of CL rule out all the classloading problems
>>>>> people had before?
>>>>
>>>> What's currently in SVN head will probably fix 90% of the problems, and
>>>> is about 99% backwards compatible. I would love to see it released, so
>>>> that the debate could then move on to a "JCL 2.0" which I think is quite
>>>> likely to take the alternative approach described above. Oh for a few
>>>> more hours in the day!
>>> what work's required for a release (above the actual code cutting)?
>> * Remove the ServletCleanupContextListener (this might not be exactly
>> the right class name). It's obviously too controversial. Maybe the code
>> could be put in the documentation somewhere, or on the wiki.
>
> i'm +1 for the class to be distributed. my main concern was about the
> best way to do this sympathetically.
>
> IMHO the real decisions needed are:
>
> 1 our jar distribution strategy (in particular, whether we ship the
> optional jar or not)
>
> 2 how we give downstream packagers and users a fair view of the actual
> JCL dependencies
>
> i'll move these two important and related issues to a separate thread.
>
>> * Decide whether to merge the weak-hash-map stuff into the main trunk or
>> leave it in an "optional" jar. If we merge it, we can do away with the
>> optional jar completely which is good. However it does mean that if
>> there is a bug in it people can't disable it. If bundled in the main jar
>> there might need to be a little extra code to just ignore it when it
>> throws an exception on load for java < 1.3.
>
> this is a tough call :-/
>
> but probably want to add that code in any case
>
> i'm learning towards distributing a more limited number of more easily
> understood standard jars (more on this in the other thread). probably
> need to work through the shape of the distribution first.
>
>> * Sort out whether we split Log4JLogger into two classes or not.
>
> yep needs sorting :-/
There is one more thing to consider here. If we choose two classes, how
should we name them? This has to do with backward compatibility.
In SVN there are currently two classes named Log4J12Logger.java and
Log4J13Logger.java. In configuration terms this means that if a user
that uses a configuration file to select the logging implementation, and
wants to upgrade from JCL 1.0.4 to the new version, will need to
change their configuration. How do we feel about this? In my book that
means that the new version of JCL is not a drop-in replacement for the
previous version and would warrant it a 1.1 version number. Thoughts?
One idea would be to rename Log4J12Logger.java back to Log4JLogger.java.
That would make the upgrade transparent for the previous use-case. But
there is the chance that this will not work at all for a user that is
currently using JCL 1.0.4 together with log4jalpha-something and a
configuration file stating that Log4JLogger should be used.
> opinions?
I like the idea of two files. A while back I did a quick analysis of
what changes has been done in Log4J between 1.2 and 1.3. I could not
find a way to make it work with just one logging implementation file in JCL.
>> * Verify that TRACE support works for log4j's latest releases.
>
> +1
>
> volunteers?
I can help out with this.
Which versions are we talking about here? Here's a rundown of the ones
that should be considered:
1.2.6 seems to be what is required for running JCL
1.2.9 is mentioned in build.xml
1.2.12 implements trace support and is the compilation dependency
version in project.xml
1.2.13rc1 was tagged three weeks ago and contains fixes related to TRACE
level
1.3.0 is only found in build.xml but it has mention of a more specific
version. 1.3alpha-7 is the latest tag I found in Log4Js SVN.
If it were up to me I'd pick these:
1.2.6 make sure TRACE goes to debug
1.2.12 make sure TRACE goes to trace
1.3alpha-7 make sure TRACE goes to trace
What do you think?
>> * Consider Joerg Schaible/Joerg Hohwiller's "getChildLogger" proposal.
>> I'm tempted not to include this, though. Getting a release out is
>> probably the highest priority.
>
> IMHO i need to be certain that everything's exactly right before i'm
> willing to commit it. i was trying to work through the issues and making
> sure i understood them but this went a bit quiet.
>
> either of the two Joerg's around to advocate it's inclusion?
>
> - robert
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[logging] distribution and packaging [WAS Re: [logging] What's
needed for a release]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-11-12 at 13:00 +0000, robert burrell donkin wrote:
> On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote:
> > On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
> > > On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
<snip>
> > > what work's required for a release (above the actual code cutting)?
> >
> > * Remove the ServletCleanupContextListener (this might not be exactly
> > the right class name). It's obviously too controversial. Maybe the code
> > could be put in the documentation somewhere, or on the wiki.
>
> i'm +1 for the class to be distributed. my main concern was about the
> best way to do this sympathetically.
>
> IMHO the real decisions needed are:
>
> 1 our jar distribution strategy (in particular, whether we ship the
> optional jar or not)
>
> 2 how we give downstream packagers and users a fair view of the actual
> JCL dependencies
>
> i'll move these two important and related issues to a separate thread.
and here it is :)
i've had a chance to reflect on this in the months since it was last
discussed. for end users, i'm now inclined to agree that we need to keep
the number of jars short. this should make it easier to explain to users
how they can troubleshoot common problems. i think that the
demonstration code is a good starting point for a troubleshooting guide
similar in tone to the tech guide.
i would like to offer the content in the optional jar but there are
other ways this might be done. for example, we might offer a separate
commons logging extras distribution.
some of my concerns about end users understanding the dependencies can
probably be addressed through documentation. i've added comments to the
maven dependency document and we could add a table explaining the
dependencies to the JCL home page.
what's really needed by downstream packagers is to be able to know the
actual minimal core dependencies for a functional JCL. perhaps we could
address this by documentation and changes to the build script.
opinions welcomed :)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-11-15 at 07:47 +1300, Simon Kitching wrote:
> On Sat, 2005-11-12 at 13:00 +0000, robert burrell donkin wrote:
> > On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote:
> > > On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
> > > > On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
> > > >
> > > > <snip>
> > > >
> > > > > > Can a new release of CL rule out all the classloading problems
> > > > > > people had before?
> > > > >
> > > > >
> > > > > What's currently in SVN head will probably fix 90% of the problems, and
> > > > > is about 99% backwards compatible. I would love to see it released, so
> > > > > that the debate could then move on to a "JCL 2.0" which I think is quite
> > > > > likely to take the alternative approach described above. Oh for a few
> > > > > more hours in the day!
> > > >
> > > > what work's required for a release (above the actual code cutting)?
> > >
> > > * Remove the ServletCleanupContextListener (this might not be exactly
> > > the right class name). It's obviously too controversial. Maybe the code
> > > could be put in the documentation somewhere, or on the wiki.
> >
> > i'm +1 for the class to be distributed. my main concern was about the
> > best way to do this sympathetically.
>
> Well, I'm not too worried about simply removing the servlet class from
> the distribution for now. It's only one class, and not very long, so
> having it in the documentation rather than the actual distribution is ok
> I think.
>
> I would much rather have a release out with this class in the docs than
> spend a lot of time considering generic mechanisms for handling complex
> dependencies. Let's just remove the class for now and debate dependency
> management issues for this sort of issue in the next release cycle...
i wasn't thinking of anything particularly complex.
i've been thinking and my concerns could be addressed by some
documentation and a new build target (for a minimal build from source).
any objections to this plan?
we need to decide about the future of the optional jar. i think i've
come around to the think that users are going to be confused enough just
with the jars that are needed to support various classloader
combinations.
i'd like to keep the code but the current location isn't all that good.
i have a few more ideas (if i ever find the time) for useful (but not
core) functionality. so, one possibility would be to push for a separate
JCL extras/ JCL utilities component. another would be to off-shore the
codebase.
opinions, please :)
this doesn't need to be decided right now: the directory can be parked
somewhere convenient in subversion.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2005-11-12 at 13:00 +0000, robert burrell donkin wrote:
> On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote:
> > On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
> > > On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
> > >
> > > <snip>
> > >
> > > > > Can a new release of CL rule out all the classloading problems
> > > > > people had before?
> > > >
> > > >
> > > > What's currently in SVN head will probably fix 90% of the problems, and
> > > > is about 99% backwards compatible. I would love to see it released, so
> > > > that the debate could then move on to a "JCL 2.0" which I think is quite
> > > > likely to take the alternative approach described above. Oh for a few
> > > > more hours in the day!
> > >
> > > what work's required for a release (above the actual code cutting)?
> >
> > * Remove the ServletCleanupContextListener (this might not be exactly
> > the right class name). It's obviously too controversial. Maybe the code
> > could be put in the documentation somewhere, or on the wiki.
>
> i'm +1 for the class to be distributed. my main concern was about the
> best way to do this sympathetically.
Well, I'm not too worried about simply removing the servlet class from
the distribution for now. It's only one class, and not very long, so
having it in the documentation rather than the actual distribution is ok
I think.
I would much rather have a release out with this class in the docs than
spend a lot of time considering generic mechanisms for handling complex
dependencies. Let's just remove the class for now and debate dependency
management issues for this sort of issue in the next release cycle...
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] What's needed for a release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote:
> On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
> > On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
> >
> > <snip>
> >
> > > > Can a new release of CL rule out all the classloading problems
> > > > people had before?
> > >
> > >
> > > What's currently in SVN head will probably fix 90% of the problems, and
> > > is about 99% backwards compatible. I would love to see it released, so
> > > that the debate could then move on to a "JCL 2.0" which I think is quite
> > > likely to take the alternative approach described above. Oh for a few
> > > more hours in the day!
> >
> > what work's required for a release (above the actual code cutting)?
>
> * Remove the ServletCleanupContextListener (this might not be exactly
> the right class name). It's obviously too controversial. Maybe the code
> could be put in the documentation somewhere, or on the wiki.
i'm +1 for the class to be distributed. my main concern was about the
best way to do this sympathetically.
IMHO the real decisions needed are:
1 our jar distribution strategy (in particular, whether we ship the
optional jar or not)
2 how we give downstream packagers and users a fair view of the actual
JCL dependencies
i'll move these two important and related issues to a separate thread.
> * Decide whether to merge the weak-hash-map stuff into the main trunk or
> leave it in an "optional" jar. If we merge it, we can do away with the
> optional jar completely which is good. However it does mean that if
> there is a bug in it people can't disable it. If bundled in the main jar
> there might need to be a little extra code to just ignore it when it
> throws an exception on load for java < 1.3.
this is a tough call :-/
but probably want to add that code in any case
i'm learning towards distributing a more limited number of more easily
understood standard jars (more on this in the other thread). probably
need to work through the shape of the distribution first.
> * Sort out whether we split Log4JLogger into two classes or not.
yep needs sorting :-/
opinions?
> * Verify that TRACE support works for log4j's latest releases.
+1
volunteers?
> * Consider Joerg Schaible/Joerg Hohwiller's "getChildLogger" proposal.
> I'm tempted not to include this, though. Getting a release out is
> probably the highest priority.
IMHO i need to be certain that everything's exactly right before i'm
willing to commit it. i was trying to work through the issues and making
sure i understood them but this went a bit quiet.
either of the two Joerg's around to advocate it's inclusion?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[logging] What's needed for a release
Posted by Simon Kitching <sk...@apache.org>.
On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
> On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
>
> <snip>
>
> > > Can a new release of CL rule out all the classloading problems
> > > people had before?
> >
> >
> > What's currently in SVN head will probably fix 90% of the problems, and
> > is about 99% backwards compatible. I would love to see it released, so
> > that the debate could then move on to a "JCL 2.0" which I think is quite
> > likely to take the alternative approach described above. Oh for a few
> > more hours in the day!
>
> what work's required for a release (above the actual code cutting)?
* Remove the ServletCleanupContextListener (this might not be exactly
the right class name). It's obviously too controversial. Maybe the code
could be put in the documentation somewhere, or on the wiki.
* Decide whether to merge the weak-hash-map stuff into the main trunk or
leave it in an "optional" jar. If we merge it, we can do away with the
optional jar completely which is good. However it does mean that if
there is a bug in it people can't disable it. If bundled in the main jar
there might need to be a little extra code to just ignore it when it
throws an exception on load for java < 1.3.
* Sort out whether we split Log4JLogger into two classes or not.
* Verify that TRACE support works for log4j's latest releases.
* Consider Joerg Schaible/Joerg Hohwiller's "getChildLogger" proposal.
I'm tempted not to include this, though. Getting a release out is
probably the highest priority.
That's all I'm aware of.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] commons logging stubs [was Re: [jci] c#]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
<snip>
> > Can a new release of CL rule out all the classloading problems
> > people had before?
>
>
> What's currently in SVN head will probably fix 90% of the problems, and
> is about 99% backwards compatible. I would love to see it released, so
> that the debate could then move on to a "JCL 2.0" which I think is quite
> likely to take the alternative approach described above. Oh for a few
> more hours in the day!
what work's required for a release (above the actual code cutting)?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] commons logging stubs [was Re: [jci] c#]
Posted by Simon Kitching <sk...@apache.org>.
On Wed, 2005-11-09 at 12:48 +0100, Torsten Curdt wrote:
> > I also talked about removing the commons-logging dependency (which
> > seemed to be in agreeance at the time),
> > as at least in our environment we don't use it.
>
> The more I think about this the more I get the opinion we should
> also provide a commons-logging-stub.jar to satisfy commons-logging
> dependencies if you don't like to use it.
Well, ***people can always write their own implementation of the
LogFactory and Log APIs***. Apache isn't going to sue anyone for writing
classes with the package scope org.apache.commons.logging. In fact, this
is definitely the most efficient and reliable way to bind code using the
JCL api to an underlying concrete library.
This is pretty much the approach that the slf4j project uses: a separate
jar for each lib provides different underlying implementations of the
same API. Compile-time tricks are used to generate a family of such
implementations for well-known logging libraries, but if you're only
writing a bridge to one library then it's easy enough to do by hand.
This approach does have some limitations, I think, but the nice thing
about such a solution is that it's easy enough to transparently provide
a more sophisticated (container-aware, classpath-scanning, all-dancing)
solution: it's just another implementation of the same API as far as
classes using it are concerned.
There's some thought/experiment still to be done over whether compiler
tricks or bytecode engineering is the best way to generate the various
bridges to well-known implementations. And there's the thorny issue of
backwards compatibility.
But to get back to the original issue: if you don't like the way JCL is
implemented, just write your own implementation of two classes with very
simple APIs and use that instead of the JCL standard jar. Problem
solved. The JCL project is as much an API as an implementation.
> Can a new release of CL rule out all the classloading problems
> people had before?
What's currently in SVN head will probably fix 90% of the problems, and
is about 99% backwards compatible. I would love to see it released, so
that the debate could then move on to a "JCL 2.0" which I think is quite
likely to take the alternative approach described above. Oh for a few
more hours in the day!
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[logging] commons logging stubs [was Re: [jci] c#]
Posted by Torsten Curdt <tc...@apache.org>.
> I also talked about removing the commons-logging dependency (which
> seemed to be in agreeance at the time),
> as at least in our environment we don't use it.
The more I think about this the more I get the opinion we should
also provide a commons-logging-stub.jar to satisfy commons-logging
dependencies if you don't like to use it.
I know there has been put quite some effort in fixing CL
but I fear fixing the reputation is a different issue.
Can a new release of CL rule out all the classloading problems
people had before?
cheers
--
Torsten
Re: [jci] c#
Posted by Brett Porter <br...@apache.org>.
Guys,
Some time back (and I'm still trying to get around to it), I talked
about merging plexus-compiler with JCI.
plexus-compiler has a basic c# interface (as well as eclipse, javac, jikes).
I also talked about removing the commons-logging dependency (which
seemed to be in agreeance at the time), as at least in our environment
we don't use it.
I'm able to help anyone that wants to work on this effort - which would
avoid duplicating the work.
Cheers,
Brett
Mark Proctor wrote:
> Chinmay Nagarkar is going to donate a c# interface to Drools -
> http://www.blogger.com/comment.g?blogID=17469068&postID=112848674485482389
>
> I've been requesting he make this work with JCI via IKVM. If this is
> possible, with some hard work I believe it could be, we might want to
> change JavaCompiler to GciCompiler so its not generic to java - just a
> thought.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jci] c#
Posted by Mark Proctor <li...@markproctor.com>.
Chinmay Nagarkar is going to donate a c# interface to Drools -
http://www.blogger.com/comment.g?blogID=17469068&postID=112848674485482389
I've been requesting he make this work with JCI via IKVM. If this is
possible, with some hard work I believe it could be, we might want to
change JavaCompiler to GciCompiler so its not generic to java - just a
thought.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jci] commons-logging use Was: patches
Posted by Torsten Curdt <tc...@apache.org>.
>> I really dislike the idea of a fork at this stage.
>
> Agreed. I'm trying to bring back a fork, so let's not make a third :)
:-)
>> As of the event model - it just feels a bit like
>> re-inventing commons-logging.
>
> I don't agree (this is why I've posted here, not under a [logging]
> thread - I don't think this is about the relative merits of c-l).
>
> I think the compiler API warrants its own event listening
> interface. Sure, the compiler outputs info warning and error
> messages, but these are from the compiler and not the compiler API
> which also has its info warning and error (and debug) logging
> messages. And I think the API has some richer events - like when it
> starts processing a certain file, for example.
That's true. It does make sense to integrate something like that.
(The ProblemHandler goes already in such a direction)
...but that does not cover the logging for jci itself.
We could remove the logging completely but I don't really
like the idea as it makes debugging more complicated.
Especially for the FAM it's sometimes really useful to see
what's going on under the hood.
> Note that we don't use c-l in Maven because Maven's classloader is
> shared with the plugins and that was often a problem in Maven 1.x
> (which did use c-l and log4j). Now while that doesn't mean the
> compiler plugin can't use it via jci, it would be nicer to
> implement the above jci event interface and log them using the
> native Maven logging.
Sure, but IMO this is a separate thing.
cheers
--
Torsten
Re: [jci] commons-logging use Was: patches
Posted by Brett Porter <br...@apache.org>.
Torsten Curdt wrote:
> I really dislike the idea of a fork at this stage.
Agreed. I'm trying to bring back a fork, so let's not make a third :)
> As of the event model - it just feels a bit like
> re-inventing commons-logging.
I don't agree (this is why I've posted here, not under a [logging]
thread - I don't think this is about the relative merits of c-l).
I think the compiler API warrants its own event listening interface.
Sure, the compiler outputs info warning and error messages, but these
are from the compiler and not the compiler API which also has its info
warning and error (and debug) logging messages. And I think the API has
some richer events - like when it starts processing a certain file, for
example.
Note that we don't use c-l in Maven because Maven's classloader is
shared with the plugins and that was often a problem in Maven 1.x (which
did use c-l and log4j). Now while that doesn't mean the compiler plugin
can't use it via jci, it would be nicer to implement the above jci event
interface and log them using the native Maven logging.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jci] patches
Posted by Torsten Curdt <tc...@apache.org>.
> http://issues.apache.org/bugzilla/show_bug.cgi?id=37394 Groovy no
> longer allows null CompilerConfiguration
>
> I'm also just writting a simple CompilerFactory class.
Cool!
> Once that is done I'll weigh up either ripping jci
> into the Drools tree sans common-logging requirement or build an
> event model instead.
We should work something out ...unfortunately I have
been a little busy the past few weeks. So not much
progress here. The bytecode removal seems to be a
bit tricky as it's not really clear where the logging
part starts and where it stops. Probably possible
but tricky.
I really dislike the idea of a fork at this stage.
As of the event model - it just feels a bit like
re-inventing commons-logging.
Couldn't you rather mock the commons-logging API?
That way everything is fine as it is and IF someone
wants to plug in some logging he just have to replace
the mocks with the real commons-logging.
cheers
--
Torsten