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: [OT] JDO Enhancer Idea from JBoss
Date Wed, 13 Aug 2003 14:43:42 GMT
BSD style licenses (ie Artistic, Ruby, BSD, etc) and public domain  
software.

-Brian

On Wednesday, August 13, 2003, at 10:31 AM, Alen Ribic wrote:

> Oh, I see what you mean by LGPL viral nature in this case.
> While I'm at the site, I'll read the rest of relevant license issues  
> to get
> a better idea.
>
> So 3rd party tool wise, what tools/libraries can one potentially use in
> project to conform to ASF acceptance?
>
> --Alen
>
>
> ----- Original Message -----
> From: "Weaver, Scott" <Sweaver@rippe.com>
> To: "'OJB Developers List'" <ojb-dev@db.apache.org>
> Sent: Wednesday, August 13, 2003 3:35 PM
> Subject: RE: JDO Enhancer Idea from JBoss
>
>
> LGPL is not allowed in java-based Apache projects due the viral nature  
> of
> the LGPL when it is used within java.
>
> http://www.fsf.org/licenses/lgpl.html
>
> Look at section 6 of the license.  This section provides for the  
> possibility
> that proprietary applications using OJB could be infected with  
> LGPLness due
> to the dynamic linking nature of the java language.
>
> Regards,
> *===================================*
> * Scott T Weaver *
> * Jakarta Jetspeed Portal Project *
> * weaver@apache.org *
> *===================================*
>
>
>
>> -----Original Message-----
>> From: Alen Ribic [mailto:alenr@mweb.co.za]
>> Sent: Wednesday, August 13, 2003 9:18 AM
>> To: OJB Developers List
>> Subject: Re: JDO Enhancer Idea from JBoss
>>
>> I noticed that JBoss uses Javassist in their JDO enhancer.
>> License wise, I'm not to clued up in this department.
>> I didn't even know that Javassist was submitted to JBoss.
>> What are the rules around LGPL use anyway? ;)
>>
>> --Alen
>>
>>
>>
>> ----- Original Message -----
>> From: "Brian McCallister" <mccallister@forthillcompany.com>
>> To: "OJB Developers List" <ojb-dev@db.apache.org>
>> Sent: Wednesday, August 13, 2003 3:07 PM
>> Subject: Re: JDO Enhancer Idea from JBoss
>>
>>
>>> Javassist looks good, concerns are license related. What are ASF  
>>> rules
>>> regarding Mozilla Public License (MPL)? Right now Javassist is
>>> distributed as MPL and LGPL, but I suspect it will be LGPL only  
>>> before
>>> long as it was just subsumed into JBoss.
>>>
>>> -Brian
>>>
>>> On Wednesday, August 13, 2003, at 07:03 AM, Alen Ribic wrote:
>>>
>>>> Javassist might be another lib to take a look at for bytecode level
>>>> manipulation.
>>>> http://www.csg.is.titech.ac.jp/~chiba/javassist/
>>>>
>>>> --Alen
>>>>
>>>>
>>>> ----- 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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