Well, I think #1 will work for me. But #2 is definately more flexible.
Thomas Mahler wrote:
> That's not yet possible!
>
> Please have a look at the VirtualProxy class. It has a static factory
> method:
>
> public static Object createProxy(Class proxyClass, Identity
> realSubjectsIdentity)
> {
> try
> {
> // the invocation handler manages all delegation stuff
> InvocationHandler handler = new
> IndirectionHandler(realSubjectsIdentity);
>
> // the proxy provides the interface of the real subject
> Constructor constructor = proxyClass.getDeclaredConstructor(
> new Class[]{ InvocationHandler.class });
> Object result = constructor.newInstance(
> new Object[]{ handler });
> return result;
> }
> catch(Exception ex)
> {
> throw new PersistenceBrokerException("Unable to create
> proxy using class:"+proxyClass,ex);
> }
> }
>
> This factory method is used for dynamic *and* manually programmed
> proxies as well. It will also work fine for your stuff.
>
> The important part is the construction of the InvocationHandler !
>
> We could
> 1. have a configuration entry in OJB.properties to globally set the
> InvocationHandler class to be used.
>
> 2. make this configurable per class and add it to the repository.xml.
>
> I vote for 1. as this will be much easier to implement and does bring
> no *real* disadvantages.
>
> cheers,
> Thomas
>
> David Corbin wrote:
>
>> Is there anyway to tell OJB that I want to use a proxy, but instead
>> of specifying the class, I provide a classFactory? For the path
>> we've started down, I'd like to write my own dynamic proxy, but I
>> can't see anyway to tie it into the repository specification.
>>
>> Thanks.
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail:
>> <mailto:[EMAIL PROTECTED]>
>>
>>
>>
>>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
