You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Juozas Baliuka <ba...@centras.lt> on 2002/08/22 18:39:06 UTC
[TOOLS] was Re: [VOTE] (re-vote) XxxUtils constructors
----- Original Message -----
From: "Jack, Paul" <pj...@sfaf.org>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Thursday, August 22, 2002 6:27 PM
Subject: RE: [VOTE] (re-vote) XxxUtils constructors
> > Speaking of compromises, was there any objection to the bean wrapper
> > class idea other than maintenance? If I can eliminate the maintenance
> > from this idea (by volunteering for now, and later to build a tool to
> > automate the process), are there any other objections to the idea?
>
> I'm +1 on you doing all of the actual work. :)
I have a time and I have started this kind of tool implementation :)
It will live in http://cglib.sourceforge.net with "dynamic proxy generator"
I am going to omplement something like this :
Object bean = Enhancer.toBean( Math.class );
context.put( "math", bean );
Object bean2 = Enhancer.toBean( arrayOfStaticMethods );
context.put( "all", bean2 );
Object bean3 = Enhancer.toBean( arrayOfClasses );
context.put( "utils", bean3 );
>
> -Paul
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [TOOLS] was Re: [VOTE] (re-vote) XxxUtils constructors
Posted by Juozas Baliuka <ba...@centras.lt>.
----- Original Message -----
From: "Michael A. Smith" <ma...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, August 22, 2002 7:22 PM
Subject: Re: [TOOLS] was Re: [VOTE] (re-vote) XxxUtils constructors
> On Thu, 22 Aug 2002, Juozas Baliuka wrote:
> > > > Speaking of compromises, was there any objection to the bean wrapper
> > > > class idea other than maintenance? If I can eliminate the
maintenance
> > > > from this idea (by volunteering for now, and later to build a tool
to
> > > > automate the process), are there any other objections to the idea?
> > >
> > > I'm +1 on you doing all of the actual work. :)
> >
> > I have a time and I have started this kind of tool implementation :)
> > It will live in http://cglib.sourceforge.net with "dynamic proxy
generator"
> >
> > I am going to omplement something like this :
> >
> > Object bean = Enhancer.toBean( Math.class );
> >
> > context.put( "math", bean );
>
> This doesn't solve the problem described by those wishing for a public
> constructor. My interpretation is that the bean must be constructed at
> compile time, not at runtime, so that users don't need to do anything
> special to use the wrapper (e.g. have BCEL on the classpath).
>
> In an ironic twist, my plan is to use Velocity to automatically generate
> the bean wrapper as a source code file that is compiled with the
> XxxUtils class.
Yes Velocity is very good for source code generation, I have plans to create
some MACRO ASM for JAVA, based on Velocity.
>
> regards,
> michael
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [TOOLS] was Re: [VOTE] (re-vote) XxxUtils constructors
Posted by "Michael A. Smith" <ma...@apache.org>.
On Thu, 22 Aug 2002, Juozas Baliuka wrote:
> > > Speaking of compromises, was there any objection to the bean wrapper
> > > class idea other than maintenance? If I can eliminate the maintenance
> > > from this idea (by volunteering for now, and later to build a tool to
> > > automate the process), are there any other objections to the idea?
> >
> > I'm +1 on you doing all of the actual work. :)
>
> I have a time and I have started this kind of tool implementation :)
> It will live in http://cglib.sourceforge.net with "dynamic proxy generator"
>
> I am going to omplement something like this :
>
> Object bean = Enhancer.toBean( Math.class );
>
> context.put( "math", bean );
This doesn't solve the problem described by those wishing for a public
constructor. My interpretation is that the bean must be constructed at
compile time, not at runtime, so that users don't need to do anything
special to use the wrapper (e.g. have BCEL on the classpath).
In an ironic twist, my plan is to use Velocity to automatically generate
the bean wrapper as a source code file that is compiled with the
XxxUtils class.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>