Re: Dynamic code generation [lang] Proposal for *NEXT* version

[Juozas Baliuka <ba...@centras.lt>]

Hi,
I implemented some generator for beans, it is very dirty and generated beans
are not serializable at this time.
It can be used this way :

BeanGenerator generator = new BeanGenerator();// some kind of ClassLoader
// add get/set and private field
generator.addProperty("myProperty", int.class );
generator.addProperties( propertyDescriptors );
// add static methods
generator.addMethod( "mySin", Math.class.getMethod("sin",new
Class[]{double.class} ) );
generator.addMethods( StringUtils.class );
Class beanClass = generator.generate();
 context.put("bean", beanClass.newInstance() );

 can be used as:
  myNumber = bean.mySin(pi)
 in some scripting language.


I have plans to implement generator for BeanInfo too.
It hosted on sourceforge [cglib] at this time
I am not sure it is useful thing, but it can solve some dynamic programing
problems,
like "static utility methods".


>
> +1 on adding a new subproject.
> -0 on calling it "reflection".
>
> Calling it "reflection" will be a bit misleading as it implies
> java.lang.reflect. But what has been discussed so far is more than simply
> providing a "thin" utils on the top of java.lang.reflect.
>
> I'd suggest something like "Meta-Prog", "ClassGenerator", or even
> "Metaclass" (?!).
Code generation is invisible for user and I think it was not good idea to
use
names like "generator". Some java.lang.reflect implementations use code
generation too.

> --
> John
>
>
> At 03:33 pm 08-10-2002, you wrote:
>
> >Agree, [lang] must be minimalist as possible,
> >[lang] is not a very good prefix for this thread.
> >I am thinking about some new subproject it sandbox for reflection.
> >
> >BTW .NET's reflection  has some API like BCEL to genetate code for CLR.
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Juozas Baliuka [mailto:baliuka@centras.lt]
> > > > Sent: Monday, October 07, 2002 11:15 PM
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: [lang] Proposal for *NEXT* version
> > > >
> > > >
> > > > Hi,
> > > > I do not think dependency on top level project is any problem
> > > > for commons
> > > > component, if public API  does's not have classes or
> > > > interfaces from this
> > > > project.
> > >
> > > I disagree. Commons Lang should sit as close to the JDK as possible -
> >that's
> > > really what it's all about. If it starts depending on other packages,
then
> > > it seems to me that it no longer meets its design goals.
> > >
> > > > Projects like BCEL , ORO, Lucene are very good and solve
> > > > common problems
> > > > too.
> > >
> > > Sure, but they do not - and should not - relate to Commons Lang.
> > >
> > > --
> > > Martin Cooper
>
>
> --
> 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>

[latka] [PATCH] responseHeader CVS issues and docs

[Janek Bogucki <ya...@studylink.com>]

Could someone have a look at applying the documentation patch for 
xml-reference.xml which I have posted here

  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13426

The patch adds a section covering responseHeader and updates a couple of 
other bits.

A related issue is described here

  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13390

Basically o.a.c.latka.validators.ResponseHeaderHandler.java and 
ResponseHeaderValidator.java have been removed from the repository but other 
parts of latka assume the validator is present.

Many Thanks,
Janek Bogucki

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>