Re: Random String Generator

[Ralph Daugherty <rdjfc@xxxxxxxxxxxxx>]

Hi Thorbjørn, I am already doing what you are suggesting. The class I 
started with is (as I posted back aways) 
org.apache.myfaces.custom.captcha.util and I am bringing in supporting 
classes for generating a PNG text image twisted based on this. It is 
Apache's robust CAPTCHA logic, unmodified.

I am not concerned about the size of unused code in a jar, if I were I 
would be the only one in IT anymore that was, and I know that 
ClassNotFound won't happen unless class is invoked.

Keeping from invoking unrelated classes is the trick though. I'm not 
interested in that approach, but thanks for the suggestion.

There will be one override or modification in the starting class from 
using HTTPResponseStream to another bytestream output. Other than that, 
code is generated and twisted based on properties, and there are/will be 
calls to change the defaults or generate based on passed in parms.

The key class is CAPTCHAImageGenerator in that package.

Haven't looked any closer than that yet.

 rd


Thorbjørn Ravn Andersen wrote:
> Ralph Daugherty skrev:
> >     The class I started out with was from a midlevel Apache web package 
> > (org.apache.myfaces...) which after all is the whole point of a CAPTCHA. 
> > :) However my goal is a set of calls to return a CAPTCHA via bytestream 
> > or to a file to be available to be merged with output rather than being 
> > called in the JSF code, in other words a generic external source of a 
> > CAPTCHA.
> >
> >   
> If you have an Image it is not hard to get the rest right, so I would 
> suggest focusing on getting that right first just with plain Batik, then 
> other libraries can be leveraged to do the byte stream transformations 
> etc (I've done it in an earlier project).  Doing this from inside JSF is 
> a bit like building a cathedral from the spire and down.
>
> >     I also just want it to be a standalone jar focused on generating 
> > text images, a functioning app callable from RPG without a huge (or 
> > actually any) dependency on many, many other jars that a full Apache 
> > Batik product would require.
> >   
> Fair enough.  Just note that even with a full Batik jar inside, it only 
> loads those classes used, so the difference is only the diskspace used 
> by the jars.
>
> >     It's not like we have many choices, as far as I was able to 
> > determine only Batik and JAI, which has more caveats mentioned with it 
> > than you can shake a stick at.
> >   
> The basic functionality you are after is the "twist letters according to 
> THIS"? 
>
> What is your algorithmic approach?
>
> /Thorbjørn