[jci] patches

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[jci] patches

Mark Proctor-4
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
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [jci] patches

Torsten Curdt
> 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

PGP.sig (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[jci] c#

Mark Proctor-4
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jci] c#

Brett Porter-2
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jci] c#

Torsten Curdt
> 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


PGP.sig (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[logging] commons logging stubs [was Re: [jci] c#]

Torsten Curdt
In reply to this post by Brett Porter-2
> 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

PGP.sig (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [logging] commons logging stubs [was Re: [jci] c#]

Mark Proctor-4
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] commons logging stubs [was Re: [jci] c#]

robert burrell donkin
In reply to this post by Torsten Curdt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] commons logging stubs [was Re: [jci] c#]

robert burrell donkin
In reply to this post by Mark Proctor-4
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jci] c#

Brett Porter-2
In reply to this post by Torsten Curdt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jci] commons-logging use Was: patches

Brett Porter-2
In reply to this post by Torsten Curdt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jci] c#

Mark Proctor-4
In reply to this post by Brett Porter-2
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jci] c#

Brett Porter-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jci] c#

Mark Proctor-4
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jci] commons-logging use Was: patches

Torsten Curdt
In reply to this post by Brett Porter-2
>> 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

PGP.sig (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [jci] c#

Torsten Curdt
In reply to this post by Brett Porter-2
> 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 :)


PGP.sig (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [logging] commons logging stubs [was Re: [jci] c#]

Simon Kitching
In reply to this post by Torsten Curdt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] commons logging stubs [was Re: [jci] c#]

Simon Kitching
In reply to this post by robert burrell donkin
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] commons logging stubs [was Re: [jci] c#]

robert burrell donkin
In reply to this post by Simon Kitching
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[logging] What's needed for a release

Simon Kitching
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: [hidden email]
For additional commands, e-mail: [hidden email]

12