[VOTE] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

All,
 
Outside projects (currently my Syringe project and the "Crispy" project at
sourceforge) are beginning to want to use Commons Proxy, but are finding it
difficult since it's in the sandbox and no releases are available.  I
believe Proxy's API is close to being ready for a release candidate.
Currently, I don't have any other bright ideas for it, but I'm open to
suggestions.  Moving it to the proper will help us prepare it for an
official release.
 
I'm +1
 
----- Cut Here -----
I vote as follows on moving Proxy to the Commons Proper:
[ ] +1 - I support this move and am willing to help
[ ] +0 - I support this move, but cannot assist
[ ] -0 - I don't support this move
[ ] -1 - I vote against this move (requires valid *technical*
         reasoning)
----- Cut Here -----

 

James

RE: [VOTE] Moving Proxy to Commons Proper

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Sat, 2005-10-15 at 07:33 -0400, James Carman wrote:
> Robert,

hi james

> Thank you for your feedback (finally somebody said *something*).  I made
> this a vote based on the instructions found at
> http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN.  Maybe
> we should update that WIKI to suggest making a proposal first and then
> starting a vote if there are no objections.  

feel free to change the wiki: people can revert or modify anything they
don't like. 

> I really just wanted to know if
> there were any technical objections to having proxy move into the commons
> proper so that I could fix the problems.  I would really like to see this
> become a full-fledged commons component.  I think it's a very useful idea
> and a pretty intuitive API.

no criticism intended: it's just that VOTE threads tend to get a bit
messy if people pick up on the issues too late. it's a bit of a
judgement call and PROPOSAL's aren't always necessary. 

> As for your suggestion to cut a release candidate now, I like it.  I do
> think that I need some simple tutorials/examples on the site before it's
> ready for a real release, so I'll try to take care of that sometime soon.
> Then, I'll cut a release candidate, per your suggestion.  I will try to
> follow the directions found at
> http://jakarta.apache.org/commons/releases/prepare.html to prepare the
> release candidate, but I'm probably bound to make mistakes as I'm new to
> this project management stuff.  I'll probably have a few questions along the
> way too! 

that's why creating a sample release candidate is a good idea. the notes
have been developed over many years and are pretty comprehensive now. i
hope you'll continue the tradition of improving the documentation as you
learn how to cut a commons release. 

> Also, I would still like to hear if anyone else has any suggestions for
> things that I need to take care of before they would consider it ready for
> release.  Resolving the 1.5 dependency helped of course, even if it did make
> the API a lot uglier IMHO.  I liked the var-args feature for specifying the
> interfaces/classes that the proxy should support and I would rather use the
> core JDK Executor class rather than the one from the "concurrent" API.  Oh
> well.

folks have picked this up on the other thread

- robert


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

RE: [proxy] Moving Proxy to Commons Proper

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Thu, 2005-10-20 at 06:50 -0400, James Carman wrote:
> What would an abstract class buy us?  Suppose ProxyFactory were an abstract
> class.  In the initial release, it would have some abstract methods to be
> overridden in the subclasses.  Then, I might have some users who decide (for
> some crazy reason) to extend ProxyFactory on their own.  They implement the
> abstract methods and all is good.  Now, suppose that I need to add a method
> to ProxyFactory in the future.  The added method can't be abstract or else
> it would break the binary compatibility.  Therefore, we'd have to provide an
> implementation of the new method.  We'd have a choice here.  We could throw
> an UnsupportedOperationException which would make the method unusable, but
> maintain binary compatibility.  Or, we could provide a default
> implementation which would probably have to be reflection-based anyway to
> avoid unnecessary required dependencies.  I don't really like adding
> unusable methods to my abstract class, so I would rather provide the default
> implementation.  Thus, any new methods would be reflection based.  Why don't
> we just make the base class reflection based in the first place?  

there are no really good solutions to this problem. (or, if there are, i
don't know about them ;) experience has proved though that it's best to
think about it sooner rather than later.

reflection is slow and has wrinkles in some environments and containers.
it's best avoided as a solution.

creating new (logical) interfaces would be an alternative way of
preserving binary compatibility. in some cases, it makes more sense to
create a new interface than add a method to an existing one especially
when semantic compatibility would be broken. the design of proxy
probably makes this a credible strategy. 

> Again, I'm new to this whole "maintaining binary compatibility" thing,
> because thus far I have mostly worked on projects where I control the source
> for the clients of the code that I write.  So, I can go back and fix what I
> broke!  :-)  So, how do you guys usually go about this?  Do you provide the
> default implementation in the base class or throw an exception?

that depends:

the best case (and one that happens a lot) is that the need develops for
optional parameters which were not foreseen when the API was designed.
in this case, it's natural to add a new concrete method that delegates
to the original version. for this case, using an abstract class allows
semantic and binary compatibility to be preserved. using an interface
would mean breaking binary compatibility.

cases requiring the breaking of semantic incompatibility are tougher.
here, novel capabilities which were not foreseen when the API was design
require the addition of new methods. existing implementations may well
be broken by this change whether binary compatibility is preserved or
not. 

it is usually best not to include default implementations in a logical
interface. so, that means creating an empty implementations. indicating
a base implementation containing reasonable defaults (rather than the
abstract class) that implementors are recommended to subclass (so they
can protect themselves against this) is probably a good idea.

there definitely comes a time when it's better to cut your losses and
break compatibility but using an abstract class to model a logical
interface allows this call to be made on a case-by-case basis.

- robert


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

RE: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

What would an abstract class buy us?  Suppose ProxyFactory were an abstract
class.  In the initial release, it would have some abstract methods to be
overridden in the subclasses.  Then, I might have some users who decide (for
some crazy reason) to extend ProxyFactory on their own.  They implement the
abstract methods and all is good.  Now, suppose that I need to add a method
to ProxyFactory in the future.  The added method can't be abstract or else
it would break the binary compatibility.  Therefore, we'd have to provide an
implementation of the new method.  We'd have a choice here.  We could throw
an UnsupportedOperationException which would make the method unusable, but
maintain binary compatibility.  Or, we could provide a default
implementation which would probably have to be reflection-based anyway to
avoid unnecessary required dependencies.  I don't really like adding
unusable methods to my abstract class, so I would rather provide the default
implementation.  Thus, any new methods would be reflection based.  Why don't
we just make the base class reflection based in the first place?  

Again, I'm new to this whole "maintaining binary compatibility" thing,
because thus far I have mostly worked on projects where I control the source
for the clients of the code that I write.  So, I can go back and fix what I
broke!  :-)  So, how do you guys usually go about this?  Do you provide the
default implementation in the base class or throw an exception?

The JDK must introduce problems with binary compatibility all the time.  One
example I can think of is the JDBC API, which is almost entirely
interface-based.  They add methods to that API somewhat frequently (the 1.4
release has new methods in ResultSet I know), it seems.  How do JDBC driver
vendors avoid that?  Do they have to release new versions of the drivers
that implement the new versions of the interfaces?  I would guess they have
to; I've just never run into a problem.

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
Sent: Thursday, October 20, 2005 5:32 AM
To: Jakarta Commons Developers List
Subject: RE: [proxy] Moving Proxy to Commons Proper

Why can ProxyFactory not be an abstract class?

Stephen

--- James Carman <ja...@carmanconsulting.com> wrote:

> Robert,
> 
> How about this?  We provide a "default"
> implementation which just uses JDK
> proxies.  So, ReflectionProxyFactory would become
> ProxyFactory and
> JavassistProxyFactory and CglibProxyFactory would
> just extend/override it.
> That way, if we do add a method to ProxyFactory, the
> subclasses don't
> necessarily have to override it.  The
> implementations would just use
> reflection rather than a more advanced proxying
> technique.  ProxyFactory
> would actually be concrete and not abstract in that
> case.  Does that sound
> like it would work better?  Would that address your
> concerns with the binary
> compatibility?  
> 
> James
> 
> -----Original Message-----
> From: robert burrell donkin
> [mailto:robertburrelldonkin@blueyonder.co.uk] 
> Sent: Wednesday, October 19, 2005 6:18 PM
> To: Jakarta Commons Developers List
> Subject: Re: [proxy] Moving Proxy to Commons Proper
> 
> On Wed, 2005-10-19 at 16:35 +0200, Knut Wannheden
> wrote:
> > On 10/19/05, James Carman
> <ja...@carmanconsulting.com> wrote:
> > > > i would also like to reiterate stephen's
> warning: if you use
> interfaces,
> > > > be very sure that you are not going to need to
> change them in any
> > > > fashion. i would very strongly suggest
> implementing the key
> > > > ProxyFactory logical interface as an abstract
> class. this isn't bias
> (i
> > > > love interfaces when coding applications) but
> a hard lesson painfully
> > > > learnt.
> > >
> > > Robert,
> > >
> > > I understand the concerns here, but I am really
> torn between changing
> the
> > > API and leaving it like it is.  IMHO, it is
> *very* unlikely that a user
> of
> > > Commons Proxy is even going to implement
> ProxyFactory on their own.  If
> I
> > > had to ballpark it, I would be surprised if 1
> out of every 100 (I might
> even
> > > go 1000) people who use Commons Proxy implement
> ProxyFactory.  That's
> the
> > > whole point of using Commons Proxy in the first
> place.  You don't have
> to
> > > write the proxying logic yourself!  So, what is
> our target here?  Are we
> > > looking for 100% backward compatibility with
> *all* projects?  Or, are we
> > > happy with keeping something more like 90% or
> 95% of our users happy?
> Maybe
> > > we could tell them in the documentation that if
> they have a proxying
> > > technology that they wish Commons Proxy
> supported that they can submit a
> > > request to the mailing list or into Bugzilla for
> it and we can take care
> of
> > > it (of course, any code that gets us going would
> help).  As long as we
> > > decide between AOP Alliance vs. "rolling our
> own" interfaces, I'm pretty
> > > happy with the ProxyFactory interface.  Besides,
> there's really nothing
> you
> > > can't do with Invokers.  That's sort of the
> "common denominator."
> > >
> > 
> > In Eclipse APIs it is common practice that
> interfaces are never
> > changed -- hence new interfaces have to be added
> when new changes are
> > required -- and abstract classes are used where
> changes (in form of
> > new methods) are expected (see
> >
>
http://www.artima.com/lejava/articles/designprinciples.html).
> > 
> > As you say the Invokers are the "common
> denominator". So ProxyFactory
> > could be implemented as an abstract base class
> with the
> > createInvokerProxy() method declared as abstract
> and the other proxy
> > factory methods defined in terms of that. Concrete
> implementaions
> > would although do best in overriding these other
> methods for
> > performance reasons.
> > 
> > Although, as you say, there are probably not many
> users who will want
> > to implement this interface anyways. So maybe it's
> best left as it is.
> > 
> > I'm torn on this one. Any other thoughs?
> 
> there are certain pitfalls associated with deep
> libraries that are not
> commonly found elsewhere and are therefore not
> generally well known
> amongst other communities. (by deep libraries, i
> mean libraries that are
> used by libraries rather than applications.) these
> issues don't really
> effect applications or frameworks. 
> 
> we often talk about two different forms of
> compatibility: semantic and
> binary. binary compatibility is defined by the java
> language and
> concerns when one version of a class can be
> substitute for another.
> semantic compatibility means that existing uses
> don't break when one
> version of a class is substituted for another.
> 
> when developing a deep library, compatibility is big
> issue. since the
> library will be used by many other libraries and so
> indirectly by many,
> many applications, breaking compatibility means
> disrupting many users
> who were not aware that they even used your library.
> this will make you
> very personally unpopular. due to the number of end
> users who may be
> effected by changes in semantics, breaking semantic
> compatibility is
> quite a big deal. so, it's usually better to choose
> delegation and
> logical interfaces over subclassing frameworks.
> 
> breaking binary compatibility is a very big deal for
> deep libraries. by
> breaking binary compatibility, all users must be
> forced to choose to
> have only one version of the library on the
> classpath. if a user is
> building an application and require two libraries
> each of which depends
> on a different version of your library, this will
> cause them great pain
> resulting in great anger. 
> 
> the problem with interfaces is that adding methods
> breaks binary
> compatibility. 
> 
> some of the commmons components are amazingly widely
> distributed. proxy
> is just starting out but in a year or two, maybe
> it'll be relied upon by
> hundreds of open source libraries (as several of the
> deep commons
> libraries are). now, imagine having to justify
> yourself to all those
> downstream users who use those libraries why you
> needed to break binary
> compatibility: this kind of thing really trashes
> your reputation and the
> reputation of your component as well as upsetting
> all those downstream
> users who'd never even heard of your library before.
> 
> but, this choice is yours. this is just advice and
> not a condition :)
> 
> - robert
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 
=== message truncated ===


---------------------------------------------------------------------
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: [proxy] Moving Proxy to Commons Proper

[Stephen Colebourne <sc...@btopenworld.com>]

Why can ProxyFactory not be an abstract class?

Stephen

--- James Carman <ja...@carmanconsulting.com> wrote:

> Robert,
> 
> How about this?  We provide a "default"
> implementation which just uses JDK
> proxies.  So, ReflectionProxyFactory would become
> ProxyFactory and
> JavassistProxyFactory and CglibProxyFactory would
> just extend/override it.
> That way, if we do add a method to ProxyFactory, the
> subclasses don't
> necessarily have to override it.  The
> implementations would just use
> reflection rather than a more advanced proxying
> technique.  ProxyFactory
> would actually be concrete and not abstract in that
> case.  Does that sound
> like it would work better?  Would that address your
> concerns with the binary
> compatibility?  
> 
> James
> 
> -----Original Message-----
> From: robert burrell donkin
> [mailto:robertburrelldonkin@blueyonder.co.uk] 
> Sent: Wednesday, October 19, 2005 6:18 PM
> To: Jakarta Commons Developers List
> Subject: Re: [proxy] Moving Proxy to Commons Proper
> 
> On Wed, 2005-10-19 at 16:35 +0200, Knut Wannheden
> wrote:
> > On 10/19/05, James Carman
> <ja...@carmanconsulting.com> wrote:
> > > > i would also like to reiterate stephen's
> warning: if you use
> interfaces,
> > > > be very sure that you are not going to need to
> change them in any
> > > > fashion. i would very strongly suggest
> implementing the key
> > > > ProxyFactory logical interface as an abstract
> class. this isn't bias
> (i
> > > > love interfaces when coding applications) but
> a hard lesson painfully
> > > > learnt.
> > >
> > > Robert,
> > >
> > > I understand the concerns here, but I am really
> torn between changing
> the
> > > API and leaving it like it is.  IMHO, it is
> *very* unlikely that a user
> of
> > > Commons Proxy is even going to implement
> ProxyFactory on their own.  If
> I
> > > had to ballpark it, I would be surprised if 1
> out of every 100 (I might
> even
> > > go 1000) people who use Commons Proxy implement
> ProxyFactory.  That's
> the
> > > whole point of using Commons Proxy in the first
> place.  You don't have
> to
> > > write the proxying logic yourself!  So, what is
> our target here?  Are we
> > > looking for 100% backward compatibility with
> *all* projects?  Or, are we
> > > happy with keeping something more like 90% or
> 95% of our users happy?
> Maybe
> > > we could tell them in the documentation that if
> they have a proxying
> > > technology that they wish Commons Proxy
> supported that they can submit a
> > > request to the mailing list or into Bugzilla for
> it and we can take care
> of
> > > it (of course, any code that gets us going would
> help).  As long as we
> > > decide between AOP Alliance vs. "rolling our
> own" interfaces, I'm pretty
> > > happy with the ProxyFactory interface.  Besides,
> there's really nothing
> you
> > > can't do with Invokers.  That's sort of the
> "common denominator."
> > >
> > 
> > In Eclipse APIs it is common practice that
> interfaces are never
> > changed -- hence new interfaces have to be added
> when new changes are
> > required -- and abstract classes are used where
> changes (in form of
> > new methods) are expected (see
> >
>
http://www.artima.com/lejava/articles/designprinciples.html).
> > 
> > As you say the Invokers are the "common
> denominator". So ProxyFactory
> > could be implemented as an abstract base class
> with the
> > createInvokerProxy() method declared as abstract
> and the other proxy
> > factory methods defined in terms of that. Concrete
> implementaions
> > would although do best in overriding these other
> methods for
> > performance reasons.
> > 
> > Although, as you say, there are probably not many
> users who will want
> > to implement this interface anyways. So maybe it's
> best left as it is.
> > 
> > I'm torn on this one. Any other thoughs?
> 
> there are certain pitfalls associated with deep
> libraries that are not
> commonly found elsewhere and are therefore not
> generally well known
> amongst other communities. (by deep libraries, i
> mean libraries that are
> used by libraries rather than applications.) these
> issues don't really
> effect applications or frameworks. 
> 
> we often talk about two different forms of
> compatibility: semantic and
> binary. binary compatibility is defined by the java
> language and
> concerns when one version of a class can be
> substitute for another.
> semantic compatibility means that existing uses
> don't break when one
> version of a class is substituted for another.
> 
> when developing a deep library, compatibility is big
> issue. since the
> library will be used by many other libraries and so
> indirectly by many,
> many applications, breaking compatibility means
> disrupting many users
> who were not aware that they even used your library.
> this will make you
> very personally unpopular. due to the number of end
> users who may be
> effected by changes in semantics, breaking semantic
> compatibility is
> quite a big deal. so, it's usually better to choose
> delegation and
> logical interfaces over subclassing frameworks.
> 
> breaking binary compatibility is a very big deal for
> deep libraries. by
> breaking binary compatibility, all users must be
> forced to choose to
> have only one version of the library on the
> classpath. if a user is
> building an application and require two libraries
> each of which depends
> on a different version of your library, this will
> cause them great pain
> resulting in great anger. 
> 
> the problem with interfaces is that adding methods
> breaks binary
> compatibility. 
> 
> some of the commmons components are amazingly widely
> distributed. proxy
> is just starting out but in a year or two, maybe
> it'll be relied upon by
> hundreds of open source libraries (as several of the
> deep commons
> libraries are). now, imagine having to justify
> yourself to all those
> downstream users who use those libraries why you
> needed to break binary
> compatibility: this kind of thing really trashes
> your reputation and the
> reputation of your component as well as upsetting
> all those downstream
> users who'd never even heard of your library before.
> 
> but, this choice is yours. this is just advice and
> not a condition :)
> 
> - robert
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 
=== message truncated ===


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

RE: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

Robert,

How about this?  We provide a "default" implementation which just uses JDK
proxies.  So, ReflectionProxyFactory would become ProxyFactory and
JavassistProxyFactory and CglibProxyFactory would just extend/override it.
That way, if we do add a method to ProxyFactory, the subclasses don't
necessarily have to override it.  The implementations would just use
reflection rather than a more advanced proxying technique.  ProxyFactory
would actually be concrete and not abstract in that case.  Does that sound
like it would work better?  Would that address your concerns with the binary
compatibility?  

James

-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk] 
Sent: Wednesday, October 19, 2005 6:18 PM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Moving Proxy to Commons Proper

On Wed, 2005-10-19 at 16:35 +0200, Knut Wannheden wrote:
> On 10/19/05, James Carman <ja...@carmanconsulting.com> wrote:
> > > i would also like to reiterate stephen's warning: if you use
interfaces,
> > > be very sure that you are not going to need to change them in any
> > > fashion. i would very strongly suggest implementing the key
> > > ProxyFactory logical interface as an abstract class. this isn't bias
(i
> > > love interfaces when coding applications) but a hard lesson painfully
> > > learnt.
> >
> > Robert,
> >
> > I understand the concerns here, but I am really torn between changing
the
> > API and leaving it like it is.  IMHO, it is *very* unlikely that a user
of
> > Commons Proxy is even going to implement ProxyFactory on their own.  If
I
> > had to ballpark it, I would be surprised if 1 out of every 100 (I might
even
> > go 1000) people who use Commons Proxy implement ProxyFactory.  That's
the
> > whole point of using Commons Proxy in the first place.  You don't have
to
> > write the proxying logic yourself!  So, what is our target here?  Are we
> > looking for 100% backward compatibility with *all* projects?  Or, are we
> > happy with keeping something more like 90% or 95% of our users happy?
Maybe
> > we could tell them in the documentation that if they have a proxying
> > technology that they wish Commons Proxy supported that they can submit a
> > request to the mailing list or into Bugzilla for it and we can take care
of
> > it (of course, any code that gets us going would help).  As long as we
> > decide between AOP Alliance vs. "rolling our own" interfaces, I'm pretty
> > happy with the ProxyFactory interface.  Besides, there's really nothing
you
> > can't do with Invokers.  That's sort of the "common denominator."
> >
> 
> In Eclipse APIs it is common practice that interfaces are never
> changed -- hence new interfaces have to be added when new changes are
> required -- and abstract classes are used where changes (in form of
> new methods) are expected (see
> http://www.artima.com/lejava/articles/designprinciples.html).
> 
> As you say the Invokers are the "common denominator". So ProxyFactory
> could be implemented as an abstract base class with the
> createInvokerProxy() method declared as abstract and the other proxy
> factory methods defined in terms of that. Concrete implementaions
> would although do best in overriding these other methods for
> performance reasons.
> 
> Although, as you say, there are probably not many users who will want
> to implement this interface anyways. So maybe it's best left as it is.
> 
> I'm torn on this one. Any other thoughs?

there are certain pitfalls associated with deep libraries that are not
commonly found elsewhere and are therefore not generally well known
amongst other communities. (by deep libraries, i mean libraries that are
used by libraries rather than applications.) these issues don't really
effect applications or frameworks. 

we often talk about two different forms of compatibility: semantic and
binary. binary compatibility is defined by the java language and
concerns when one version of a class can be substitute for another.
semantic compatibility means that existing uses don't break when one
version of a class is substituted for another.

when developing a deep library, compatibility is big issue. since the
library will be used by many other libraries and so indirectly by many,
many applications, breaking compatibility means disrupting many users
who were not aware that they even used your library. this will make you
very personally unpopular. due to the number of end users who may be
effected by changes in semantics, breaking semantic compatibility is
quite a big deal. so, it's usually better to choose delegation and
logical interfaces over subclassing frameworks.

breaking binary compatibility is a very big deal for deep libraries. by
breaking binary compatibility, all users must be forced to choose to
have only one version of the library on the classpath. if a user is
building an application and require two libraries each of which depends
on a different version of your library, this will cause them great pain
resulting in great anger. 

the problem with interfaces is that adding methods breaks binary
compatibility. 

some of the commmons components are amazingly widely distributed. proxy
is just starting out but in a year or two, maybe it'll be relied upon by
hundreds of open source libraries (as several of the deep commons
libraries are). now, imagine having to justify yourself to all those
downstream users who use those libraries why you needed to break binary
compatibility: this kind of thing really trashes your reputation and the
reputation of your component as well as upsetting all those downstream
users who'd never even heard of your library before.

but, this choice is yours. this is just advice and not a condition :)

- robert


---------------------------------------------------------------------
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: [proxy] Moving Proxy to Commons Proper

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Wed, 2005-10-19 at 16:35 +0200, Knut Wannheden wrote:
> On 10/19/05, James Carman <ja...@carmanconsulting.com> wrote:
> > > i would also like to reiterate stephen's warning: if you use interfaces,
> > > be very sure that you are not going to need to change them in any
> > > fashion. i would very strongly suggest implementing the key
> > > ProxyFactory logical interface as an abstract class. this isn't bias (i
> > > love interfaces when coding applications) but a hard lesson painfully
> > > learnt.
> >
> > Robert,
> >
> > I understand the concerns here, but I am really torn between changing the
> > API and leaving it like it is.  IMHO, it is *very* unlikely that a user of
> > Commons Proxy is even going to implement ProxyFactory on their own.  If I
> > had to ballpark it, I would be surprised if 1 out of every 100 (I might even
> > go 1000) people who use Commons Proxy implement ProxyFactory.  That's the
> > whole point of using Commons Proxy in the first place.  You don't have to
> > write the proxying logic yourself!  So, what is our target here?  Are we
> > looking for 100% backward compatibility with *all* projects?  Or, are we
> > happy with keeping something more like 90% or 95% of our users happy?  Maybe
> > we could tell them in the documentation that if they have a proxying
> > technology that they wish Commons Proxy supported that they can submit a
> > request to the mailing list or into Bugzilla for it and we can take care of
> > it (of course, any code that gets us going would help).  As long as we
> > decide between AOP Alliance vs. "rolling our own" interfaces, I'm pretty
> > happy with the ProxyFactory interface.  Besides, there's really nothing you
> > can't do with Invokers.  That's sort of the "common denominator."
> >
> 
> In Eclipse APIs it is common practice that interfaces are never
> changed -- hence new interfaces have to be added when new changes are
> required -- and abstract classes are used where changes (in form of
> new methods) are expected (see
> http://www.artima.com/lejava/articles/designprinciples.html).
> 
> As you say the Invokers are the "common denominator". So ProxyFactory
> could be implemented as an abstract base class with the
> createInvokerProxy() method declared as abstract and the other proxy
> factory methods defined in terms of that. Concrete implementaions
> would although do best in overriding these other methods for
> performance reasons.
> 
> Although, as you say, there are probably not many users who will want
> to implement this interface anyways. So maybe it's best left as it is.
> 
> I'm torn on this one. Any other thoughs?

there are certain pitfalls associated with deep libraries that are not
commonly found elsewhere and are therefore not generally well known
amongst other communities. (by deep libraries, i mean libraries that are
used by libraries rather than applications.) these issues don't really
effect applications or frameworks. 

we often talk about two different forms of compatibility: semantic and
binary. binary compatibility is defined by the java language and
concerns when one version of a class can be substitute for another.
semantic compatibility means that existing uses don't break when one
version of a class is substituted for another.

when developing a deep library, compatibility is big issue. since the
library will be used by many other libraries and so indirectly by many,
many applications, breaking compatibility means disrupting many users
who were not aware that they even used your library. this will make you
very personally unpopular. due to the number of end users who may be
effected by changes in semantics, breaking semantic compatibility is
quite a big deal. so, it's usually better to choose delegation and
logical interfaces over subclassing frameworks.

breaking binary compatibility is a very big deal for deep libraries. by
breaking binary compatibility, all users must be forced to choose to
have only one version of the library on the classpath. if a user is
building an application and require two libraries each of which depends
on a different version of your library, this will cause them great pain
resulting in great anger. 

the problem with interfaces is that adding methods breaks binary
compatibility. 

some of the commmons components are amazingly widely distributed. proxy
is just starting out but in a year or two, maybe it'll be relied upon by
hundreds of open source libraries (as several of the deep commons
libraries are). now, imagine having to justify yourself to all those
downstream users who use those libraries why you needed to break binary
compatibility: this kind of thing really trashes your reputation and the
reputation of your component as well as upsetting all those downstream
users who'd never even heard of your library before.

but, this choice is yours. this is just advice and not a condition :)

- robert


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

Re: [proxy] Moving Proxy to Commons Proper

[Knut Wannheden <kn...@gmail.com>]

On 10/19/05, James Carman <ja...@carmanconsulting.com> wrote:
> > i would also like to reiterate stephen's warning: if you use interfaces,
> > be very sure that you are not going to need to change them in any
> > fashion. i would very strongly suggest implementing the key
> > ProxyFactory logical interface as an abstract class. this isn't bias (i
> > love interfaces when coding applications) but a hard lesson painfully
> > learnt.
>
> Robert,
>
> I understand the concerns here, but I am really torn between changing the
> API and leaving it like it is.  IMHO, it is *very* unlikely that a user of
> Commons Proxy is even going to implement ProxyFactory on their own.  If I
> had to ballpark it, I would be surprised if 1 out of every 100 (I might even
> go 1000) people who use Commons Proxy implement ProxyFactory.  That's the
> whole point of using Commons Proxy in the first place.  You don't have to
> write the proxying logic yourself!  So, what is our target here?  Are we
> looking for 100% backward compatibility with *all* projects?  Or, are we
> happy with keeping something more like 90% or 95% of our users happy?  Maybe
> we could tell them in the documentation that if they have a proxying
> technology that they wish Commons Proxy supported that they can submit a
> request to the mailing list or into Bugzilla for it and we can take care of
> it (of course, any code that gets us going would help).  As long as we
> decide between AOP Alliance vs. "rolling our own" interfaces, I'm pretty
> happy with the ProxyFactory interface.  Besides, there's really nothing you
> can't do with Invokers.  That's sort of the "common denominator."
>

In Eclipse APIs it is common practice that interfaces are never
changed -- hence new interfaces have to be added when new changes are
required -- and abstract classes are used where changes (in form of
new methods) are expected (see
http://www.artima.com/lejava/articles/designprinciples.html).

As you say the Invokers are the "common denominator". So ProxyFactory
could be implemented as an abstract base class with the
createInvokerProxy() method declared as abstract and the other proxy
factory methods defined in terms of that. Concrete implementaions
would although do best in overriding these other methods for
performance reasons.

Although, as you say, there are probably not many users who will want
to implement this interface anyways. So maybe it's best left as it is.

I'm torn on this one. Any other thoughs?

--knut

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

RE: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

> i would also like to reiterate stephen's warning: if you use interfaces,
> be very sure that you are not going to need to change them in any
> fashion. i would very strongly suggest implementing the key
> ProxyFactory logical interface as an abstract class. this isn't bias (i
> love interfaces when coding applications) but a hard lesson painfully
> learnt. 

Robert,

I understand the concerns here, but I am really torn between changing the
API and leaving it like it is.  IMHO, it is *very* unlikely that a user of
Commons Proxy is even going to implement ProxyFactory on their own.  If I
had to ballpark it, I would be surprised if 1 out of every 100 (I might even
go 1000) people who use Commons Proxy implement ProxyFactory.  That's the
whole point of using Commons Proxy in the first place.  You don't have to
write the proxying logic yourself!  So, what is our target here?  Are we
looking for 100% backward compatibility with *all* projects?  Or, are we
happy with keeping something more like 90% or 95% of our users happy?  Maybe
we could tell them in the documentation that if they have a proxying
technology that they wish Commons Proxy supported that they can submit a
request to the mailing list or into Bugzilla for it and we can take care of
it (of course, any code that gets us going would help).  As long as we
decide between AOP Alliance vs. "rolling our own" interfaces, I'm pretty
happy with the ProxyFactory interface.  Besides, there's really nothing you
can't do with Invokers.  That's sort of the "common denominator."

James 



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

RE: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

Jörg,

Thanks.  I will remove the Eclipse and IDEA files.  I didn't realize that
Maven could generate files for IDEA/Eclipse.  That's really cool!  I did
read the other day how it could generate Ant build.xml files. 

James

-----Original Message-----
From: Joerg Hohwiller [mailto:joerg@j-hohwiller.de] 
Sent: Thursday, October 20, 2005 2:04 AM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Moving Proxy to Commons Proper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi James,

James Carman wrote:
> My comments are interleaved:
> 
> [snip]
> 
>>commons-proxy.imi, commons-proxy.ipr and lo4j.properties files need a
>>license boilerplate.
> 
> 
> I fixed log4j.properties, but every time I edit the Intellij IDEA files,
> IDEA overwrites them.  Am I not supposed to be including IDEA
project/module
> files?  How about Eclipse .classpath and .project files?  What's our
policy
> on this?
I think you should never check in IDE config files! They will contain user
specific preferences or favours. So this tends to become a commit war or at
least causes trouble if someone commits a change and others update and get
conflicts/merges.
You could provide them as examples with different name/location in the svn,
but you can generate the IDE settings for Eclipse and/or IntelliJ with maven
so there is absolutely no need for having them in svn. Better add some lines
about how to get startet and include the command to generate the IDE config
with
maven. Be aware, that if the POM (project.xml) changes (e.g. dependend jars
change), the IDE config can be updated (regenerated) with maven.
This is all about the idea of maven: single point of information.
Avoid having redundancies as you have the dependencies in project.xml and
the
IntelliJ settings.
> 
> [snip]
Regards
  Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDVzNlmPuec2Dcv/8RAu5zAJ49NFRhYiZP/AcfsadMk3PoFe3BKgCfXzUl
gQq/NDm+TuHedvdFw65iqqQ=
=sekE
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
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: [proxy] Moving Proxy to Commons Proper

[Joerg Hohwiller <jo...@j-hohwiller.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi James,

James Carman wrote:
> My comments are interleaved:
> 
> [snip]
> 
>>commons-proxy.imi, commons-proxy.ipr and lo4j.properties files need a
>>license boilerplate.
> 
> 
> I fixed log4j.properties, but every time I edit the Intellij IDEA files,
> IDEA overwrites them.  Am I not supposed to be including IDEA project/module
> files?  How about Eclipse .classpath and .project files?  What's our policy
> on this?
I think you should never check in IDE config files! They will contain user
specific preferences or favours. So this tends to become a commit war or at
least causes trouble if someone commits a change and others update and get
conflicts/merges.
You could provide them as examples with different name/location in the svn,
but you can generate the IDE settings for Eclipse and/or IntelliJ with maven
so there is absolutely no need for having them in svn. Better add some lines
about how to get startet and include the command to generate the IDE config with
maven. Be aware, that if the POM (project.xml) changes (e.g. dependend jars
change), the IDE config can be updated (regenerated) with maven.
This is all about the idea of maven: single point of information.
Avoid having redundancies as you have the dependencies in project.xml and the
IntelliJ settings.
> 
> [snip]
Regards
  Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDVzNlmPuec2Dcv/8RAu5zAJ49NFRhYiZP/AcfsadMk3PoFe3BKgCfXzUl
gQq/NDm+TuHedvdFw65iqqQ=
=sekE
-----END PGP SIGNATURE-----

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

RE: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

My comments are interleaved:

> i think that the proposal could be improved. it's usually used as the
> basis of the introduction paragraph for the component. a good proposal
> is a powerful weapon against featuritus and scope drift. so, it's
> important for the long term health of a project. 

> "The package shall create and maintain a suite of utility classes for
> creating proxy objects" seems just a little short. it seems to me that
> proxy is more like a minimal core of bridging API's for constructing
> proxy's (with minimal dependencies) supported by a number of optional
> implementations. 

I'm working on the proposal now.

> i would also like to reiterate stephen's warning: if you use interfaces,
> be very sure that you are not going to need to change them in any
> fashion. i would very strongly suggest implementing the key
> ProxyFactory logical interface as an abstract class. this isn't bias (i
> love interfaces when coding applications) but a hard lesson painfully
> learnt. 

I'm pretty sure about the ProxyFactory interface, actually.  I don't think
I'd actually be changing any of the existing method names/parameters.
However, I may have to add methods in the future.  That could cause problems
when folks upgrade, but I think I'd have the same problem if I used an
abstract class.  This is the first time that I've heard people tell me *not*
to use interfaces!  I understand the concern, though.  If anyone has any
suggestions for the ProxyFactory interface, I would be glad to hear them.
We really need to get this right.

> IMHO it'd be a good idea to note in the comment on the maven dependency
> page which dependencies are required for what code (preferably with an
> OPTIONAL at the start of the comment). a lot of users really complain
> (with good reason) about libraries with lots of core dependencies. the
> downside of maven (1) builds is that the list of dependencies can prove
> misleading.

Done, but I just appended "(optional)" rather than using a prefix because
Maven, for some reason, didn't include the comment when I prefixed it with
"OPTIONAL:".

> the maven mailing list page doesn't seem to have any information.

Fixed.

> you have some javadoc warnings and checkstyle violations.

Fixed.

> the distribution build doesn't load the notice and license into the jar
> MANEFEST. please read
> http://jakarta.apache.org/commons/releases/prepare.html for more
> details. 

Fixed.

> commons-proxy.imi, commons-proxy.ipr and lo4j.properties files need a
> license boilerplate.

I fixed log4j.properties, but every time I edit the Intellij IDEA files,
IDEA overwrites them.  Am I not supposed to be including IDEA project/module
files?  How about Eclipse .classpath and .project files?  What's our policy
on this?

> navigation.xml lists the project as beanutils

Fixed

> status.html still says 'collections' in a number of places. the list of 
> required runtime dependencies is probably now outdated.

Fixed

> ProxyUtils may well encounter classloading difficulties in some
> containers. it is possible that the context classloader may be null or
> inaccessible. i'm not convinced that the instantiateProxyFactory code
> will cope gracefully under all circumstances.
> http://jakarta.apache.org/commons/logging/tech.html may prove useful.

I'm going to have to look into this and maybe put in some test cases.

> on a slightly more serious note, the proposal says:

> "The initial codebase will be contributed by James Carman based on code
> in the Syringe (http://syringe.dev.java.net) project and can be
> distributed under the Apache license."

> has the incubator checked the paperwork for this?

Yes, the software grant paperwork has been filed.

> basic package level document. a lot of components include a basic
> introduction in the package level java docs. the information already
> contained in status and proposal document would make a good start.

Working on this still.

> since there are a lot of optional dependencies, it would be a very good
> idea to indicate in the javadocs which classes require which optional
> dependencies. for some packages, the package level documentation could
> be used for this.

This is done as far as I can tell.  I took care of most of the classes that
required outside dependencies.



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

RE: [proxy] Moving Proxy to Commons Proper

[robert burrell donkin <ro...@blueyonder.co.uk>]

ping?

(i didn't really intend this to slow down the momentum)

- robert

On Sat, 2005-10-22 at 14:01 +0100, robert burrell donkin wrote:
> On Thu, 2005-10-20 at 08:14 -0400, James Carman wrote:
> > > i think that the proposal could be improved. it's usually used as the
> > > basis of the introduction paragraph for the component. a good proposal
> > > is a powerful weapon against featuritus and scope drift. so, it's
> > > important for the long term health of a project. 
> > 
> > > "The package shall create and maintain a suite of utility classes for
> > > creating proxy objects" seems just a little short. it seems to me that
> > > proxy is more like a minimal core of bridging API's for constructing
> > > proxy's (with minimal dependencies) supported by a number of optional
> > > implementations. 
> > 
> > That's just the first sentence of the proposals "Scope of the Package"
> > section.  Here's the whole paragraph:
> > 
> > The package shall create and maintain a suite of utility classes for
> > creating proxy objects written in the Java language to be distributed under
> > the ASF license. The package will include many different "object provider"
> > implementations.  The package will also serve as a repository for many
> > useful interceptor implementations. The package will provide multiple "proxy
> > factory" implementations, supporting different proxying technologies (JDK
> > proxies, CGLIB, and Javassist).
> 
> IMHO that sounds more a like a description than a definition.
> 
> good scopes are tough but it's best to be declarative rather than
> descriptive. the main use of the scope is to be able to know when a
> particular bit of functionality is in-scope and when it'd be better to
> create a new individual library. 
> 
> the problem with descriptive scopes is that if they are taken literally
> then new work is almost always out-of-scope. 
> 
> thinking about the scope can really help a component discover it's
> mission. for example, discussing the scope for math really helped to
> define it's niche in the code ecology. 
> 
> this is an opertunity you only get once :) 
> 
> > The Commons Collections PROPOSAL.html file has this in its "Scope of the
> > Package" section:
> > 
> > "The package will create and maintain a set of collections and related
> > classes designed to be compatible with the Java Collections Framework, and
> > to be distributed under the ASF license."
> > 
> > I tried to model proxy's documents after collections, since it is one of the
> > most popular commons libraries.
> 
> unfortunately, it also has one of the worst scope statements :)
> 
> in the past, this lack of clarity resulted in arguments about scope.
> 
> - robert
> 
> 
> ---------------------------------------------------------------------
> 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: [proxy] Moving Proxy to Commons Proper

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Thu, 2005-10-20 at 08:14 -0400, James Carman wrote:
> > i think that the proposal could be improved. it's usually used as the
> > basis of the introduction paragraph for the component. a good proposal
> > is a powerful weapon against featuritus and scope drift. so, it's
> > important for the long term health of a project. 
> 
> > "The package shall create and maintain a suite of utility classes for
> > creating proxy objects" seems just a little short. it seems to me that
> > proxy is more like a minimal core of bridging API's for constructing
> > proxy's (with minimal dependencies) supported by a number of optional
> > implementations. 
> 
> That's just the first sentence of the proposals "Scope of the Package"
> section.  Here's the whole paragraph:
> 
> The package shall create and maintain a suite of utility classes for
> creating proxy objects written in the Java language to be distributed under
> the ASF license. The package will include many different "object provider"
> implementations.  The package will also serve as a repository for many
> useful interceptor implementations. The package will provide multiple "proxy
> factory" implementations, supporting different proxying technologies (JDK
> proxies, CGLIB, and Javassist).

IMHO that sounds more a like a description than a definition.

good scopes are tough but it's best to be declarative rather than
descriptive. the main use of the scope is to be able to know when a
particular bit of functionality is in-scope and when it'd be better to
create a new individual library. 

the problem with descriptive scopes is that if they are taken literally
then new work is almost always out-of-scope. 

thinking about the scope can really help a component discover it's
mission. for example, discussing the scope for math really helped to
define it's niche in the code ecology. 

this is an opertunity you only get once :) 

> The Commons Collections PROPOSAL.html file has this in its "Scope of the
> Package" section:
> 
> "The package will create and maintain a set of collections and related
> classes designed to be compatible with the Java Collections Framework, and
> to be distributed under the ASF license."
> 
> I tried to model proxy's documents after collections, since it is one of the
> most popular commons libraries.

unfortunately, it also has one of the worst scope statements :)

in the past, this lack of clarity resulted in arguments about scope.

- robert


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

RE: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

> i think that the proposal could be improved. it's usually used as the
> basis of the introduction paragraph for the component. a good proposal
> is a powerful weapon against featuritus and scope drift. so, it's
> important for the long term health of a project. 

> "The package shall create and maintain a suite of utility classes for
> creating proxy objects" seems just a little short. it seems to me that
> proxy is more like a minimal core of bridging API's for constructing
> proxy's (with minimal dependencies) supported by a number of optional
> implementations. 

That's just the first sentence of the proposals "Scope of the Package"
section.  Here's the whole paragraph:

The package shall create and maintain a suite of utility classes for
creating proxy objects written in the Java language to be distributed under
the ASF license. The package will include many different "object provider"
implementations.  The package will also serve as a repository for many
useful interceptor implementations. The package will provide multiple "proxy
factory" implementations, supporting different proxying technologies (JDK
proxies, CGLIB, and Javassist).


The Commons Collections PROPOSAL.html file has this in its "Scope of the
Package" section:

"The package will create and maintain a set of collections and related
classes designed to be compatible with the Java Collections Framework, and
to be distributed under the ASF license."

I tried to model proxy's documents after collections, since it is one of the
most popular commons libraries.





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

RE: [proxy] Moving Proxy to Commons Proper

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Mon, 2005-10-17 at 10:28 -0400, James Carman wrote:
> Of course, I meant the only *required* dependency that Commons Proxy has is
> the JDK itself.

great :)

i think that the proposal could be improved. it's usually used as the
basis of the introduction paragraph for the component. a good proposal
is a powerful weapon against featuritus and scope drift. so, it's
important for the long term health of a project. 

"The package shall create and maintain a suite of utility classes for
creating proxy objects" seems just a little short. it seems to me that
proxy is more like a minimal core of bridging API's for constructing
proxy's (with minimal dependencies) supported by a number of optional
implementations. 

i would also like to reiterate stephen's warning: if you use interfaces,
be very sure that you are not going to need to change them in any
fashion. i would very strongly suggest implementing the key
ProxyFactory logical interface as an abstract class. this isn't bias (i
love interfaces when coding applications) but a hard lesson painfully
learnt. 


a few minor points:

IMHO it'd be a good idea to note in the comment on the maven dependency
page which dependencies are required for what code (preferably with an
OPTIONAL at the start of the comment). a lot of users really complain
(with good reason) about libraries with lots of core dependencies. the
downside of maven (1) builds is that the list of dependencies can prove
misleading.

the maven mailing list page doesn't seem to have any information.

you have some javadoc warnings and checkstyle violations.

the distribution build doesn't load the notice and license into the jar
MANEFEST. please read
http://jakarta.apache.org/commons/releases/prepare.html for more
details. 

commons-proxy.imi, commons-proxy.ipr and lo4j.properties files need a
license boilerplate.

navigation.xml lists the project as beanutils

status.html still says 'collections' in a number of places. the list of 
required runtime dependencies is probably now outdated.

ProxyUtils may well encounter classloading difficulties in some
containers. it is possible that the context classloader may be null or
inaccessible. i'm not convinced that the instantiateProxyFactory code
will cope gracefully under all circumstances.
http://jakarta.apache.org/commons/logging/tech.html may prove useful.



on a slightly more serious note, the proposal says:

"The initial codebase will be contributed by James Carman based on code
in the Syringe (http://syringe.dev.java.net) project and can be
distributed under the Apache license."

has the incubator checked the paperwork for this?


some nice to haves: 

basic package level document. a lot of components include a basic
introduction in the package level java docs. the information already
contained in status and proposal document would make a good start.

since there are a lot of optional dependencies, it would be a very good
idea to indicate in the javadocs which classes require which optional
dependencies. for some packages, the package level documentation could
be used for this.

- robert


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

RE: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

Of course, I meant the only *required* dependency that Commons Proxy has is
the JDK itself.

-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com] 
Sent: Monday, October 17, 2005 10:26 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [proxy] Moving Proxy to Commons Proper


I went ahead and committed it.  So, the only dependency Commons Proxy has
now is the JDK itself!  Check that out and let me know what you think.
There are two "adapter" classes included which allow the use of JDK
InvocationHandlers and AOP Alliance MethodInterceptors:

http://jakarta.apache.org/commons/sandbox/proxy/xref/org/apache/commons/prox
y/invoker/InvocationHandlerAdapter.html


http://jakarta.apache.org/commons/sandbox/proxy/xref/org/apache/commons/prox
y/interceptor/MethodInterceptorAdapter.html

If we choose to switch back to the AOP Alliance API directly, we can pretty
easily.  But, we may want to stick with this.  I don't know.

James
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com] 
Sent: Sunday, October 16, 2005 10:03 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [proxy] Moving Proxy to Commons Proper

I have implemented what I was talking about (using our own interfaces and
providing bridge/adapter implementations).  Do you guys want me to check it
in so that you can see what I mean?  Basically, I introduced a few new
interfaces (Invoker, InvocationInterceptor, and Invocation) and made
ProxyFactory dependent upon those rather than the AOP Alliance stuff and the
InvocationHandler (in the JDK).

-----Original Message-----
From: Joerg Hohwiller [mailto:joerg@j-hohwiller.de] 
Sent: Sunday, October 16, 2005 8:08 AM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Moving Proxy to Commons Proper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Carman wrote:
> Stephen,
Hi there,

just to give some feedback from me...

In my oppinion commons-proxy is very usefull already as is. So I
want to agree with the initial idea of this thread and would also like to
see it in proper.
> 
> Thank you for taking the time to dig into the code and poke around a bit.
> I'll try to address your questions/concerns here:
> 
> 1.  Logging interceptor using Javassist - it didn't really use Javassist,
> but a method that was in JavassistUtils which returns the "java class
name"
> of a class (java class name of Object[] == "java.lang.Object[]").  So, I
> moved that method to ProxyUtils.  That was a good catch.  Thanks!  It
would
> be silly to introduce a dependency on Javassist just to log method
> invocations!
> 
> 2.  The ProxyFactory interface could limit you in the future - I don't
> understand what you mean here.  Do you mean because I depend on interfaces
> that I don't have control over (AOP Alliance's MethodInterceptor and the
> JDK's InvocationHandler)?  If so, then I suppose that I could come up with
> my own interfaces and provide "bridge" or "adapter" classes to close the
gap
> (I think someone suggested this before, but I forgot about it).  This
would
> actually remove *all* required dependencies (other than JDK1.3+) from
> [proxy].  All other dependencies are optional.  If you want to use CGLIB
or
> Javassist to create your proxies, you can just include them in your
> classpath.  Maybe I could provide a getInstance() method on ProxyFactory
> which tries to discover which options are available (Javassist, then
CGLIB,
> then default to JDK proxies; override using system propery).  What would
you
> think about these changes?
I am currently active on commons-logging. We want to extend the API of the
logger. The problem is that extending the existing interface (Log) is not a
good
idea, because it is already implemented by third-party code that we can not
control. So if we add new methods to the interface, we will break
dependencies.
So we expierence some difficulties in realizing the proposal, even though it
is
still possible without breaking dependencies.
The same issue is also causing pain in log4j 1.2 -> 1.3 where the intention
was
to prepare for removing legacy stuff in further releases.
So I think Stephen wanted to say that you should think deep about
ProxyFactory
and consider if there could be use-cases in the future that may need to
change
the interface in any way? There we discussions about the fact that what
commons-proxy does is already done by others. It may help to have a look
there and consolidate the ideas to have a stable API for the future.
I personally think your usage and dependency on AOP-Al. is good and not a
problem, but removing dependencies is never a bad thing. Anyways AOP-Al.
aims to
be THE API for that issue and for me it does not make sense to encapsulate
this
API. Isn't the idea that you have an AOP-Al. compatible implementation and
can
pass those instances directly to commons-proxy?
But I am maybe not deep enough into commons-proxy to see exactly what you
pointed out.
> 
> 3.  Will most users have to write their own code implementing an 
> interface defining in [proxy], or can they just used the existing 
> implementations? - Well, users could use existing AOP Alliance method
> interceptors (like the ones included with Spring, for example).  Other
than
> that, if you just want to create proxies for your classes/objects, you
don't
> have to implement anything from [proxy].  The core object providers
> (BeanProvider or ConstantProvider) would provide all you need to "plug
in."
mhm. Actually I can not see the problem about commons-proxy beeing a wrong
animal here... logging has dependencies on various native-logger
implementations. They are all optional but I think this is almost the same
about
commons-proxy.
You might consider to spilt some of the code into sub-projects. Then you can
have the commons-proxy core with almost no dependencies and addintional
sub-projects for cglib stuff, javassist stuff, and the cacho stuff.
This will be very conform with the maven philosophy of projects and
dependencies.
The disadvantage is that by default you will not produce a single jar as
artifact by default. Anyways you can still provide this if you want.
> 
> James
Regards
  Jörg

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Saturday, October 15, 2005 8:08 AM
> To: Jakarta Commons Developers List
> Subject: Re: [proxy] Moving Proxy to Commons Proper
> 
> James Carman wrote:
> 
>>Thank you for your feedback (finally somebody said *something*).  I made
>>this a vote based on the instructions found at
>>http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN.
> 
> Maybe
> 
>>we should update that WIKI to suggest making a proposal first and then
>>starting a vote if there are no objections.  I really just wanted to know
> 
> if
> 
>>there were any technical objections to having proxy move into the commons
>>proper so that I could fix the problems.  I would really like to see this
>>become a full-fledged commons component.  I think it's a very useful idea
>>and a pretty intuitive API.
> 
> 
> I took a look this morning, and also thought it could be quite useful, 
> and I could follow reasonably well what was going on.
> 
> Technically, I remember a couple of oddities, although there may be more:
> - the Logging interceptor used Javassist, an odd dependency
> - the core ProxyFactory interface could limit you in the future, as you 
> can't change released interfaces
> 
> The more fundamental question however, is whether this is a true commons 
> component. The sheer number of dependencies is a real question. Now 
> while a lot are probably optional, some will not be.
> 
> This component looks rather like a framework to me, although a very low 
> level framework. Commons does have other components that have interfaces 
> and plugin points, but doesn't this one go further than we've had 
> before? Will most users have to write their own code implementing an 
> interface defining in [proxy], or can they just used the existing 
> implementations?
> 
> Stephen
> 
> 
> 
>>As for your suggestion to cut a release candidate now, I like it.  I do
>>think that I need some simple tutorials/examples on the site before it's
>>ready for a real release, so I'll try to take care of that sometime soon.
>>Then, I'll cut a release candidate, per your suggestion.  I will try to
>>follow the directions found at
>>http://jakarta.apache.org/commons/releases/prepare.html to prepare the
>>release candidate, but I'm probably bound to make mistakes as I'm new to
>>this project management stuff.  I'll probably have a few questions along
> 
> the
> 
>>way too! 
>>
>> 
>>
>>Also, I would still like to hear if anyone else has any suggestions for
>>things that I need to take care of before they would consider it ready for
>>release.  Resolving the 1.5 dependency helped of course, even if it did
> 
> make
> 
>>the API a lot uglier IMHO.  I liked the var-args feature for specifying
> 
> the
> 
>>interfaces/classes that the proxy should support and I would rather use
> 
> the
> 
>>core JDK Executor class rather than the one from the "concurrent" API.  Oh
>>well.
>>
>> 
>>
>>James
>>
>> 
>>
>>-----Original Message-----
>>From: robert burrell donkin [mailto:rdonkin@apache.org] 
>>Sent: Saturday, October 15, 2005 6:28 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [VOTE] Moving Proxy to Commons Proper
>>
>> 
>>
>>hi james
>>
>> 
>>
>>IMO it would be better to make this a proposal. quite often, small
>>
>>changes will are needed and discussion required. votes tend to get a
>>
>>little confused and lost when that happens. usually, it's a bit cleaner
>>
>>to make a proposal then move to a vote when there are no remaining
>>
>>objections.
>>
>> 
>>
>>On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:
>>
>>
>>
>>>All,
>>
>>
>>
>>>Outside projects (currently my Syringe project and the "Crispy" project
at
>>
>>
>>>sourceforge) are beginning to want to use Commons Proxy, but are finding
>>
>>it
>>
>>
>>
>>>difficult since it's in the sandbox and no releases are available.  I
>>
>>
>>>believe Proxy's API is close to being ready for a release candidate.
>>
>>
>>>Currently, I don't have any other bright ideas for it, but I'm open to
>>
>>
>>>suggestions.  Moving it to the proper will help us prepare it for an
>>
>>
>>>official release.
>>
>>
>> 
>>
>>being ready for an official release is one of my personal criteria for
>>
>>promotion (so that's good). part of being ready is demonstrating to the
>>
>>community that the committers know how to cut commons releases. 
>>
>> 
>>
>>might i suggest that you cut an example release candidate and upload it
>>
>>to your apache home directory. not only will this speed the time taken
>>
>>to cut the first release (we can spot any problems now rather than
>>
>>later) but it will also give us a better idea of where proxy actually is
>>
>>right now.
>>
>> 
>>
>>- robert
>>
>>
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDUkKRmPuec2Dcv/8RArfbAJ0TfUd0D8Bp5HtRuLD0lCmQz8kK9gCfXbEh
vncqXCrQ5E34qhEhq5qlkeA=
=bldL
-----END PGP SIGNATURE-----

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




---------------------------------------------------------------------
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: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

I went ahead and committed it.  So, the only dependency Commons Proxy has
now is the JDK itself!  Check that out and let me know what you think.
There are two "adapter" classes included which allow the use of JDK
InvocationHandlers and AOP Alliance MethodInterceptors:

http://jakarta.apache.org/commons/sandbox/proxy/xref/org/apache/commons/prox
y/invoker/InvocationHandlerAdapter.html


http://jakarta.apache.org/commons/sandbox/proxy/xref/org/apache/commons/prox
y/interceptor/MethodInterceptorAdapter.html

If we choose to switch back to the AOP Alliance API directly, we can pretty
easily.  But, we may want to stick with this.  I don't know.

James
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com] 
Sent: Sunday, October 16, 2005 10:03 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [proxy] Moving Proxy to Commons Proper

I have implemented what I was talking about (using our own interfaces and
providing bridge/adapter implementations).  Do you guys want me to check it
in so that you can see what I mean?  Basically, I introduced a few new
interfaces (Invoker, InvocationInterceptor, and Invocation) and made
ProxyFactory dependent upon those rather than the AOP Alliance stuff and the
InvocationHandler (in the JDK).

-----Original Message-----
From: Joerg Hohwiller [mailto:joerg@j-hohwiller.de] 
Sent: Sunday, October 16, 2005 8:08 AM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Moving Proxy to Commons Proper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Carman wrote:
> Stephen,
Hi there,

just to give some feedback from me...

In my oppinion commons-proxy is very usefull already as is. So I
want to agree with the initial idea of this thread and would also like to
see it in proper.
> 
> Thank you for taking the time to dig into the code and poke around a bit.
> I'll try to address your questions/concerns here:
> 
> 1.  Logging interceptor using Javassist - it didn't really use Javassist,
> but a method that was in JavassistUtils which returns the "java class
name"
> of a class (java class name of Object[] == "java.lang.Object[]").  So, I
> moved that method to ProxyUtils.  That was a good catch.  Thanks!  It
would
> be silly to introduce a dependency on Javassist just to log method
> invocations!
> 
> 2.  The ProxyFactory interface could limit you in the future - I don't
> understand what you mean here.  Do you mean because I depend on interfaces
> that I don't have control over (AOP Alliance's MethodInterceptor and the
> JDK's InvocationHandler)?  If so, then I suppose that I could come up with
> my own interfaces and provide "bridge" or "adapter" classes to close the
gap
> (I think someone suggested this before, but I forgot about it).  This
would
> actually remove *all* required dependencies (other than JDK1.3+) from
> [proxy].  All other dependencies are optional.  If you want to use CGLIB
or
> Javassist to create your proxies, you can just include them in your
> classpath.  Maybe I could provide a getInstance() method on ProxyFactory
> which tries to discover which options are available (Javassist, then
CGLIB,
> then default to JDK proxies; override using system propery).  What would
you
> think about these changes?
I am currently active on commons-logging. We want to extend the API of the
logger. The problem is that extending the existing interface (Log) is not a
good
idea, because it is already implemented by third-party code that we can not
control. So if we add new methods to the interface, we will break
dependencies.
So we expierence some difficulties in realizing the proposal, even though it
is
still possible without breaking dependencies.
The same issue is also causing pain in log4j 1.2 -> 1.3 where the intention
was
to prepare for removing legacy stuff in further releases.
So I think Stephen wanted to say that you should think deep about
ProxyFactory
and consider if there could be use-cases in the future that may need to
change
the interface in any way? There we discussions about the fact that what
commons-proxy does is already done by others. It may help to have a look
there and consolidate the ideas to have a stable API for the future.
I personally think your usage and dependency on AOP-Al. is good and not a
problem, but removing dependencies is never a bad thing. Anyways AOP-Al.
aims to
be THE API for that issue and for me it does not make sense to encapsulate
this
API. Isn't the idea that you have an AOP-Al. compatible implementation and
can
pass those instances directly to commons-proxy?
But I am maybe not deep enough into commons-proxy to see exactly what you
pointed out.
> 
> 3.  Will most users have to write their own code implementing an 
> interface defining in [proxy], or can they just used the existing 
> implementations? - Well, users could use existing AOP Alliance method
> interceptors (like the ones included with Spring, for example).  Other
than
> that, if you just want to create proxies for your classes/objects, you
don't
> have to implement anything from [proxy].  The core object providers
> (BeanProvider or ConstantProvider) would provide all you need to "plug
in."
mhm. Actually I can not see the problem about commons-proxy beeing a wrong
animal here... logging has dependencies on various native-logger
implementations. They are all optional but I think this is almost the same
about
commons-proxy.
You might consider to spilt some of the code into sub-projects. Then you can
have the commons-proxy core with almost no dependencies and addintional
sub-projects for cglib stuff, javassist stuff, and the cacho stuff.
This will be very conform with the maven philosophy of projects and
dependencies.
The disadvantage is that by default you will not produce a single jar as
artifact by default. Anyways you can still provide this if you want.
> 
> James
Regards
  Jörg

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Saturday, October 15, 2005 8:08 AM
> To: Jakarta Commons Developers List
> Subject: Re: [proxy] Moving Proxy to Commons Proper
> 
> James Carman wrote:
> 
>>Thank you for your feedback (finally somebody said *something*).  I made
>>this a vote based on the instructions found at
>>http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN.
> 
> Maybe
> 
>>we should update that WIKI to suggest making a proposal first and then
>>starting a vote if there are no objections.  I really just wanted to know
> 
> if
> 
>>there were any technical objections to having proxy move into the commons
>>proper so that I could fix the problems.  I would really like to see this
>>become a full-fledged commons component.  I think it's a very useful idea
>>and a pretty intuitive API.
> 
> 
> I took a look this morning, and also thought it could be quite useful, 
> and I could follow reasonably well what was going on.
> 
> Technically, I remember a couple of oddities, although there may be more:
> - the Logging interceptor used Javassist, an odd dependency
> - the core ProxyFactory interface could limit you in the future, as you 
> can't change released interfaces
> 
> The more fundamental question however, is whether this is a true commons 
> component. The sheer number of dependencies is a real question. Now 
> while a lot are probably optional, some will not be.
> 
> This component looks rather like a framework to me, although a very low 
> level framework. Commons does have other components that have interfaces 
> and plugin points, but doesn't this one go further than we've had 
> before? Will most users have to write their own code implementing an 
> interface defining in [proxy], or can they just used the existing 
> implementations?
> 
> Stephen
> 
> 
> 
>>As for your suggestion to cut a release candidate now, I like it.  I do
>>think that I need some simple tutorials/examples on the site before it's
>>ready for a real release, so I'll try to take care of that sometime soon.
>>Then, I'll cut a release candidate, per your suggestion.  I will try to
>>follow the directions found at
>>http://jakarta.apache.org/commons/releases/prepare.html to prepare the
>>release candidate, but I'm probably bound to make mistakes as I'm new to
>>this project management stuff.  I'll probably have a few questions along
> 
> the
> 
>>way too! 
>>
>> 
>>
>>Also, I would still like to hear if anyone else has any suggestions for
>>things that I need to take care of before they would consider it ready for
>>release.  Resolving the 1.5 dependency helped of course, even if it did
> 
> make
> 
>>the API a lot uglier IMHO.  I liked the var-args feature for specifying
> 
> the
> 
>>interfaces/classes that the proxy should support and I would rather use
> 
> the
> 
>>core JDK Executor class rather than the one from the "concurrent" API.  Oh
>>well.
>>
>> 
>>
>>James
>>
>> 
>>
>>-----Original Message-----
>>From: robert burrell donkin [mailto:rdonkin@apache.org] 
>>Sent: Saturday, October 15, 2005 6:28 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [VOTE] Moving Proxy to Commons Proper
>>
>> 
>>
>>hi james
>>
>> 
>>
>>IMO it would be better to make this a proposal. quite often, small
>>
>>changes will are needed and discussion required. votes tend to get a
>>
>>little confused and lost when that happens. usually, it's a bit cleaner
>>
>>to make a proposal then move to a vote when there are no remaining
>>
>>objections.
>>
>> 
>>
>>On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:
>>
>>
>>
>>>All,
>>
>>
>>
>>>Outside projects (currently my Syringe project and the "Crispy" project
at
>>
>>
>>>sourceforge) are beginning to want to use Commons Proxy, but are finding
>>
>>it
>>
>>
>>
>>>difficult since it's in the sandbox and no releases are available.  I
>>
>>
>>>believe Proxy's API is close to being ready for a release candidate.
>>
>>
>>>Currently, I don't have any other bright ideas for it, but I'm open to
>>
>>
>>>suggestions.  Moving it to the proper will help us prepare it for an
>>
>>
>>>official release.
>>
>>
>> 
>>
>>being ready for an official release is one of my personal criteria for
>>
>>promotion (so that's good). part of being ready is demonstrating to the
>>
>>community that the committers know how to cut commons releases. 
>>
>> 
>>
>>might i suggest that you cut an example release candidate and upload it
>>
>>to your apache home directory. not only will this speed the time taken
>>
>>to cut the first release (we can spot any problems now rather than
>>
>>later) but it will also give us a better idea of where proxy actually is
>>
>>right now.
>>
>> 
>>
>>- robert
>>
>>
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDUkKRmPuec2Dcv/8RArfbAJ0TfUd0D8Bp5HtRuLD0lCmQz8kK9gCfXbEh
vncqXCrQ5E34qhEhq5qlkeA=
=bldL
-----END PGP SIGNATURE-----

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




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

RE: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

I have implemented what I was talking about (using our own interfaces and
providing bridge/adapter implementations).  Do you guys want me to check it
in so that you can see what I mean?  Basically, I introduced a few new
interfaces (Invoker, InvocationInterceptor, and Invocation) and made
ProxyFactory dependent upon those rather than the AOP Alliance stuff and the
InvocationHandler (in the JDK).

-----Original Message-----
From: Joerg Hohwiller [mailto:joerg@j-hohwiller.de] 
Sent: Sunday, October 16, 2005 8:08 AM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Moving Proxy to Commons Proper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Carman wrote:
> Stephen,
Hi there,

just to give some feedback from me...

In my oppinion commons-proxy is very usefull already as is. So I
want to agree with the initial idea of this thread and would also like to
see it in proper.
> 
> Thank you for taking the time to dig into the code and poke around a bit.
> I'll try to address your questions/concerns here:
> 
> 1.  Logging interceptor using Javassist - it didn't really use Javassist,
> but a method that was in JavassistUtils which returns the "java class
name"
> of a class (java class name of Object[] == "java.lang.Object[]").  So, I
> moved that method to ProxyUtils.  That was a good catch.  Thanks!  It
would
> be silly to introduce a dependency on Javassist just to log method
> invocations!
> 
> 2.  The ProxyFactory interface could limit you in the future - I don't
> understand what you mean here.  Do you mean because I depend on interfaces
> that I don't have control over (AOP Alliance's MethodInterceptor and the
> JDK's InvocationHandler)?  If so, then I suppose that I could come up with
> my own interfaces and provide "bridge" or "adapter" classes to close the
gap
> (I think someone suggested this before, but I forgot about it).  This
would
> actually remove *all* required dependencies (other than JDK1.3+) from
> [proxy].  All other dependencies are optional.  If you want to use CGLIB
or
> Javassist to create your proxies, you can just include them in your
> classpath.  Maybe I could provide a getInstance() method on ProxyFactory
> which tries to discover which options are available (Javassist, then
CGLIB,
> then default to JDK proxies; override using system propery).  What would
you
> think about these changes?
I am currently active on commons-logging. We want to extend the API of the
logger. The problem is that extending the existing interface (Log) is not a
good
idea, because it is already implemented by third-party code that we can not
control. So if we add new methods to the interface, we will break
dependencies.
So we expierence some difficulties in realizing the proposal, even though it
is
still possible without breaking dependencies.
The same issue is also causing pain in log4j 1.2 -> 1.3 where the intention
was
to prepare for removing legacy stuff in further releases.
So I think Stephen wanted to say that you should think deep about
ProxyFactory
and consider if there could be use-cases in the future that may need to
change
the interface in any way? There we discussions about the fact that what
commons-proxy does is already done by others. It may help to have a look
there and consolidate the ideas to have a stable API for the future.
I personally think your usage and dependency on AOP-Al. is good and not a
problem, but removing dependencies is never a bad thing. Anyways AOP-Al.
aims to
be THE API for that issue and for me it does not make sense to encapsulate
this
API. Isn't the idea that you have an AOP-Al. compatible implementation and
can
pass those instances directly to commons-proxy?
But I am maybe not deep enough into commons-proxy to see exactly what you
pointed out.
> 
> 3.  Will most users have to write their own code implementing an 
> interface defining in [proxy], or can they just used the existing 
> implementations? - Well, users could use existing AOP Alliance method
> interceptors (like the ones included with Spring, for example).  Other
than
> that, if you just want to create proxies for your classes/objects, you
don't
> have to implement anything from [proxy].  The core object providers
> (BeanProvider or ConstantProvider) would provide all you need to "plug
in."
mhm. Actually I can not see the problem about commons-proxy beeing a wrong
animal here... logging has dependencies on various native-logger
implementations. They are all optional but I think this is almost the same
about
commons-proxy.
You might consider to spilt some of the code into sub-projects. Then you can
have the commons-proxy core with almost no dependencies and addintional
sub-projects for cglib stuff, javassist stuff, and the cacho stuff.
This will be very conform with the maven philosophy of projects and
dependencies.
The disadvantage is that by default you will not produce a single jar as
artifact by default. Anyways you can still provide this if you want.
> 
> James
Regards
  Jörg

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Saturday, October 15, 2005 8:08 AM
> To: Jakarta Commons Developers List
> Subject: Re: [proxy] Moving Proxy to Commons Proper
> 
> James Carman wrote:
> 
>>Thank you for your feedback (finally somebody said *something*).  I made
>>this a vote based on the instructions found at
>>http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN.
> 
> Maybe
> 
>>we should update that WIKI to suggest making a proposal first and then
>>starting a vote if there are no objections.  I really just wanted to know
> 
> if
> 
>>there were any technical objections to having proxy move into the commons
>>proper so that I could fix the problems.  I would really like to see this
>>become a full-fledged commons component.  I think it's a very useful idea
>>and a pretty intuitive API.
> 
> 
> I took a look this morning, and also thought it could be quite useful, 
> and I could follow reasonably well what was going on.
> 
> Technically, I remember a couple of oddities, although there may be more:
> - the Logging interceptor used Javassist, an odd dependency
> - the core ProxyFactory interface could limit you in the future, as you 
> can't change released interfaces
> 
> The more fundamental question however, is whether this is a true commons 
> component. The sheer number of dependencies is a real question. Now 
> while a lot are probably optional, some will not be.
> 
> This component looks rather like a framework to me, although a very low 
> level framework. Commons does have other components that have interfaces 
> and plugin points, but doesn't this one go further than we've had 
> before? Will most users have to write their own code implementing an 
> interface defining in [proxy], or can they just used the existing 
> implementations?
> 
> Stephen
> 
> 
> 
>>As for your suggestion to cut a release candidate now, I like it.  I do
>>think that I need some simple tutorials/examples on the site before it's
>>ready for a real release, so I'll try to take care of that sometime soon.
>>Then, I'll cut a release candidate, per your suggestion.  I will try to
>>follow the directions found at
>>http://jakarta.apache.org/commons/releases/prepare.html to prepare the
>>release candidate, but I'm probably bound to make mistakes as I'm new to
>>this project management stuff.  I'll probably have a few questions along
> 
> the
> 
>>way too! 
>>
>> 
>>
>>Also, I would still like to hear if anyone else has any suggestions for
>>things that I need to take care of before they would consider it ready for
>>release.  Resolving the 1.5 dependency helped of course, even if it did
> 
> make
> 
>>the API a lot uglier IMHO.  I liked the var-args feature for specifying
> 
> the
> 
>>interfaces/classes that the proxy should support and I would rather use
> 
> the
> 
>>core JDK Executor class rather than the one from the "concurrent" API.  Oh
>>well.
>>
>> 
>>
>>James
>>
>> 
>>
>>-----Original Message-----
>>From: robert burrell donkin [mailto:rdonkin@apache.org] 
>>Sent: Saturday, October 15, 2005 6:28 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [VOTE] Moving Proxy to Commons Proper
>>
>> 
>>
>>hi james
>>
>> 
>>
>>IMO it would be better to make this a proposal. quite often, small
>>
>>changes will are needed and discussion required. votes tend to get a
>>
>>little confused and lost when that happens. usually, it's a bit cleaner
>>
>>to make a proposal then move to a vote when there are no remaining
>>
>>objections.
>>
>> 
>>
>>On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:
>>
>>
>>
>>>All,
>>
>>
>>
>>>Outside projects (currently my Syringe project and the "Crispy" project
at
>>
>>
>>>sourceforge) are beginning to want to use Commons Proxy, but are finding
>>
>>it
>>
>>
>>
>>>difficult since it's in the sandbox and no releases are available.  I
>>
>>
>>>believe Proxy's API is close to being ready for a release candidate.
>>
>>
>>>Currently, I don't have any other bright ideas for it, but I'm open to
>>
>>
>>>suggestions.  Moving it to the proper will help us prepare it for an
>>
>>
>>>official release.
>>
>>
>> 
>>
>>being ready for an official release is one of my personal criteria for
>>
>>promotion (so that's good). part of being ready is demonstrating to the
>>
>>community that the committers know how to cut commons releases. 
>>
>> 
>>
>>might i suggest that you cut an example release candidate and upload it
>>
>>to your apache home directory. not only will this speed the time taken
>>
>>to cut the first release (we can spot any problems now rather than
>>
>>later) but it will also give us a better idea of where proxy actually is
>>
>>right now.
>>
>> 
>>
>>- robert
>>
>>
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDUkKRmPuec2Dcv/8RArfbAJ0TfUd0D8Bp5HtRuLD0lCmQz8kK9gCfXbEh
vncqXCrQ5E34qhEhq5qlkeA=
=bldL
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
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: [proxy] Moving Proxy to Commons Proper

[Joerg Hohwiller <jo...@j-hohwiller.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Carman wrote:
> Stephen,
Hi there,

just to give some feedback from me...

In my oppinion commons-proxy is very usefull already as is. So I
want to agree with the initial idea of this thread and would also like to
see it in proper.
> 
> Thank you for taking the time to dig into the code and poke around a bit.
> I'll try to address your questions/concerns here:
> 
> 1.  Logging interceptor using Javassist - it didn't really use Javassist,
> but a method that was in JavassistUtils which returns the "java class name"
> of a class (java class name of Object[] == "java.lang.Object[]").  So, I
> moved that method to ProxyUtils.  That was a good catch.  Thanks!  It would
> be silly to introduce a dependency on Javassist just to log method
> invocations!
> 
> 2.  The ProxyFactory interface could limit you in the future - I don't
> understand what you mean here.  Do you mean because I depend on interfaces
> that I don't have control over (AOP Alliance's MethodInterceptor and the
> JDK's InvocationHandler)?  If so, then I suppose that I could come up with
> my own interfaces and provide "bridge" or "adapter" classes to close the gap
> (I think someone suggested this before, but I forgot about it).  This would
> actually remove *all* required dependencies (other than JDK1.3+) from
> [proxy].  All other dependencies are optional.  If you want to use CGLIB or
> Javassist to create your proxies, you can just include them in your
> classpath.  Maybe I could provide a getInstance() method on ProxyFactory
> which tries to discover which options are available (Javassist, then CGLIB,
> then default to JDK proxies; override using system propery).  What would you
> think about these changes?
I am currently active on commons-logging. We want to extend the API of the
logger. The problem is that extending the existing interface (Log) is not a good
idea, because it is already implemented by third-party code that we can not
control. So if we add new methods to the interface, we will break dependencies.
So we expierence some difficulties in realizing the proposal, even though it is
still possible without breaking dependencies.
The same issue is also causing pain in log4j 1.2 -> 1.3 where the intention was
to prepare for removing legacy stuff in further releases.
So I think Stephen wanted to say that you should think deep about ProxyFactory
and consider if there could be use-cases in the future that may need to change
the interface in any way? There we discussions about the fact that what
commons-proxy does is already done by others. It may help to have a look
there and consolidate the ideas to have a stable API for the future.
I personally think your usage and dependency on AOP-Al. is good and not a
problem, but removing dependencies is never a bad thing. Anyways AOP-Al. aims to
be THE API for that issue and for me it does not make sense to encapsulate this
API. Isn't the idea that you have an AOP-Al. compatible implementation and can
pass those instances directly to commons-proxy?
But I am maybe not deep enough into commons-proxy to see exactly what you
pointed out.
> 
> 3.  Will most users have to write their own code implementing an 
> interface defining in [proxy], or can they just used the existing 
> implementations? - Well, users could use existing AOP Alliance method
> interceptors (like the ones included with Spring, for example).  Other than
> that, if you just want to create proxies for your classes/objects, you don't
> have to implement anything from [proxy].  The core object providers
> (BeanProvider or ConstantProvider) would provide all you need to "plug in."
mhm. Actually I can not see the problem about commons-proxy beeing a wrong
animal here... logging has dependencies on various native-logger
implementations. They are all optional but I think this is almost the same about
commons-proxy.
You might consider to spilt some of the code into sub-projects. Then you can
have the commons-proxy core with almost no dependencies and addintional
sub-projects for cglib stuff, javassist stuff, and the cacho stuff.
This will be very conform with the maven philosophy of projects and dependencies.
The disadvantage is that by default you will not produce a single jar as
artifact by default. Anyways you can still provide this if you want.
> 
> James
Regards
  Jörg

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Saturday, October 15, 2005 8:08 AM
> To: Jakarta Commons Developers List
> Subject: Re: [proxy] Moving Proxy to Commons Proper
> 
> James Carman wrote:
> 
>>Thank you for your feedback (finally somebody said *something*).  I made
>>this a vote based on the instructions found at
>>http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN.
> 
> Maybe
> 
>>we should update that WIKI to suggest making a proposal first and then
>>starting a vote if there are no objections.  I really just wanted to know
> 
> if
> 
>>there were any technical objections to having proxy move into the commons
>>proper so that I could fix the problems.  I would really like to see this
>>become a full-fledged commons component.  I think it's a very useful idea
>>and a pretty intuitive API.
> 
> 
> I took a look this morning, and also thought it could be quite useful, 
> and I could follow reasonably well what was going on.
> 
> Technically, I remember a couple of oddities, although there may be more:
> - the Logging interceptor used Javassist, an odd dependency
> - the core ProxyFactory interface could limit you in the future, as you 
> can't change released interfaces
> 
> The more fundamental question however, is whether this is a true commons 
> component. The sheer number of dependencies is a real question. Now 
> while a lot are probably optional, some will not be.
> 
> This component looks rather like a framework to me, although a very low 
> level framework. Commons does have other components that have interfaces 
> and plugin points, but doesn't this one go further than we've had 
> before? Will most users have to write their own code implementing an 
> interface defining in [proxy], or can they just used the existing 
> implementations?
> 
> Stephen
> 
> 
> 
>>As for your suggestion to cut a release candidate now, I like it.  I do
>>think that I need some simple tutorials/examples on the site before it's
>>ready for a real release, so I'll try to take care of that sometime soon.
>>Then, I'll cut a release candidate, per your suggestion.  I will try to
>>follow the directions found at
>>http://jakarta.apache.org/commons/releases/prepare.html to prepare the
>>release candidate, but I'm probably bound to make mistakes as I'm new to
>>this project management stuff.  I'll probably have a few questions along
> 
> the
> 
>>way too! 
>>
>> 
>>
>>Also, I would still like to hear if anyone else has any suggestions for
>>things that I need to take care of before they would consider it ready for
>>release.  Resolving the 1.5 dependency helped of course, even if it did
> 
> make
> 
>>the API a lot uglier IMHO.  I liked the var-args feature for specifying
> 
> the
> 
>>interfaces/classes that the proxy should support and I would rather use
> 
> the
> 
>>core JDK Executor class rather than the one from the "concurrent" API.  Oh
>>well.
>>
>> 
>>
>>James
>>
>> 
>>
>>-----Original Message-----
>>From: robert burrell donkin [mailto:rdonkin@apache.org] 
>>Sent: Saturday, October 15, 2005 6:28 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [VOTE] Moving Proxy to Commons Proper
>>
>> 
>>
>>hi james
>>
>> 
>>
>>IMO it would be better to make this a proposal. quite often, small
>>
>>changes will are needed and discussion required. votes tend to get a
>>
>>little confused and lost when that happens. usually, it's a bit cleaner
>>
>>to make a proposal then move to a vote when there are no remaining
>>
>>objections.
>>
>> 
>>
>>On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:
>>
>>
>>
>>>All,
>>
>>
>>
>>>Outside projects (currently my Syringe project and the "Crispy" project at
>>
>>
>>>sourceforge) are beginning to want to use Commons Proxy, but are finding
>>
>>it
>>
>>
>>
>>>difficult since it's in the sandbox and no releases are available.  I
>>
>>
>>>believe Proxy's API is close to being ready for a release candidate.
>>
>>
>>>Currently, I don't have any other bright ideas for it, but I'm open to
>>
>>
>>>suggestions.  Moving it to the proper will help us prepare it for an
>>
>>
>>>official release.
>>
>>
>> 
>>
>>being ready for an official release is one of my personal criteria for
>>
>>promotion (so that's good). part of being ready is demonstrating to the
>>
>>community that the committers know how to cut commons releases. 
>>
>> 
>>
>>might i suggest that you cut an example release candidate and upload it
>>
>>to your apache home directory. not only will this speed the time taken
>>
>>to cut the first release (we can spot any problems now rather than
>>
>>later) but it will also give us a better idea of where proxy actually is
>>
>>right now.
>>
>> 
>>
>>- robert
>>
>>
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDUkKRmPuec2Dcv/8RArfbAJ0TfUd0D8Bp5HtRuLD0lCmQz8kK9gCfXbEh
vncqXCrQ5E34qhEhq5qlkeA=
=bldL
-----END PGP SIGNATURE-----

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

RE: [proxy] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

Stephen,

Thank you for taking the time to dig into the code and poke around a bit.
I'll try to address your questions/concerns here:

1.  Logging interceptor using Javassist - it didn't really use Javassist,
but a method that was in JavassistUtils which returns the "java class name"
of a class (java class name of Object[] == "java.lang.Object[]").  So, I
moved that method to ProxyUtils.  That was a good catch.  Thanks!  It would
be silly to introduce a dependency on Javassist just to log method
invocations!

2.  The ProxyFactory interface could limit you in the future - I don't
understand what you mean here.  Do you mean because I depend on interfaces
that I don't have control over (AOP Alliance's MethodInterceptor and the
JDK's InvocationHandler)?  If so, then I suppose that I could come up with
my own interfaces and provide "bridge" or "adapter" classes to close the gap
(I think someone suggested this before, but I forgot about it).  This would
actually remove *all* required dependencies (other than JDK1.3+) from
[proxy].  All other dependencies are optional.  If you want to use CGLIB or
Javassist to create your proxies, you can just include them in your
classpath.  Maybe I could provide a getInstance() method on ProxyFactory
which tries to discover which options are available (Javassist, then CGLIB,
then default to JDK proxies; override using system propery).  What would you
think about these changes?

3.  Will most users have to write their own code implementing an 
interface defining in [proxy], or can they just used the existing 
implementations? - Well, users could use existing AOP Alliance method
interceptors (like the ones included with Spring, for example).  Other than
that, if you just want to create proxies for your classes/objects, you don't
have to implement anything from [proxy].  The core object providers
(BeanProvider or ConstantProvider) would provide all you need to "plug in."

James
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
Sent: Saturday, October 15, 2005 8:08 AM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Moving Proxy to Commons Proper

James Carman wrote:
> Thank you for your feedback (finally somebody said *something*).  I made
> this a vote based on the instructions found at
> http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN.
Maybe
> we should update that WIKI to suggest making a proposal first and then
> starting a vote if there are no objections.  I really just wanted to know
if
> there were any technical objections to having proxy move into the commons
> proper so that I could fix the problems.  I would really like to see this
> become a full-fledged commons component.  I think it's a very useful idea
> and a pretty intuitive API.

I took a look this morning, and also thought it could be quite useful, 
and I could follow reasonably well what was going on.

Technically, I remember a couple of oddities, although there may be more:
- the Logging interceptor used Javassist, an odd dependency
- the core ProxyFactory interface could limit you in the future, as you 
can't change released interfaces

The more fundamental question however, is whether this is a true commons 
component. The sheer number of dependencies is a real question. Now 
while a lot are probably optional, some will not be.

This component looks rather like a framework to me, although a very low 
level framework. Commons does have other components that have interfaces 
and plugin points, but doesn't this one go further than we've had 
before? Will most users have to write their own code implementing an 
interface defining in [proxy], or can they just used the existing 
implementations?

Stephen


> As for your suggestion to cut a release candidate now, I like it.  I do
> think that I need some simple tutorials/examples on the site before it's
> ready for a real release, so I'll try to take care of that sometime soon.
> Then, I'll cut a release candidate, per your suggestion.  I will try to
> follow the directions found at
> http://jakarta.apache.org/commons/releases/prepare.html to prepare the
> release candidate, but I'm probably bound to make mistakes as I'm new to
> this project management stuff.  I'll probably have a few questions along
the
> way too! 
> 
>  
> 
> Also, I would still like to hear if anyone else has any suggestions for
> things that I need to take care of before they would consider it ready for
> release.  Resolving the 1.5 dependency helped of course, even if it did
make
> the API a lot uglier IMHO.  I liked the var-args feature for specifying
the
> interfaces/classes that the proxy should support and I would rather use
the
> core JDK Executor class rather than the one from the "concurrent" API.  Oh
> well.
> 
>  
> 
> James
> 
>  
> 
> -----Original Message-----
> From: robert burrell donkin [mailto:rdonkin@apache.org] 
> Sent: Saturday, October 15, 2005 6:28 AM
> To: Jakarta Commons Developers List
> Subject: Re: [VOTE] Moving Proxy to Commons Proper
> 
>  
> 
> hi james
> 
>  
> 
> IMO it would be better to make this a proposal. quite often, small
> 
> changes will are needed and discussion required. votes tend to get a
> 
> little confused and lost when that happens. usually, it's a bit cleaner
> 
> to make a proposal then move to a vote when there are no remaining
> 
> objections.
> 
>  
> 
> On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:
> 
> 
>>All,
> 
> 
>> 
> 
> 
>>Outside projects (currently my Syringe project and the "Crispy" project at
> 
> 
>>sourceforge) are beginning to want to use Commons Proxy, but are finding
> 
> it
> 
> 
>>difficult since it's in the sandbox and no releases are available.  I
> 
> 
>>believe Proxy's API is close to being ready for a release candidate.
> 
> 
>>Currently, I don't have any other bright ideas for it, but I'm open to
> 
> 
>>suggestions.  Moving it to the proper will help us prepare it for an
> 
> 
>>official release.
> 
> 
>  
> 
> being ready for an official release is one of my personal criteria for
> 
> promotion (so that's good). part of being ready is demonstrating to the
> 
> community that the committers know how to cut commons releases. 
> 
>  
> 
> might i suggest that you cut an example release candidate and upload it
> 
> to your apache home directory. not only will this speed the time taken
> 
> to cut the first release (we can spot any problems now rather than
> 
> later) but it will also give us a better idea of where proxy actually is
> 
> right now.
> 
>  
> 
> - robert
> 
> 

---------------------------------------------------------------------
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: [proxy] Moving Proxy to Commons Proper

[Stephen Colebourne <sc...@btopenworld.com>]

James Carman wrote:
> Thank you for your feedback (finally somebody said *something*).  I made
> this a vote based on the instructions found at
> http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN.  Maybe
> we should update that WIKI to suggest making a proposal first and then
> starting a vote if there are no objections.  I really just wanted to know if
> there were any technical objections to having proxy move into the commons
> proper so that I could fix the problems.  I would really like to see this
> become a full-fledged commons component.  I think it's a very useful idea
> and a pretty intuitive API.

I took a look this morning, and also thought it could be quite useful, 
and I could follow reasonably well what was going on.

Technically, I remember a couple of oddities, although there may be more:
- the Logging interceptor used Javassist, an odd dependency
- the core ProxyFactory interface could limit you in the future, as you 
can't change released interfaces

The more fundamental question however, is whether this is a true commons 
component. The sheer number of dependencies is a real question. Now 
while a lot are probably optional, some will not be.

This component looks rather like a framework to me, although a very low 
level framework. Commons does have other components that have interfaces 
and plugin points, but doesn't this one go further than we've had 
before? Will most users have to write their own code implementing an 
interface defining in [proxy], or can they just used the existing 
implementations?

Stephen


> As for your suggestion to cut a release candidate now, I like it.  I do
> think that I need some simple tutorials/examples on the site before it's
> ready for a real release, so I'll try to take care of that sometime soon.
> Then, I'll cut a release candidate, per your suggestion.  I will try to
> follow the directions found at
> http://jakarta.apache.org/commons/releases/prepare.html to prepare the
> release candidate, but I'm probably bound to make mistakes as I'm new to
> this project management stuff.  I'll probably have a few questions along the
> way too! 
> 
>  
> 
> Also, I would still like to hear if anyone else has any suggestions for
> things that I need to take care of before they would consider it ready for
> release.  Resolving the 1.5 dependency helped of course, even if it did make
> the API a lot uglier IMHO.  I liked the var-args feature for specifying the
> interfaces/classes that the proxy should support and I would rather use the
> core JDK Executor class rather than the one from the "concurrent" API.  Oh
> well.
> 
>  
> 
> James
> 
>  
> 
> -----Original Message-----
> From: robert burrell donkin [mailto:rdonkin@apache.org] 
> Sent: Saturday, October 15, 2005 6:28 AM
> To: Jakarta Commons Developers List
> Subject: Re: [VOTE] Moving Proxy to Commons Proper
> 
>  
> 
> hi james
> 
>  
> 
> IMO it would be better to make this a proposal. quite often, small
> 
> changes will are needed and discussion required. votes tend to get a
> 
> little confused and lost when that happens. usually, it's a bit cleaner
> 
> to make a proposal then move to a vote when there are no remaining
> 
> objections.
> 
>  
> 
> On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:
> 
> 
>>All,
> 
> 
>> 
> 
> 
>>Outside projects (currently my Syringe project and the "Crispy" project at
> 
> 
>>sourceforge) are beginning to want to use Commons Proxy, but are finding
> 
> it
> 
> 
>>difficult since it's in the sandbox and no releases are available.  I
> 
> 
>>believe Proxy's API is close to being ready for a release candidate.
> 
> 
>>Currently, I don't have any other bright ideas for it, but I'm open to
> 
> 
>>suggestions.  Moving it to the proper will help us prepare it for an
> 
> 
>>official release.
> 
> 
>  
> 
> being ready for an official release is one of my personal criteria for
> 
> promotion (so that's good). part of being ready is demonstrating to the
> 
> community that the committers know how to cut commons releases. 
> 
>  
> 
> might i suggest that you cut an example release candidate and upload it
> 
> to your apache home directory. not only will this speed the time taken
> 
> to cut the first release (we can spot any problems now rather than
> 
> later) but it will also give us a better idea of where proxy actually is
> 
> right now.
> 
>  
> 
> - robert
> 
> 

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

RE: [VOTE] Moving Proxy to Commons Proper

[James Carman <ja...@carmanconsulting.com>]

Robert,

 

Thank you for your feedback (finally somebody said *something*).  I made
this a vote based on the instructions found at
http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN.  Maybe
we should update that WIKI to suggest making a proposal first and then
starting a vote if there are no objections.  I really just wanted to know if
there were any technical objections to having proxy move into the commons
proper so that I could fix the problems.  I would really like to see this
become a full-fledged commons component.  I think it's a very useful idea
and a pretty intuitive API.

 

As for your suggestion to cut a release candidate now, I like it.  I do
think that I need some simple tutorials/examples on the site before it's
ready for a real release, so I'll try to take care of that sometime soon.
Then, I'll cut a release candidate, per your suggestion.  I will try to
follow the directions found at
http://jakarta.apache.org/commons/releases/prepare.html to prepare the
release candidate, but I'm probably bound to make mistakes as I'm new to
this project management stuff.  I'll probably have a few questions along the
way too! 

 

Also, I would still like to hear if anyone else has any suggestions for
things that I need to take care of before they would consider it ready for
release.  Resolving the 1.5 dependency helped of course, even if it did make
the API a lot uglier IMHO.  I liked the var-args feature for specifying the
interfaces/classes that the proxy should support and I would rather use the
core JDK Executor class rather than the one from the "concurrent" API.  Oh
well.

 

James

 

-----Original Message-----
From: robert burrell donkin [mailto:rdonkin@apache.org] 
Sent: Saturday, October 15, 2005 6:28 AM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Moving Proxy to Commons Proper

 

hi james

 

IMO it would be better to make this a proposal. quite often, small

changes will are needed and discussion required. votes tend to get a

little confused and lost when that happens. usually, it's a bit cleaner

to make a proposal then move to a vote when there are no remaining

objections.

 

On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:

> All,

>  

> Outside projects (currently my Syringe project and the "Crispy" project at

> sourceforge) are beginning to want to use Commons Proxy, but are finding
it

> difficult since it's in the sandbox and no releases are available.  I

> believe Proxy's API is close to being ready for a release candidate.

> Currently, I don't have any other bright ideas for it, but I'm open to

> suggestions.  Moving it to the proper will help us prepare it for an

> official release.

 

being ready for an official release is one of my personal criteria for

promotion (so that's good). part of being ready is demonstrating to the

community that the committers know how to cut commons releases. 

 

might i suggest that you cut an example release candidate and upload it

to your apache home directory. not only will this speed the time taken

to cut the first release (we can spot any problems now rather than

later) but it will also give us a better idea of where proxy actually is

right now.

 

- robert

Re: [VOTE] Moving Proxy to Commons Proper

[robert burrell donkin <rd...@apache.org>]

hi james

IMO it would be better to make this a proposal. quite often, small
changes will are needed and discussion required. votes tend to get a
little confused and lost when that happens. usually, it's a bit cleaner
to make a proposal then move to a vote when there are no remaining
objections.

On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:
> All,
>  
> Outside projects (currently my Syringe project and the "Crispy" project at
> sourceforge) are beginning to want to use Commons Proxy, but are finding it
> difficult since it's in the sandbox and no releases are available.  I
> believe Proxy's API is close to being ready for a release candidate.
> Currently, I don't have any other bright ideas for it, but I'm open to
> suggestions.  Moving it to the proper will help us prepare it for an
> official release.

being ready for an official release is one of my personal criteria for
promotion (so that's good). part of being ready is demonstrating to the
community that the committers know how to cut commons releases. 

might i suggest that you cut an example release candidate and upload it
to your apache home directory. not only will this speed the time taken
to cut the first release (we can spot any problems now rather than
later) but it will also give us a better idea of where proxy actually is
right now.

- robert