date:20130322

Re: Determining code coverage with Pax Exam

2013-03-22 Thread Achim Nierbeck

Hi,

you should ask this at the ops4j community.
Or try to search for this at the ops4j Google group.

regards, Achim

sent from mobile device
Am 22.03.2013 06:07 schrieb "Chetan Mehrotra" :

> Hi,
>
> This query is not related to Felix but I just wanted to check if any of the
> projects have used any Code Coverage tool with Pax Exam.
>
> I am adding integration test for the JAAS module and was looking for a way
> to measure code coverage. So any pointers around that would be helpful.
>
> Chetan Mehrotra
>

[jira] [Resolved] (FELIX-3989) Add support for determining code coverage with integration testcases

2013-03-22 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra resolved FELIX-3989.


   Resolution: Fixed
Fix Version/s: jaas-0.0.2

Added support for collecting code coverage via JoCoCo [1] with rev 1459658.

For now the stats are 

[INFO] --- jacoco-maven-plugin:0.6.2.201302030002:check (check) @ 
org.apache.felix.jaas ---
[WARNING] Insufficient code coverage for INSTRUCTION: 59.30% < 90.00%
[WARNING] Insufficient code coverage for BRANCH: 45.20% < 85.00%
[WARNING] Insufficient code coverage for LINE: 59.35% < 90.00%
[WARNING] Insufficient code coverage for COMPLEXITY: 54.45% < 85.00%
[WARNING] Insufficient code coverage for METHOD: 69.49% < 95.00%
[WARNING] Insufficient code coverage for CLASS: 95.00% < 100.00%

Test case are being added as part of FELIX-3935 and that would be used to track 
the coverage.

[1] http://www.eclemma.org/jacoco/trunk/index.html

> Add support for determining code coverage with integration testcases
> 
>
> Key: FELIX-3989
> URL: https://issues.apache.org/jira/browse/FELIX-3989
> Project: Felix
>  Issue Type: Task
>  Components: JAAS
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-0.0.2
>
>
> It would be good to have a report generated for determining the code coverage 
> of the integration test run by Pax Exam

--
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: Determining code coverage with Pax Exam

2013-03-22 Thread Chetan Mehrotra

I got it working with JoCoCo [1]. So problem is solved for now.

[1] http://www.eclemma.org/jacoco/trunk/index.html

Chetan Mehrotra


On Fri, Mar 22, 2013 at 1:31 PM, Achim Nierbeck wrote:

> Hi,
>
> you should ask this at the ops4j community.
> Or try to search for this at the ops4j Google group.
>
> regards, Achim
>
> sent from mobile device
> Am 22.03.2013 06:07 schrieb "Chetan Mehrotra" :
>
> > Hi,
> >
> > This query is not related to Felix but I just wanted to check if any of
> the
> > projects have used any Code Coverage tool with Pax Exam.
> >
> > I am adding integration test for the JAAS module and was looking for a
> way
> > to measure code coverage. So any pointers around that would be helpful.
> >
> > Chetan Mehrotra
> >
>

Re: Determining code coverage with Pax Exam

2013-03-22 Thread Felix Meschberger

Hi Chetan

Excellent ! You might want to document what you did on the opsj4 wiki ?

Regards
Felix

Am 22.03.2013 um 09:18 schrieb Chetan Mehrotra:

> I got it working with JoCoCo [1]. So problem is solved for now.
> 
> [1] http://www.eclemma.org/jacoco/trunk/index.html
> 
> Chetan Mehrotra
> 
> 
> On Fri, Mar 22, 2013 at 1:31 PM, Achim Nierbeck 
> wrote:
> 
>> Hi,
>> 
>> you should ask this at the ops4j community.
>> Or try to search for this at the ops4j Google group.
>> 
>> regards, Achim
>> 
>> sent from mobile device
>> Am 22.03.2013 06:07 schrieb "Chetan Mehrotra" :
>> 
>>> Hi,
>>> 
>>> This query is not related to Felix but I just wanted to check if any of
>> the
>>> projects have used any Code Coverage tool with Pax Exam.
>>> 
>>> I am adding integration test for the JAAS module and was looking for a
>> way
>>> to measure code coverage. So any pointers around that would be helpful.
>>> 
>>> Chetan Mehrotra
>>> 
>> 


--
Felix Meschberger | Principal Scientist | Adobe

Re: Determining code coverage with Pax Exam

2013-03-22 Thread Achim Nierbeck

Hi,

yeah some documentation on this is highly appreciated :D
Though we do have some issues with our confluence due to an (at least for
us)
unanticipated move to a newer version of confluence and some other form of
hosting.
For adding your documentation please use this link [1].
We do have a forwarding from team.ops4j.org but somehow editing doesn't
work through this.

regards, Achim

[1] -
https://ops4j1.jira.com/wiki/display/ops4j/Open+Participation+Software+for+Java



2013/3/22 Felix Meschberger 

> Hi Chetan
>
> Excellent ! You might want to document what you did on the opsj4 wiki ?
>
> Regards
> Felix
>
> Am 22.03.2013 um 09:18 schrieb Chetan Mehrotra:
>
> > I got it working with JoCoCo [1]. So problem is solved for now.
> >
> > [1] http://www.eclemma.org/jacoco/trunk/index.html
> >
> > Chetan Mehrotra
> >
> >
> > On Fri, Mar 22, 2013 at 1:31 PM, Achim Nierbeck  >wrote:
> >
> >> Hi,
> >>
> >> you should ask this at the ops4j community.
> >> Or try to search for this at the ops4j Google group.
> >>
> >> regards, Achim
> >>
> >> sent from mobile device
> >> Am 22.03.2013 06:07 schrieb "Chetan Mehrotra" <
> chetan.mehro...@gmail.com>:
> >>
> >>> Hi,
> >>>
> >>> This query is not related to Felix but I just wanted to check if any of
> >> the
> >>> projects have used any Code Coverage tool with Pax Exam.
> >>>
> >>> I am adding integration test for the JAAS module and was looking for a
> >> way
> >>> to measure code coverage. So any pointers around that would be helpful.
> >>>
> >>> Chetan Mehrotra
> >>>
> >>
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
>


-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog

[jira] [Commented] (FELIX-3953) Deadlock in classloaders

2013-03-22 Thread Don Brown (JIRA)


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

Don Brown commented on FELIX-3953:
--

We (Atlassian) are seeing this issue a lot in testing Felix 4.2.1.  Does this 
mean we are effectively stuck on 3.0 until we can move to JDK 7 as our minimum 
requirement?  (4.0 doesn't work due to nasty locking issues that, while present 
in 3.0, were treated less severely)

> Deadlock in classloaders
> 
>
> Key: FELIX-3953
> URL: https://issues.apache.org/jira/browse/FELIX-3953
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-4.2.0
> Environment: JDK 6
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>
> The two threads seem to deadlock
> {code}
> "pool-org.fusesource.patch.patch-core-7.2.0.redhat-012-thread-1" prio=6 
> tid=0x32f60400 nid=0x1110 in Object.wait() [0x3b55e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x25e09670> (a java.util.HashMap)
>   at java.lang.Object.wait(Object.java:485)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2050)
>   - locked <0x25e09670> (a java.util.HashMap)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1472)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1923)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   at java.lang.ClassLoader.defineClass1(Native Method)
>   at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2228)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1472)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1923)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1862)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:937)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.loadClass(BlueprintContainerImpl.java:419)
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.loadClass(BlueprintRepository.java:410)
>   at 
> org.apache.aries.blueprint.container.GenericType.parse(GenericType.java:113)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.doLoadType(AbstractRecipe.java:168)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.loadType(AbstractRecipe.java:161)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.loadClass(BeanRecipe.java:249)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.getType(BeanRecipe.java:895)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:323)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
>   at 
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)
>   at 
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:282)
>   at 
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:249)
>   at 
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:146)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)
>   at 
> org.apache.aries.blueprint

[jira] [Commented] (FELIX-3953) Deadlock in classloaders

2013-03-22 Thread Richard S. Hall (JIRA)


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

Richard S. Hall commented on FELIX-3953:


If the deadlocking is caused by held class loader locks, then there is nothing 
we can do in the framework, since the framework doesn't hold class loader locks.

Did you test Java 7 and/or Java 6 with the above flags to see if it solves your 
issue?

Not sure why it would be worse on 4.2.1 than on 3.0, necessarily, but if you 
investigate it and have some theories on how to loosen it up, we'd be 
interested in hearing about them.

> Deadlock in classloaders
> 
>
> Key: FELIX-3953
> URL: https://issues.apache.org/jira/browse/FELIX-3953
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-4.2.0
> Environment: JDK 6
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>
> The two threads seem to deadlock
> {code}
> "pool-org.fusesource.patch.patch-core-7.2.0.redhat-012-thread-1" prio=6 
> tid=0x32f60400 nid=0x1110 in Object.wait() [0x3b55e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x25e09670> (a java.util.HashMap)
>   at java.lang.Object.wait(Object.java:485)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2050)
>   - locked <0x25e09670> (a java.util.HashMap)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1472)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1923)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   at java.lang.ClassLoader.defineClass1(Native Method)
>   at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2228)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1472)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1923)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1862)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:937)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.loadClass(BlueprintContainerImpl.java:419)
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.loadClass(BlueprintRepository.java:410)
>   at 
> org.apache.aries.blueprint.container.GenericType.parse(GenericType.java:113)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.doLoadType(AbstractRecipe.java:168)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.loadType(AbstractRecipe.java:161)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.loadClass(BeanRecipe.java:249)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.getType(BeanRecipe.java:895)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:323)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
>   at 
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)
>   at 
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:282)
>   at 
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:249)
>   at 
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:146)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRec

Re: Determining code coverage with Pax Exam

[jira] [Resolved] (FELIX-3989) Add support for determining code coverage with integration testcases

Re: Determining code coverage with Pax Exam

Re: Determining code coverage with Pax Exam

Re: Determining code coverage with Pax Exam

[jira] [Commented] (FELIX-3953) Deadlock in classloaders

[jira] [Commented] (FELIX-3953) Deadlock in classloaders

7 matches

Site Navigation

Mail list logo

Footer information