You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Olivier Lamy <ol...@apache.org> on 2014/04/11 02:03:18 UTC
Redback core issue with jdk 1.7 as prerequisite
Hi,
So we use a pretty old jpox stack which do bytecode enhancement with bcel.
This generate bad bytecode when compiling with 1.7 (if compiler target 1.7)
Solutions I have in mind:
* stay as today not having 1.7 as prerequisite for redback core
(that's what I just did) (compiler target/source 1.6)
* moving to a new technology (openjpa?)
Regarding the last option, does it mean reusing same database model or
using a new one but with a data migration tooling?
Thoughts?
Cheers
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Redback core issue with jdk 1.7 as prerequisite
Posted by Olivier Lamy <ol...@apache.org>.
I believe as we are really Spring based spring-security sounds a good option :-)
On 14 April 2014 19:34, Eric Barboni <sk...@apache.org> wrote:
> 1.6 fallback is enough for me (for now)
> But If it's time to move to new tech or framework, I'm seriously out of
> knowledge (or rationale) on where to go.
>
> -----Message d'origine-----
> De : Brett Porter [mailto:brett@porterclan.net] De la part de Brett Porter
> Envoyé : vendredi 11 avril 2014 03:02
> À : dev@archiva.apache.org
> Objet : Re: Redback core issue with jdk 1.7 as prerequisite
>
>
> On 11 Apr 2014, at 10:03 am, Olivier Lamy <ol...@apache.org> wrote:
>
>> Hi,
>> So we use a pretty old jpox stack which do bytecode enhancement with bcel.
>> This generate bad bytecode when compiling with 1.7 (if compiler target
>> 1.7)
>>
>> Solutions I have in mind:
>> * stay as today not having 1.7 as prerequisite for redback core
>> (that's what I just did) (compiler target/source 1.6)
>
> Seems the best immediate solution.
>
>> * moving to a new technology (openjpa?)
>>
>> Regarding the last option, does it mean reusing same database model or
>> using a new one but with a data migration tooling?
>>
>> Thoughts?
>
> If you're going to do that amount of work, I think it's worth seriously
> considering if another framework (Shiro, Spring Security) might better fit
> the needs, and either replace Redback or reduce it down to things on top of
> that. But I'm not volunteering :)
>
> - Brett
>
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
RE: Redback core issue with jdk 1.7 as prerequisite
Posted by Eric Barboni <sk...@apache.org>.
1.6 fallback is enough for me (for now)
But If it's time to move to new tech or framework, I'm seriously out of
knowledge (or rationale) on where to go.
-----Message d'origine-----
De : Brett Porter [mailto:brett@porterclan.net] De la part de Brett Porter
Envoyé : vendredi 11 avril 2014 03:02
À : dev@archiva.apache.org
Objet : Re: Redback core issue with jdk 1.7 as prerequisite
On 11 Apr 2014, at 10:03 am, Olivier Lamy <ol...@apache.org> wrote:
> Hi,
> So we use a pretty old jpox stack which do bytecode enhancement with bcel.
> This generate bad bytecode when compiling with 1.7 (if compiler target
> 1.7)
>
> Solutions I have in mind:
> * stay as today not having 1.7 as prerequisite for redback core
> (that's what I just did) (compiler target/source 1.6)
Seems the best immediate solution.
> * moving to a new technology (openjpa?)
>
> Regarding the last option, does it mean reusing same database model or
> using a new one but with a data migration tooling?
>
> Thoughts?
If you're going to do that amount of work, I think it's worth seriously
considering if another framework (Shiro, Spring Security) might better fit
the needs, and either replace Redback or reduce it down to things on top of
that. But I'm not volunteering :)
- Brett
Re: Redback core issue with jdk 1.7 as prerequisite
Posted by Brett Porter <br...@apache.org>.
On 11 Apr 2014, at 10:03 am, Olivier Lamy <ol...@apache.org> wrote:
> Hi,
> So we use a pretty old jpox stack which do bytecode enhancement with bcel.
> This generate bad bytecode when compiling with 1.7 (if compiler target 1.7)
>
> Solutions I have in mind:
> * stay as today not having 1.7 as prerequisite for redback core
> (that's what I just did) (compiler target/source 1.6)
Seems the best immediate solution.
> * moving to a new technology (openjpa?)
>
> Regarding the last option, does it mean reusing same database model or
> using a new one but with a data migration tooling?
>
> Thoughts?
If you're going to do that amount of work, I think it's worth seriously considering if another framework (Shiro, Spring Security) might better fit the needs, and either replace Redback or reduce it down to things on top of that. But I'm not volunteering :)
- Brett