db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: JDO Enhancer Idea from JBoss
Date Tue, 12 Aug 2003 19:02:06 GMT
Yep, that is the problem. If you build your JDO impl around the desire  
to do runtime enhancement it is possible to implement the API in every  
way except the manager.makePeristent(object) where  ((object instanceof  
PersistenceCapable) == true ). You can fake it out by special casing /  
caching all of the "made persistent" objects in the manager and helper  
-- but this is ugly.

This will even work as long as you never try to cast the "made  
persistent" object to PersistenceCapable.

-Brian

On Tuesday, August 12, 2003, at 02:32 PM, Juozas Baliuka wrote:

> Hi,
> There is no way to implement JDO enhancement at runtime (it is  
> inpossible to
> undefine class or define two classes with the same name in the same  
> class
> loader), but you can do it at load time like Jboss doe's (this way  
> needs
> custom class loader).
> There is way to generate subclass at runtime, but it is not supported  
> by JDO
> spec. at this time , XORM and Hibernate use cglib for byte code
> enhancement at runtime, but this way can not be used to implement  
> "standard"
> JDO (runtime/dynamic code generation needs "factory" to create  
> instances and
> JDOImplHelper is not designed for JDO API user code)..
>
> ----- Original Message -----
> From: "Brian McCallister" <mccallister@forthillcompany.com>
> To: "OJB Developers List" <ojb-dev@db.apache.org>
> Sent: Tuesday, August 12, 2003 4:25 PM
> Subject: Re: JDO Enhancer Idea from JBoss
>
>
>> Tilt, I misunderstood soemthing about Aspectwerkz - it *does* do
>> runtime bytecode enhancement! Need to look into this, even if we can't
>> use it, the techniques it uses for enhancement could provide the
>> insight into how to do what we want.
>>
>> -Brian
>>
>> On Tuesday, August 12, 2003, at 10:22 AM, Brian McCallister wrote:
>>
>>> I agree something like this would rock, but without having access to
>>> pre-loaded bytecode you have to use some tricks that I don't think
>>> Java actually supports (hmm, we could port all of J2EE to Ruby...)
>>> such as wrapping a particular instance in a runtime subclass of  
>>> itself
>>> in situ (easy in Ruby, impossible in Java).
>>>
>>> One thing that keeps coming to mind is how Aspect-ish JDO is, how
>>> bytecode enhancement is the preferred means of implementing it, and
>>> Aspectwerkz, ( http://aspectwerkz.codehaus.org/ ) an aspect tool that
>>> works via bytecode enhancement, as compared to AspectJ which is
>>> sourcecode enhancement. It might be an easy way to build a bytecode
>>> enhancer, though as Aspectwerkz is LGPL, we wouldn't be able to
>>> actually use it to make an official bytecode enhancer for OJB
>>> (unfortunately).
>>>
>>> Will think about how to do runtime bytecode enhancement, but without
>>> control over the classloader, I don't think it can be done.
>>>
>>> -Brian
>>>
>>> On Tuesday, August 12, 2003, at 09:32 AM, Alen Ribic wrote:
>>>
>>>> Funny enough, I just had a discussion at our JUG about requirement  
>>>> for
>>>> making things simplified for developers.
>>>> And that was my main example. JBossDO deploy-time enhancer that I
>>>> noticed
>>>> recently. Very simple but very effective. Running a good facade for
>>>> programmer interface to underling subsystems is very important from
>>>> my point
>>>> of view.
>>>>
>>>> I vote +1 for something like this for sure.
>>>>
>>>> 2c from me ;)
>>>> --Alen
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Brian McCallister" <mccallister@forthillcompany.com>
>>>> To: "OJB Developers List" <ojb-dev@db.apache.org>
>>>> Sent: Tuesday, August 12, 2003 3:19 PM
>>>> Subject: JDO Enhancer Idea from JBoss
>>>>
>>>>
>>>>> JBoss did something very interesting with their recent JDO
>>>>> announcement/release. They made it possible to do the enhancement  
>>>>> at
>>>>> deployment time *by the container*. Apparently the container  
>>>>> enhances
>>>>> the classes at deployment time if they are specified in the
>>>>> descriptor
>>>>> to be JDO's.
>>>>>
>>>>> I haven't looked into the details, but this seems like an awfully
>>>>> convenient way to do it. As OJB doesn't provide a managed  
>>>>> environment
>>>>> and have control over classloaders we couldn't do the same thing,  
>>>>> but
>>>>> is quit interesting to see how they did it.
>>>>>
>>>>> -Brian
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------- 
>>>>> --
>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------- 
>>>> -
>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>



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


Mime
View raw message