Re: [VOTE] Drop Java 5 Support in General

[Justin Edelson]

+1


On Thu, Jan 31, 2013 at 5:06 PM, Carsten Ziegeler wrote:

> Deal
>
> Carsten
>
> 2013/1/31 Justin Edelson :
> > Well again, I'm looking at Robert sending an email rather than just
> > creating a patch.
> >
> > How about this - put this information (modules build against Java 5 by
> > default, but feel free to change it by doing XYZ) in the root README.
> >
> > If no one asks about it again, then my concern will have been
> unnecessary.
> > If we get another email like Robert's asking for permission, then we
> > revisit this.
> >
> > WDYT?
> >
> >
> > On Thu, Jan 31, 2013 at 3:24 PM, Carsten Ziegeler  >wrote:
> >
> >> I don't see why this makes contributions harder: develop however you
> >> want and contribute. The only minor thing is, as by default we still
> >> target java 5 for a module and you use java 6, the build will fail,
> >> you update the pom (a single property), build again and are happy. Not
> >> really hard.
> >>
> >> But I don't want to be a road blocker here: if the majority thinks we
> >> should not support Java 5 at all anymore, let's do it.
> >>
> >> Carsten
> >>
> >> 2013/1/31 Justin Edelson :
> >> > I understand the use case, but it just seems like a hassle and makes
> >> > potential contributions like Robert was suggesting harder than they
> need
> >> to
> >> > be.
> >> >
> >> > I want people to be able to checkout the Sling source code and make
> >> changes
> >> > to it and contribute those changes back. I don't want them wasting
> time
> >> > worry about (a) how to write Java 5-compatible code or (b) whether or
> not
> >> > to update the particular module they are interested in to Java 6.
> >> >
> >> > In other words, in the balance between "something that makes it
> easier to
> >> > provide bug fixes for Java 5 users" and "something that makes it
> easier
> >> for
> >> > people to contribute patch", I am thoroughly on the side of the
> latter.
> >> >
> >> > Justin
> >> >
> >> > On Thu, Jan 31, 2013 at 3:07 PM, Carsten Ziegeler <
> cziege...@apache.org
> >> >wrote:
> >> >
> >> >> Yeah, but if I want to fix something let's say in commons scheduler
> >> >> and this is targetted for existing installations using Java 5 and I
> >> >> don't need any Java 5 stuff, why should I have to go through the
> hasle
> >> >> and create my own release just to have a bundle working with Java 5?
> >> >>
> >> >> Having launchpad using Java 6 and only start with Java 6 is pretty
> >> >> fine, using just Java 6 (and higher) for CI builds is fine as well.
> >> >> I'm just talking about individual modules.
> >> >>
> >> >> Carsten
> >> >>
> >> >> 2013/1/31 Felix Meschberger :
> >> >> > Hi
> >> >> >
> >> >> > In reality, the Sling Launchpad will not support Java 5 at all.
> >> >> >
> >> >> > We could just as well have the parent POM setup API checks for
> Java 6
> >> >> and configure the Bundle-RequiredExecutionEnvironment appropriately.
> >> >> >
> >> >> > Regards
> >> >> > Felix
> >> >> >
> >> >> > Am 31.01.2013 um 12:58 schrieb Justin Edelson:
> >> >> >
> >> >> >> -0
> >> >> >>
> >> >> >> Why even try to support Java 5? Let's just say Java 6 as a minimum
> >> >> across
> >> >> >> the board and be done with it.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler <
> >> >> cziege...@apache.org>wrote:
> >> >> >>
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> we see more and more problems with supporting Java 5 and we
> >> discussed
> >> >> >>> this several times in the past year(s?). So let's finally call a
> >> vote
> >> >> >>> and see where we all are.
> >> >> >>>
> >> >> >>> I propose to drop Java 5 support in general - we should try to
> stick
> >> >> >>> to it where possible for supporting existing installations, but
> each
> >> >> >>> module should be free to set the base to Java 6 if it makes
> sense.
> >> >> >>>
> >> >> >>> We should also mark the bundles which require Java 6 (I think
> Felix
> >> >> >>> proposed a way for this some time ago).
> >> >> >>>
> >> >> >>> Please cast your votes :)
> >> >> >>>
> >> >> >>> Regards
> >> >> >>> Carsten
> >> >> >>> --
> >> >> >>> Carsten Ziegeler
> >> >> >>> cziege...@apache.org
> >> >> >>>
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Carsten Ziegeler
> >> >> cziege...@apache.org
> >> >>
> >>
> >>
> >>
> >> --
> >> Carsten Ziegeler
> >> cziege...@apache.org
> >>
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

Re: [VOTE] Drop Java 5 Support in General

[Carsten Ziegeler]

Deal

Carsten

2013/1/31 Justin Edelson :
> Well again, I'm looking at Robert sending an email rather than just
> creating a patch.
>
> How about this - put this information (modules build against Java 5 by
> default, but feel free to change it by doing XYZ) in the root README.
>
> If no one asks about it again, then my concern will have been unnecessary.
> If we get another email like Robert's asking for permission, then we
> revisit this.
>
> WDYT?
>
>
> On Thu, Jan 31, 2013 at 3:24 PM, Carsten Ziegeler wrote:
>
>> I don't see why this makes contributions harder: develop however you
>> want and contribute. The only minor thing is, as by default we still
>> target java 5 for a module and you use java 6, the build will fail,
>> you update the pom (a single property), build again and are happy. Not
>> really hard.
>>
>> But I don't want to be a road blocker here: if the majority thinks we
>> should not support Java 5 at all anymore, let's do it.
>>
>> Carsten
>>
>> 2013/1/31 Justin Edelson :
>> > I understand the use case, but it just seems like a hassle and makes
>> > potential contributions like Robert was suggesting harder than they need
>> to
>> > be.
>> >
>> > I want people to be able to checkout the Sling source code and make
>> changes
>> > to it and contribute those changes back. I don't want them wasting time
>> > worry about (a) how to write Java 5-compatible code or (b) whether or not
>> > to update the particular module they are interested in to Java 6.
>> >
>> > In other words, in the balance between "something that makes it easier to
>> > provide bug fixes for Java 5 users" and "something that makes it easier
>> for
>> > people to contribute patch", I am thoroughly on the side of the latter.
>> >
>> > Justin
>> >
>> > On Thu, Jan 31, 2013 at 3:07 PM, Carsten Ziegeler > >wrote:
>> >
>> >> Yeah, but if I want to fix something let's say in commons scheduler
>> >> and this is targetted for existing installations using Java 5 and I
>> >> don't need any Java 5 stuff, why should I have to go through the hasle
>> >> and create my own release just to have a bundle working with Java 5?
>> >>
>> >> Having launchpad using Java 6 and only start with Java 6 is pretty
>> >> fine, using just Java 6 (and higher) for CI builds is fine as well.
>> >> I'm just talking about individual modules.
>> >>
>> >> Carsten
>> >>
>> >> 2013/1/31 Felix Meschberger :
>> >> > Hi
>> >> >
>> >> > In reality, the Sling Launchpad will not support Java 5 at all.
>> >> >
>> >> > We could just as well have the parent POM setup API checks for Java 6
>> >> and configure the Bundle-RequiredExecutionEnvironment appropriately.
>> >> >
>> >> > Regards
>> >> > Felix
>> >> >
>> >> > Am 31.01.2013 um 12:58 schrieb Justin Edelson:
>> >> >
>> >> >> -0
>> >> >>
>> >> >> Why even try to support Java 5? Let's just say Java 6 as a minimum
>> >> across
>> >> >> the board and be done with it.
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler <
>> >> cziege...@apache.org>wrote:
>> >> >>
>> >> >>> Hi,
>> >> >>>
>> >> >>> we see more and more problems with supporting Java 5 and we
>> discussed
>> >> >>> this several times in the past year(s?). So let's finally call a
>> vote
>> >> >>> and see where we all are.
>> >> >>>
>> >> >>> I propose to drop Java 5 support in general - we should try to stick
>> >> >>> to it where possible for supporting existing installations, but each
>> >> >>> module should be free to set the base to Java 6 if it makes sense.
>> >> >>>
>> >> >>> We should also mark the bundles which require Java 6 (I think Felix
>> >> >>> proposed a way for this some time ago).
>> >> >>>
>> >> >>> Please cast your votes :)
>> >> >>>
>> >> >>> Regards
>> >> >>> Carsten
>> >> >>> --
>> >> >>> Carsten Ziegeler
>> >> >>> cziege...@apache.org
>> >> >>>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Carsten Ziegeler
>> >> cziege...@apache.org
>> >>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: [VOTE] Drop Java 5 Support in General

[Justin Edelson]

Well again, I'm looking at Robert sending an email rather than just
creating a patch.

How about this - put this information (modules build against Java 5 by
default, but feel free to change it by doing XYZ) in the root README.

If no one asks about it again, then my concern will have been unnecessary.
If we get another email like Robert's asking for permission, then we
revisit this.

WDYT?


On Thu, Jan 31, 2013 at 3:24 PM, Carsten Ziegeler wrote:

> I don't see why this makes contributions harder: develop however you
> want and contribute. The only minor thing is, as by default we still
> target java 5 for a module and you use java 6, the build will fail,
> you update the pom (a single property), build again and are happy. Not
> really hard.
>
> But I don't want to be a road blocker here: if the majority thinks we
> should not support Java 5 at all anymore, let's do it.
>
> Carsten
>
> 2013/1/31 Justin Edelson :
> > I understand the use case, but it just seems like a hassle and makes
> > potential contributions like Robert was suggesting harder than they need
> to
> > be.
> >
> > I want people to be able to checkout the Sling source code and make
> changes
> > to it and contribute those changes back. I don't want them wasting time
> > worry about (a) how to write Java 5-compatible code or (b) whether or not
> > to update the particular module they are interested in to Java 6.
> >
> > In other words, in the balance between "something that makes it easier to
> > provide bug fixes for Java 5 users" and "something that makes it easier
> for
> > people to contribute patch", I am thoroughly on the side of the latter.
> >
> > Justin
> >
> > On Thu, Jan 31, 2013 at 3:07 PM, Carsten Ziegeler  >wrote:
> >
> >> Yeah, but if I want to fix something let's say in commons scheduler
> >> and this is targetted for existing installations using Java 5 and I
> >> don't need any Java 5 stuff, why should I have to go through the hasle
> >> and create my own release just to have a bundle working with Java 5?
> >>
> >> Having launchpad using Java 6 and only start with Java 6 is pretty
> >> fine, using just Java 6 (and higher) for CI builds is fine as well.
> >> I'm just talking about individual modules.
> >>
> >> Carsten
> >>
> >> 2013/1/31 Felix Meschberger :
> >> > Hi
> >> >
> >> > In reality, the Sling Launchpad will not support Java 5 at all.
> >> >
> >> > We could just as well have the parent POM setup API checks for Java 6
> >> and configure the Bundle-RequiredExecutionEnvironment appropriately.
> >> >
> >> > Regards
> >> > Felix
> >> >
> >> > Am 31.01.2013 um 12:58 schrieb Justin Edelson:
> >> >
> >> >> -0
> >> >>
> >> >> Why even try to support Java 5? Let's just say Java 6 as a minimum
> >> across
> >> >> the board and be done with it.
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler <
> >> cziege...@apache.org>wrote:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> we see more and more problems with supporting Java 5 and we
> discussed
> >> >>> this several times in the past year(s?). So let's finally call a
> vote
> >> >>> and see where we all are.
> >> >>>
> >> >>> I propose to drop Java 5 support in general - we should try to stick
> >> >>> to it where possible for supporting existing installations, but each
> >> >>> module should be free to set the base to Java 6 if it makes sense.
> >> >>>
> >> >>> We should also mark the bundles which require Java 6 (I think Felix
> >> >>> proposed a way for this some time ago).
> >> >>>
> >> >>> Please cast your votes :)
> >> >>>
> >> >>> Regards
> >> >>> Carsten
> >> >>> --
> >> >>> Carsten Ziegeler
> >> >>> cziege...@apache.org
> >> >>>
> >> >
> >>
> >>
> >>
> >> --
> >> Carsten Ziegeler
> >> cziege...@apache.org
> >>
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

Re: [VOTE] Drop Java 5 Support in General

[Carsten Ziegeler]

2013/1/31 Bertrand Delacretaz :
> On Thu, Jan 31, 2013 at 9:19 PM, Justin Edelson
>  wrote:
>> ...I want people to be able to checkout the Sling source code and make 
>> changes
>> to it and contribute those changes back. I don't want them wasting time
>> worry about (a) how to write Java 5-compatible code or (b) whether or not
>> to update the particular module they are interested in to Java 6
>
> What we can do, and IIUC what Carsten suggests is leave some modules
> on Java 5 for now (setting source=1.5 in pom) if they don't currently
> require Java 6.
>
> Then, if someone has a good reason to move a given module to Java 6,
> do that, maybe with a vote first.

Exactly, though I think no vote is needed.

Carsten

>
> -Bertrand



-- 
Carsten Ziegeler
cziege...@apache.org

Re: [VOTE] Drop Java 5 Support in General

[Bertrand Delacretaz]

On Thu, Jan 31, 2013 at 9:19 PM, Justin Edelson
 wrote:
> ...I want people to be able to checkout the Sling source code and make changes
> to it and contribute those changes back. I don't want them wasting time
> worry about (a) how to write Java 5-compatible code or (b) whether or not
> to update the particular module they are interested in to Java 6

What we can do, and IIUC what Carsten suggests is leave some modules
on Java 5 for now (setting source=1.5 in pom) if they don't currently
require Java 6.

Then, if someone has a good reason to move a given module to Java 6,
do that, maybe with a vote first.

-Bertrand

Re: [VOTE] Drop Java 5 Support in General

[Carsten Ziegeler]

I don't see why this makes contributions harder: develop however you
want and contribute. The only minor thing is, as by default we still
target java 5 for a module and you use java 6, the build will fail,
you update the pom (a single property), build again and are happy. Not
really hard.

But I don't want to be a road blocker here: if the majority thinks we
should not support Java 5 at all anymore, let's do it.

Carsten

2013/1/31 Justin Edelson :
> I understand the use case, but it just seems like a hassle and makes
> potential contributions like Robert was suggesting harder than they need to
> be.
>
> I want people to be able to checkout the Sling source code and make changes
> to it and contribute those changes back. I don't want them wasting time
> worry about (a) how to write Java 5-compatible code or (b) whether or not
> to update the particular module they are interested in to Java 6.
>
> In other words, in the balance between "something that makes it easier to
> provide bug fixes for Java 5 users" and "something that makes it easier for
> people to contribute patch", I am thoroughly on the side of the latter.
>
> Justin
>
> On Thu, Jan 31, 2013 at 3:07 PM, Carsten Ziegeler wrote:
>
>> Yeah, but if I want to fix something let's say in commons scheduler
>> and this is targetted for existing installations using Java 5 and I
>> don't need any Java 5 stuff, why should I have to go through the hasle
>> and create my own release just to have a bundle working with Java 5?
>>
>> Having launchpad using Java 6 and only start with Java 6 is pretty
>> fine, using just Java 6 (and higher) for CI builds is fine as well.
>> I'm just talking about individual modules.
>>
>> Carsten
>>
>> 2013/1/31 Felix Meschberger :
>> > Hi
>> >
>> > In reality, the Sling Launchpad will not support Java 5 at all.
>> >
>> > We could just as well have the parent POM setup API checks for Java 6
>> and configure the Bundle-RequiredExecutionEnvironment appropriately.
>> >
>> > Regards
>> > Felix
>> >
>> > Am 31.01.2013 um 12:58 schrieb Justin Edelson:
>> >
>> >> -0
>> >>
>> >> Why even try to support Java 5? Let's just say Java 6 as a minimum
>> across
>> >> the board and be done with it.
>> >>
>> >>
>> >>
>> >> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler <
>> cziege...@apache.org>wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> we see more and more problems with supporting Java 5 and we discussed
>> >>> this several times in the past year(s?). So let's finally call a vote
>> >>> and see where we all are.
>> >>>
>> >>> I propose to drop Java 5 support in general - we should try to stick
>> >>> to it where possible for supporting existing installations, but each
>> >>> module should be free to set the base to Java 6 if it makes sense.
>> >>>
>> >>> We should also mark the bundles which require Java 6 (I think Felix
>> >>> proposed a way for this some time ago).
>> >>>
>> >>> Please cast your votes :)
>> >>>
>> >>> Regards
>> >>> Carsten
>> >>> --
>> >>> Carsten Ziegeler
>> >>> cziege...@apache.org
>> >>>
>> >
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: [VOTE] Drop Java 5 Support in General

[Justin Edelson]

I understand the use case, but it just seems like a hassle and makes
potential contributions like Robert was suggesting harder than they need to
be.

I want people to be able to checkout the Sling source code and make changes
to it and contribute those changes back. I don't want them wasting time
worry about (a) how to write Java 5-compatible code or (b) whether or not
to update the particular module they are interested in to Java 6.

In other words, in the balance between "something that makes it easier to
provide bug fixes for Java 5 users" and "something that makes it easier for
people to contribute patch", I am thoroughly on the side of the latter.

Justin

On Thu, Jan 31, 2013 at 3:07 PM, Carsten Ziegeler wrote:

> Yeah, but if I want to fix something let's say in commons scheduler
> and this is targetted for existing installations using Java 5 and I
> don't need any Java 5 stuff, why should I have to go through the hasle
> and create my own release just to have a bundle working with Java 5?
>
> Having launchpad using Java 6 and only start with Java 6 is pretty
> fine, using just Java 6 (and higher) for CI builds is fine as well.
> I'm just talking about individual modules.
>
> Carsten
>
> 2013/1/31 Felix Meschberger :
> > Hi
> >
> > In reality, the Sling Launchpad will not support Java 5 at all.
> >
> > We could just as well have the parent POM setup API checks for Java 6
> and configure the Bundle-RequiredExecutionEnvironment appropriately.
> >
> > Regards
> > Felix
> >
> > Am 31.01.2013 um 12:58 schrieb Justin Edelson:
> >
> >> -0
> >>
> >> Why even try to support Java 5? Let's just say Java 6 as a minimum
> across
> >> the board and be done with it.
> >>
> >>
> >>
> >> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler <
> cziege...@apache.org>wrote:
> >>
> >>> Hi,
> >>>
> >>> we see more and more problems with supporting Java 5 and we discussed
> >>> this several times in the past year(s?). So let's finally call a vote
> >>> and see where we all are.
> >>>
> >>> I propose to drop Java 5 support in general - we should try to stick
> >>> to it where possible for supporting existing installations, but each
> >>> module should be free to set the base to Java 6 if it makes sense.
> >>>
> >>> We should also mark the bundles which require Java 6 (I think Felix
> >>> proposed a way for this some time ago).
> >>>
> >>> Please cast your votes :)
> >>>
> >>> Regards
> >>> Carsten
> >>> --
> >>> Carsten Ziegeler
> >>> cziege...@apache.org
> >>>
> >
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

Re: [VOTE] Drop Java 5 Support in General

[Ian Boston]

Would saying we dont "support" Java 5 evidenced by not having a CI
build, but in the modules avoiding using Java6 features (eg
@Overrides) be enough ?

That could still be enforced by keeping source and target to 1.5

It would probably be good to keep the jdk5.properties around in
launchepad so you can spin up a container under 5 to test.
Ian


On 1 February 2013 07:07, Carsten Ziegeler  wrote:
> Yeah, but if I want to fix something let's say in commons scheduler
> and this is targetted for existing installations using Java 5 and I
> don't need any Java 5 stuff, why should I have to go through the hasle
> and create my own release just to have a bundle working with Java 5?
>
> Having launchpad using Java 6 and only start with Java 6 is pretty
> fine, using just Java 6 (and higher) for CI builds is fine as well.
> I'm just talking about individual modules.
>
> Carsten
>
> 2013/1/31 Felix Meschberger :
>> Hi
>>
>> In reality, the Sling Launchpad will not support Java 5 at all.
>>
>> We could just as well have the parent POM setup API checks for Java 6 and 
>> configure the Bundle-RequiredExecutionEnvironment appropriately.
>>
>> Regards
>> Felix
>>
>> Am 31.01.2013 um 12:58 schrieb Justin Edelson:
>>
>>> -0
>>>
>>> Why even try to support Java 5? Let's just say Java 6 as a minimum across
>>> the board and be done with it.
>>>
>>>
>>>
>>> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler 
>>> wrote:
>>>
 Hi,

 we see more and more problems with supporting Java 5 and we discussed
 this several times in the past year(s?). So let's finally call a vote
 and see where we all are.

 I propose to drop Java 5 support in general - we should try to stick
 to it where possible for supporting existing installations, but each
 module should be free to set the base to Java 6 if it makes sense.

 We should also mark the bundles which require Java 6 (I think Felix
 proposed a way for this some time ago).

 Please cast your votes :)

 Regards
 Carsten
 --
 Carsten Ziegeler
 cziege...@apache.org

>>
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org

Re: [VOTE] Drop Java 5 Support in General

[Carsten Ziegeler]

Yeah, but if I want to fix something let's say in commons scheduler
and this is targetted for existing installations using Java 5 and I
don't need any Java 5 stuff, why should I have to go through the hasle
and create my own release just to have a bundle working with Java 5?

Having launchpad using Java 6 and only start with Java 6 is pretty
fine, using just Java 6 (and higher) for CI builds is fine as well.
I'm just talking about individual modules.

Carsten

2013/1/31 Felix Meschberger :
> Hi
>
> In reality, the Sling Launchpad will not support Java 5 at all.
>
> We could just as well have the parent POM setup API checks for Java 6 and 
> configure the Bundle-RequiredExecutionEnvironment appropriately.
>
> Regards
> Felix
>
> Am 31.01.2013 um 12:58 schrieb Justin Edelson:
>
>> -0
>>
>> Why even try to support Java 5? Let's just say Java 6 as a minimum across
>> the board and be done with it.
>>
>>
>>
>> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler 
>> wrote:
>>
>>> Hi,
>>>
>>> we see more and more problems with supporting Java 5 and we discussed
>>> this several times in the past year(s?). So let's finally call a vote
>>> and see where we all are.
>>>
>>> I propose to drop Java 5 support in general - we should try to stick
>>> to it where possible for supporting existing installations, but each
>>> module should be free to set the base to Java 6 if it makes sense.
>>>
>>> We should also mark the bundles which require Java 6 (I think Felix
>>> proposed a way for this some time ago).
>>>
>>> Please cast your votes :)
>>>
>>> Regards
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> cziege...@apache.org
>>>
>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: [VOTE] Drop Java 5 Support in General

[Felix Meschberger]

Hi

In reality, the Sling Launchpad will not support Java 5 at all.

We could just as well have the parent POM setup API checks for Java 6 and 
configure the Bundle-RequiredExecutionEnvironment appropriately.

Regards
Felix

Am 31.01.2013 um 12:58 schrieb Justin Edelson:

> -0
> 
> Why even try to support Java 5? Let's just say Java 6 as a minimum across
> the board and be done with it.
> 
> 
> 
> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler 
> wrote:
> 
>> Hi,
>> 
>> we see more and more problems with supporting Java 5 and we discussed
>> this several times in the past year(s?). So let's finally call a vote
>> and see where we all are.
>> 
>> I propose to drop Java 5 support in general - we should try to stick
>> to it where possible for supporting existing installations, but each
>> module should be free to set the base to Java 6 if it makes sense.
>> 
>> We should also mark the bundles which require Java 6 (I think Felix
>> proposed a way for this some time ago).
>> 
>> Please cast your votes :)
>> 
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>> 

Re: [VOTE] Drop Java 5 Support in General

[Julian Reschke]

On 2013-01-31 19:58, Justin Edelson wrote:

-0

Why even try to support Java 5? Let's just say Java 6 as a minimum across
the board and be done with it.


Indeed.

Or even Java7.

Best regards, Julian

Re: [VOTE] Drop Java 5 Support in General

[Carsten Ziegeler]

If we set Java 6 as the minimum for all modules, this creates
unnecessary work to ship a bugfix or enhancements to users running on
Java 5. And we have a lot of them.
The difference between Java 5 and Java 6 in terms of the languange or
the libraries is not that huge, so I think there is rarely a need to
really require Java 6 for a module. If it does, it's fine - but if not
we should not disable it from running in existing installations per
default

Carsten

2013/1/31 Justin Edelson :
> -0
>
> Why even try to support Java 5? Let's just say Java 6 as a minimum across
> the board and be done with it.
>
>
>
> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler 
> wrote:
>
>> Hi,
>>
>> we see more and more problems with supporting Java 5 and we discussed
>> this several times in the past year(s?). So let's finally call a vote
>> and see where we all are.
>>
>> I propose to drop Java 5 support in general - we should try to stick
>> to it where possible for supporting existing installations, but each
>> module should be free to set the base to Java 6 if it makes sense.
>>
>> We should also mark the bundles which require Java 6 (I think Felix
>> proposed a way for this some time ago).
>>
>> Please cast your votes :)
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: [VOTE] Drop Java 5 Support in General

[Justin Edelson]

-0

Why even try to support Java 5? Let's just say Java 6 as a minimum across
the board and be done with it.



On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler wrote:

> Hi,
>
> we see more and more problems with supporting Java 5 and we discussed
> this several times in the past year(s?). So let's finally call a vote
> and see where we all are.
>
> I propose to drop Java 5 support in general - we should try to stick
> to it where possible for supporting existing installations, but each
> module should be free to set the base to Java 6 if it makes sense.
>
> We should also mark the bundles which require Java 6 (I think Felix
> proposed a way for this some time ago).
>
> Please cast your votes :)
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org
>

RE: [VOTE] Drop Java 5 Support in General

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Thursday, January 31, 2013 5:48 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Drop Java 5 Support in General
> 
> Hi,
> 
> we see more and more problems with supporting Java 5 and we discussed
> this several times in the past year(s?). So let's finally call a vote
> and see where we all are.
> 
> I propose to drop Java 5 support in general - we should try to stick
> to it where possible for supporting existing installations, but each
> module should be free to set the base to Java 6 if it makes sense.
> 
> We should also mark the bundles which require Java 6 (I think Felix
> proposed a way for this some time ago).
> 
> Please cast your votes :)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

[jira] [Commented] (SLING-2166) Make file upload logic configurable

[Andrew Khoury (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567925#comment-13567925
 ] 

Andrew Khoury commented on SLING-2166:
--

It would also be nice to be able to configure allowed content types / file 
extensions.

> Make file upload logic configurable
> ---
>
> Key: SLING-2166
> URL: https://issues.apache.org/jira/browse/SLING-2166
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Chetan Mehrotra
>Priority: Minor
>
> The current file upload logic in Sling Engine (as present in ParameterSupport 
> [1]  class) relies on Common Fileupload. This logic can be enhanced to use 
> some features provided by the Common Fileupload library
> - Allow location of folder where temporary files are created configurable. 
> This can be done by specifying the repository in the DiskFileItemFactory. So 
> for Sling we can set to a folder under launchpad and better manage it
> - Enable the FileCleaningTracker such that any temporary file that gets 
> created also get deleted.
> - Allow specifying the maximum file size that can be uploaded
> - Update the version of file upload library
> Further the FileCleaningTracker can be exposed as a service and used by other 
> components
> [1] 
> http://svn.apache.org/repos/asf/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupport.java
> [2] 
> http://svn.apache.org/repos/asf/commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileCleaningTracker.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Drop Java 5 Support in General

[Ian Boston]

+1
Ian

On Friday, February 1, 2013, Felix Meschberger wrote:

> +1
>
> Thanks/Regards
> Felix
>
> Am 31.01.2013 um 10:47 schrieb Carsten Ziegeler:
>
> > Hi,
> >
> > we see more and more problems with supporting Java 5 and we discussed
> > this several times in the past year(s?). So let's finally call a vote
> > and see where we all are.
> >
> > I propose to drop Java 5 support in general - we should try to stick
> > to it where possible for supporting existing installations, but each
> > module should be free to set the base to Java 6 if it makes sense.
> >
> > We should also mark the bundles which require Java 6 (I think Felix
> > proposed a way for this some time ago).
> >
> > Please cast your votes :)
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > cziege...@apache.org 
>
>

Jenkins build became unstable: sling-trunk-1.6 #1564

[Apache Jenkins Server]

See 

[jira] [Resolved] (SLING-2719) Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-2719.
-

Resolution: Fixed

I rewrote the whole register/unregister code to not hold any locks when calling 
into the framework anymore.

> Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions
> --
>
> Key: SLING-2719
> URL: https://issues.apache.org/jira/browse/SLING-2719
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.0.2
> Environment: JBoss
>Reporter: Chetan Mehrotra
>Assignee: Carsten Ziegeler
>  Labels: deadlock
> Fix For: Resource Resolver 1.0.4
>
> Attachments: error-log-threaddump.zip
>
>
> We are seeing intermittent issues of deadlock while running a Sling based 
> webapp in an app server like JBoss. The deadlock is being seen between the 
> FelixFrameworkWiring and FelixStartLevel threads. 
> For example analyzing the order of locks taken in the threaddump-1.log (shown 
> below). Here the FelixFrameworkWiring thread has the Global bundle lock at 
> Felix level [1] and is waiting for the lock in 
> ResourceResolverFactoryActivator.checkFactoryPreconditions. While the 
> FelixStartLevel thread has the lock on RRF and is waiting for global lock. 
> Thus resulting in a deadlock
> The FelixFrameworkWiring [5] is busy in deactivating components because of a 
> package refresh earlier (which lead to repository getting shutdown and thus 
> triggering deactivation of ResourceResolverFactoryActivator). While the 
> FelixStartLevel [6] thread has activated ResourceResolverFactoryActivator 
> (thus hold the lock) and later requires global lock for some operation.
> Looking at the code for 
> ResourceResolverFactoryActivator.checkFactoryPreconditions [2] it appears to 
> take and hold a lock (on this) while making a call to OSGi container. Such a 
> usage *might* cause issues like deadlock. So it would be better if the 
> ResourceResolverFactoryActivator does not hold any lock while making the call 
> to container services [3]
> "FelixFrameworkWiring"
> - locked <0x0007944da478> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x0007944da9b0> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x0007944dae38> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x000796d5d030> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - waiting to lock <0x00079624ff08> (a 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:330)
> "FelixStartLevel"
> - locked <0x00079624ff08> (a 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:324)
> - locked <0x000796959bc8> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - locked <0x000796959eb8> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - locked <0x00079695a188> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - waiting <0x00079415eca0> (a [Ljava.lang.Object;) 
> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5019)
> [1] This has been confirmed via the value for m_globalLockThread of Felix 
> instance in Heap Dump
> [2] 
> https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverFactoryActivator.java#L313
> [3] http://njbartlett.name/files/osgibook_preview_20091217.pdf (Section 6.4 
> Don’t Hold Locks when Calling Foreign Code)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: h

Re: [VOTE] Drop Java 5 Support in General

[Felix Meschberger]

+1

Thanks/Regards
Felix

Am 31.01.2013 um 10:47 schrieb Carsten Ziegeler:

> Hi,
> 
> we see more and more problems with supporting Java 5 and we discussed
> this several times in the past year(s?). So let's finally call a vote
> and see where we all are.
> 
> I propose to drop Java 5 support in general - we should try to stick
> to it where possible for supporting existing installations, but each
> module should be free to set the base to Java 6 if it makes sense.
> 
> We should also mark the bundles which require Java 6 (I think Felix
> proposed a way for this some time ago).
> 
> Please cast your votes :)
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Drop Java 5 Support in General

[Jeff Young]

+1

Jeff.


> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: 31 January 2013 16:48
> To: dev@sling.apache.org
> Subject: [VOTE] Drop Java 5 Support in General
> 
> Hi,
> 
> we see more and more problems with supporting Java 5 and we discussed
> this several times in the past year(s?). So let's finally call a vote
> and see where we all are.
> 
> I propose to drop Java 5 support in general - we should try to stick
> to it where possible for supporting existing installations, but each
> module should be free to set the base to Java 6 if it makes sense.
> 
> We should also mark the bundles which require Java 6 (I think Felix
> proposed a way for this some time ago).
> 
> Please cast your votes :)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

[jira] [Updated] (SLING-2719) Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-2719:


Fix Version/s: Resource Resolver 1.0.4

> Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions
> --
>
> Key: SLING-2719
> URL: https://issues.apache.org/jira/browse/SLING-2719
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.0.2
> Environment: JBoss
>Reporter: Chetan Mehrotra
>Assignee: Carsten Ziegeler
>  Labels: deadlock
> Fix For: Resource Resolver 1.0.4
>
> Attachments: error-log-threaddump.zip
>
>
> We are seeing intermittent issues of deadlock while running a Sling based 
> webapp in an app server like JBoss. The deadlock is being seen between the 
> FelixFrameworkWiring and FelixStartLevel threads. 
> For example analyzing the order of locks taken in the threaddump-1.log (shown 
> below). Here the FelixFrameworkWiring thread has the Global bundle lock at 
> Felix level [1] and is waiting for the lock in 
> ResourceResolverFactoryActivator.checkFactoryPreconditions. While the 
> FelixStartLevel thread has the lock on RRF and is waiting for global lock. 
> Thus resulting in a deadlock
> The FelixFrameworkWiring [5] is busy in deactivating components because of a 
> package refresh earlier (which lead to repository getting shutdown and thus 
> triggering deactivation of ResourceResolverFactoryActivator). While the 
> FelixStartLevel [6] thread has activated ResourceResolverFactoryActivator 
> (thus hold the lock) and later requires global lock for some operation.
> Looking at the code for 
> ResourceResolverFactoryActivator.checkFactoryPreconditions [2] it appears to 
> take and hold a lock (on this) while making a call to OSGi container. Such a 
> usage *might* cause issues like deadlock. So it would be better if the 
> ResourceResolverFactoryActivator does not hold any lock while making the call 
> to container services [3]
> "FelixFrameworkWiring"
> - locked <0x0007944da478> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x0007944da9b0> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x0007944dae38> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x000796d5d030> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - waiting to lock <0x00079624ff08> (a 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:330)
> "FelixStartLevel"
> - locked <0x00079624ff08> (a 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:324)
> - locked <0x000796959bc8> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - locked <0x000796959eb8> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - locked <0x00079695a188> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - waiting <0x00079415eca0> (a [Ljava.lang.Object;) 
> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5019)
> [1] This has been confirmed via the value for m_globalLockThread of Felix 
> instance in Heap Dump
> [2] 
> https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverFactoryActivator.java#L313
> [3] http://njbartlett.name/files/osgibook_preview_20091217.pdf (Section 6.4 
> Don’t Hold Locks when Calling Foreign Code)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Drop Java 5 Support in General

[Antonio Sanso]

+1

Antonio

On Jan 31, 2013, at 5:47 PM, Carsten Ziegeler wrote:

> Hi,
> 
> we see more and more problems with supporting Java 5 and we discussed
> this several times in the past year(s?). So let's finally call a vote
> and see where we all are.
> 
> I propose to drop Java 5 support in general - we should try to stick
> to it where possible for supporting existing installations, but each
> module should be free to set the base to Java 6 if it makes sense.
> 
> We should also mark the bundles which require Java 6 (I think Felix
> proposed a way for this some time ago).
> 
> Please cast your votes :)
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> cziege...@apache.org

Re: [VOTE] Drop Java 5 Support in General

[Carsten Ziegeler]

+1

Carsten

2013/1/31 Carsten Ziegeler :
> Hi,
>
> we see more and more problems with supporting Java 5 and we discussed
> this several times in the past year(s?). So let's finally call a vote
> and see where we all are.
>
> I propose to drop Java 5 support in general - we should try to stick
> to it where possible for supporting existing installations, but each
> module should be free to set the base to Java 6 if it makes sense.
>
> We should also mark the bundles which require Java 6 (I think Felix
> proposed a way for this some time ago).
>
> Please cast your votes :)
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org



-- 
Carsten Ziegeler
cziege...@apache.org

Re: [VOTE] Drop Java 5 Support in General

[Bertrand Delacretaz]

On Thu, Jan 31, 2013 at 5:47 PM, Carsten Ziegeler  wrote:
> ...I propose to drop Java 5 support in general - we should try to stick
> to it where possible for supporting existing installations, but each
> module should be free to set the base to Java 6 if it makes sense

That was quick..+1

-Bertrand

[VOTE] Drop Java 5 Support in General

[Carsten Ziegeler]

Hi,

we see more and more problems with supporting Java 5 and we discussed
this several times in the past year(s?). So let's finally call a vote
and see where we all are.

I propose to drop Java 5 support in general - we should try to stick
to it where possible for supporting existing installations, but each
module should be free to set the base to Java 6 if it makes sense.

We should also mark the bundles which require Java 6 (I think Felix
proposed a way for this some time ago).

Please cast your votes :)

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

Re: Writing a Java 6-only integration test

[Bertrand Delacretaz]

On Thu, Jan 31, 2013 at 5:42 PM, Felix Meschberger  wrote:
> ...I think we discussed this already. But maybe we should just come to a 
> conclusion, that Sling requires Java 6

We could probably use JUnit categories to segregate tests...but I was
going to say the exact same thing, it's probably safe to drop Java 5
now.

-Bertrand

Re: Writing a Java 6-only integration test

[Felix Meschberger]

Hi

I think we discussed this already. But maybe we should just come to a 
conclusion, that Sling requires Java 6.

WDYT ?

Regards
Felix

Am 31.01.2013 um 10:39 schrieb Robert Munteanu:

> Hi,
> 
> I've noticed that JAXB marshaling works out of the box, given that the proper 
> framework extension bundles are available. Since IIUC this has been a tricky 
> issue, I'd like to make sure that we keep this functionality working, by 
> creating an integration test.
> 
> I wanted to add it to org.apache.sling.launchpad.test-services, but that 
> project requires Java 1.5, and JAXB and its annotations are only present in 
> Java 1.6 and later. What would be the best way to set up a Java 1.6-only 
> integration test?
> 
> Robert

Writing a Java 6-only integration test

[Robert Munteanu]

Hi,

I've noticed that JAXB marshaling works out of the box, given that the proper 
framework extension bundles are available. Since IIUC this has been a tricky 
issue, I'd like to make sure that we keep this functionality working, by 
creating an integration test.

I wanted to add it to org.apache.sling.launchpad.test-services, but that 
project requires Java 1.5, and JAXB and its annotations are only present in 
Java 1.6 and later. What would be the best way to set up a Java 1.6-only 
integration test?

Robert

[jira] [Assigned] (SLING-2719) Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned SLING-2719:
---

Assignee: Carsten Ziegeler

> Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions
> --
>
> Key: SLING-2719
> URL: https://issues.apache.org/jira/browse/SLING-2719
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.0.2
> Environment: JBoss
>Reporter: Chetan Mehrotra
>Assignee: Carsten Ziegeler
>  Labels: deadlock
> Attachments: error-log-threaddump.zip
>
>
> We are seeing intermittent issues of deadlock while running a Sling based 
> webapp in an app server like JBoss. The deadlock is being seen between the 
> FelixFrameworkWiring and FelixStartLevel threads. 
> For example analyzing the order of locks taken in the threaddump-1.log (shown 
> below). Here the FelixFrameworkWiring thread has the Global bundle lock at 
> Felix level [1] and is waiting for the lock in 
> ResourceResolverFactoryActivator.checkFactoryPreconditions. While the 
> FelixStartLevel thread has the lock on RRF and is waiting for global lock. 
> Thus resulting in a deadlock
> The FelixFrameworkWiring [5] is busy in deactivating components because of a 
> package refresh earlier (which lead to repository getting shutdown and thus 
> triggering deactivation of ResourceResolverFactoryActivator). While the 
> FelixStartLevel [6] thread has activated ResourceResolverFactoryActivator 
> (thus hold the lock) and later requires global lock for some operation.
> Looking at the code for 
> ResourceResolverFactoryActivator.checkFactoryPreconditions [2] it appears to 
> take and hold a lock (on this) while making a call to OSGi container. Such a 
> usage *might* cause issues like deadlock. So it would be better if the 
> ResourceResolverFactoryActivator does not hold any lock while making the call 
> to container services [3]
> "FelixFrameworkWiring"
> - locked <0x0007944da478> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x0007944da9b0> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x0007944dae38> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x000796d5d030> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - waiting to lock <0x00079624ff08> (a 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:330)
> "FelixStartLevel"
> - locked <0x00079624ff08> (a 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:324)
> - locked <0x000796959bc8> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - locked <0x000796959eb8> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - locked <0x00079695a188> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - waiting <0x00079415eca0> (a [Ljava.lang.Object;) 
> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5019)
> [1] This has been confirmed via the value for m_globalLockThread of Felix 
> instance in Heap Dump
> [2] 
> https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverFactoryActivator.java#L313
> [3] http://njbartlett.name/files/osgibook_preview_20091217.pdf (Section 6.4 
> Don’t Hold Locks when Calling Foreign Code)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (SLING-2720) Update exported versions for extension fragments to match well-known JAX-WS, JAXB, StAX and JAF versions

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated SLING-2720:
---

Attachment: SLING-2720.patch

> Update exported versions for extension fragments to match well-known JAX-WS, 
> JAXB, StAX and JAF versions
> 
>
> Key: SLING-2720
> URL: https://issues.apache.org/jira/browse/SLING-2720
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Framework Extension Fragment WS 1.0.0, Framework 
> Extension Fragment XML 1.0.0, Framework Extension Fragment Activation 1.0.0
>Reporter: Robert Munteanu
> Attachments: SLING-2720.patch
>
>
> The framework extension packages currently export their packages versioned as 
> 0.0.0_fragment_qualifier. However, some third-party OSGi bundles, notably CXF 
> [1] require specific versions. One example is Jax-WS 2.1.0 or newer.
> To fix this, I propose that we export the packages with well-known package 
> versions for versions which are easily identifiable. The versions are 
> proposed based on specific documentation outlining the inclusion of these 
> frameworks in Java 6 [2], [3] . Also, based on a bug report[4] I have 
> inferred that the StAX version available in Java 6 ( FCS, later updates have 
> newer packages ) is 1.0.0.
> - JAX-WS 2.1, packages
> javax.xml.ws
> javax.xml.ws.handler
> javax.xml.ws.handler.soap
> javax.xml.ws.http
> javax.xml.ws.soap
> javax.xml.ws.spi
> javax.xml.ws.spi.http
> javax.xml.ws.wsaddressing
> - JAXB 2.1 packages
> javax.xml.bind
> javax.xml.bind.annotation
> javax.xml.bind.annotation.adapters
> javax.xml.bind.attachment
> javax.xml.bind.helpers
> javax.xml.bind.util
> javax.xml.datatype
> - STAX 1.0 packages
> javax.xml.stream
> javax.xml.stream.events
> javax.xml.stream.util
> - JAF packages
> javax.activation
> [1]: http://cxf.apache.org/dosgi-releases.html
> [2]: http://jax-ws.java.net/2.2.7/docs/ch02.html#installation-instructions
> [3]: http://www.oracle.com/technetwork/java/javase/downloads/index-135046.html
> [4]: http://bugs.sun.com/view_bug.do?bug_id=6861589

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SLING-2720) Update exported versions for extension fragments to match well-known JAX-WS, JAXB, StAX and JAF versions

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-2720:
--

 Summary: Update exported versions for extension fragments to match 
well-known JAX-WS, JAXB, StAX and JAF versions
 Key: SLING-2720
 URL: https://issues.apache.org/jira/browse/SLING-2720
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Framework Extension Fragment Activation 1.0.0, Framework 
Extension Fragment XML 1.0.0, Framework Extension Fragment WS 1.0.0
Reporter: Robert Munteanu
 Attachments: SLING-2720.patch

The framework extension packages currently export their packages versioned as 
0.0.0_fragment_qualifier. However, some third-party OSGi bundles, notably CXF 
[1] require specific versions. One example is Jax-WS 2.1.0 or newer.

To fix this, I propose that we export the packages with well-known package 
versions for versions which are easily identifiable. The versions are proposed 
based on specific documentation outlining the inclusion of these frameworks in 
Java 6 [2], [3] . Also, based on a bug report[4] I have inferred that the StAX 
version available in Java 6 ( FCS, later updates have newer packages ) is 1.0.0.

- JAX-WS 2.1, packages

javax.xml.ws
javax.xml.ws.handler
javax.xml.ws.handler.soap
javax.xml.ws.http
javax.xml.ws.soap
javax.xml.ws.spi
javax.xml.ws.spi.http
javax.xml.ws.wsaddressing

- JAXB 2.1 packages

javax.xml.bind
javax.xml.bind.annotation
javax.xml.bind.annotation.adapters
javax.xml.bind.attachment
javax.xml.bind.helpers
javax.xml.bind.util
javax.xml.datatype

- STAX 1.0 packages

javax.xml.stream
javax.xml.stream.events
javax.xml.stream.util

- JAF packages

javax.activation

[1]: http://cxf.apache.org/dosgi-releases.html
[2]: http://jax-ws.java.net/2.2.7/docs/ch02.html#installation-instructions
[3]: http://www.oracle.com/technetwork/java/javase/downloads/index-135046.html
[4]: http://bugs.sun.com/view_bug.do?bug_id=6861589

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (SLING-2719) Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions

[Chetan Mehrotra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chetan Mehrotra updated SLING-2719:
---

Attachment: error-log-threaddump.zip

Attached is a zip which contains the two set of logs

1. threaddump-X.log
2. error-log-X.log

The two sets are taken from two different system where the issue has been 
observed so far

> Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions
> --
>
> Key: SLING-2719
> URL: https://issues.apache.org/jira/browse/SLING-2719
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.0.2
> Environment: JBoss
>Reporter: Chetan Mehrotra
>  Labels: deadlock
> Attachments: error-log-threaddump.zip
>
>
> We are seeing intermittent issues of deadlock while running a Sling based 
> webapp in an app server like JBoss. The deadlock is being seen between the 
> FelixFrameworkWiring and FelixStartLevel threads. 
> For example analyzing the order of locks taken in the threaddump-1.log (shown 
> below). Here the FelixFrameworkWiring thread has the Global bundle lock at 
> Felix level [1] and is waiting for the lock in 
> ResourceResolverFactoryActivator.checkFactoryPreconditions. While the 
> FelixStartLevel thread has the lock on RRF and is waiting for global lock. 
> Thus resulting in a deadlock
> The FelixFrameworkWiring [5] is busy in deactivating components because of a 
> package refresh earlier (which lead to repository getting shutdown and thus 
> triggering deactivation of ResourceResolverFactoryActivator). While the 
> FelixStartLevel [6] thread has activated ResourceResolverFactoryActivator 
> (thus hold the lock) and later requires global lock for some operation.
> Looking at the code for 
> ResourceResolverFactoryActivator.checkFactoryPreconditions [2] it appears to 
> take and hold a lock (on this) while making a call to OSGi container. Such a 
> usage *might* cause issues like deadlock. So it would be better if the 
> ResourceResolverFactoryActivator does not hold any lock while making the call 
> to container services [3]
> "FelixFrameworkWiring"
> - locked <0x0007944da478> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x0007944da9b0> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x0007944dae38> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - locked <0x000796d5d030> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
> - waiting to lock <0x00079624ff08> (a 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:330)
> "FelixStartLevel"
> - locked <0x00079624ff08> (a 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:324)
> - locked <0x000796959bc8> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - locked <0x000796959eb8> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - locked <0x00079695a188> (a java.util.concurrent.atomic.AtomicReference) 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
> - waiting <0x00079415eca0> (a [Ljava.lang.Object;) 
> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5019)
> [1] This has been confirmed via the value for m_globalLockThread of Felix 
> instance in Heap Dump
> [2] 
> https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverFactoryActivator.java#L313
> [3] http://njbartlett.name/files/osgibook_preview_20091217.pdf (Section 6.4 
> Don’t Hold Locks when Calling Foreign Code)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

[jira] [Created] (SLING-2719) Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-2719:
--

 Summary: Deadlock in 
ResourceResolverFactoryActivator.checkFactoryPreconditions
 Key: SLING-2719
 URL: https://issues.apache.org/jira/browse/SLING-2719
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.0.2
 Environment: JBoss
Reporter: Chetan Mehrotra


We are seeing intermittent issues of deadlock while running a Sling based 
webapp in an app server like JBoss. The deadlock is being seen between the 
FelixFrameworkWiring and FelixStartLevel threads. 

For example analyzing the order of locks taken in the threaddump-1.log (shown 
below). Here the FelixFrameworkWiring thread has the Global bundle lock at 
Felix level [1] and is waiting for the lock in 
ResourceResolverFactoryActivator.checkFactoryPreconditions. While the 
FelixStartLevel thread has the lock on RRF and is waiting for global lock. Thus 
resulting in a deadlock

The FelixFrameworkWiring [5] is busy in deactivating components because of a 
package refresh earlier (which lead to repository getting shutdown and thus 
triggering deactivation of ResourceResolverFactoryActivator). While the 
FelixStartLevel [6] thread has activated ResourceResolverFactoryActivator (thus 
hold the lock) and later requires global lock for some operation.

Looking at the code for 
ResourceResolverFactoryActivator.checkFactoryPreconditions [2] it appears to 
take and hold a lock (on this) while making a call to OSGi container. Such a 
usage *might* cause issues like deadlock. So it would be better if the 
ResourceResolverFactoryActivator does not hold any lock while making the call 
to container services [3]


"FelixFrameworkWiring"
- locked <0x0007944da478> (a java.util.concurrent.atomic.AtomicReference) 
org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
- locked <0x0007944da9b0> (a java.util.concurrent.atomic.AtomicReference) 
org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
- locked <0x0007944dae38> (a java.util.concurrent.atomic.AtomicReference) 
org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
- locked <0x000796d5d030> (a java.util.concurrent.atomic.AtomicReference) 
org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
- waiting to lock <0x00079624ff08> (a 
org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:330)

"FelixStartLevel"
- locked <0x00079624ff08> (a 
org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator) 
org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:324)
- locked <0x000796959bc8> (a java.util.concurrent.atomic.AtomicReference) 
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
- locked <0x000796959eb8> (a java.util.concurrent.atomic.AtomicReference) 
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
- locked <0x00079695a188> (a java.util.concurrent.atomic.AtomicReference) 
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:660)
- waiting <0x00079415eca0> (a [Ljava.lang.Object;) 
org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5019)

[1] This has been confirmed via the value for m_globalLockThread of Felix 
instance in Heap Dump
[2] 
https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverFactoryActivator.java#L313
[3] http://njbartlett.name/files/osgibook_preview_20091217.pdf (Section 6.4 
Don’t Hold Locks when Calling Foreign Code)



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SLING-2719) Deadlock in ResourceResolverFactoryActivator.checkFactoryPreconditions

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567643#comment-13567643
 ] 

Chetan Mehrotra commented on SLING-2719:


Thread stacks referred in notes
[5]
"FelixFrameworkWiring" daemon prio=6 tid=0x09749000 nid=0xfd4 waiting 
for monitor entry [0x38bcb000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.checkFactoryPreconditions(ResourceResolverFactoryActivator.java:330)
- waiting to lock <0x00079624ff08> (a 
org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverFactoryActivator.unbindResourceProviderFactory(ResourceResolverFactoryActivator.java:371)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:236)
at 
org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
at 
org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:613)
at 
org.apache.felix.scr.impl.helper.BaseMethod$NotResolved.invoke(BaseMethod.java:572)
at 
org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:496)
at 
org.apache.felix.scr.impl.helper.BindMethod.invoke(BindMethod.java:38)
at 
org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1404)
at 
org.apache.felix.scr.impl.manager.ImmediateComponentManager.invokeUnbindMethod(ImmediateComponentManager.java:327)
at 
org.apache.felix.scr.impl.manager.DependencyManager.serviceRemoved(DependencyManager.java:530)
at 
org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:274)
at 
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at 
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at 
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4335)
at org.apache.felix.framework.Felix.access$000(Felix.java:74)
at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
at 
org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:148)
at 
org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
- locked <0x000796d5d030> (a 
java.util.concurrent.atomic.AtomicReference)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager$State.doDeactivate(AbstractComponentManager.java:1301)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1599)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:555)
at 
org.apache.felix.scr.impl.manager.DependencyManager.serviceRemoved(DependencyManager.java:451)
at 
org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:274)
at 
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at 
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at 
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4335)
at org.apache.felix.framework.Felix.access$000(Felix.java:74)
at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
at 
org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:148)
at 
org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
at 
com.day.crx.sling.server.impl.jmx.ManagedRepository.deactivate(ManagedRepository.java:328)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.felix.scr.impl.help