Re: OWB Decorators

2012-04-02 Thread Mark Struberg
Hi Christian!

It is better we move this one over to the openwebbeans-dev list.

LieGrue,
strub




- Original Message -
 From: Christian Beikov c.bei...@curecomp.com
 To: MyFaces Discussion us...@myfaces.apache.org
 Cc: 
 Sent: Monday, April 2, 2012 6:46 PM
 Subject: OWB Decorators
 
 Hello there!
 
 I have just found out something that really scared me!
 I am using for this example 2 Decorators for one Interface and a simple 
 implementation, like this:
 
 interface Service extends Serializable{
   public Object getSomething(int value);
   public boolean test(String text);
 }
 
 -
 public class MyService implements Service {
 
   /* Used somewhere else to be able to use decorators and interceptors */
   @Inject
   private Service delegate;
 
   public boolean test(String text){
     return false;
   }
 }
 
 -
 @Decorator
 public abstract class ServiceDecoratorA implements Service {
   @Delegate
   @Inject
   private Service delegate;
 
   public boolean test(String text){
     Object o = delegate.getSomething();
 
     if(/*condition*/){
       return true;
     } else {
       return delegate.test(text);
     }
   }
 }
 
 
 @Decorator
 public abstract class ServiceDecoratorB implements Service {
   @Delegate
   @Inject
   private Service delegate;
 
   public boolean test(String text){
     Object o = delegate.getSomething();
 
     if(/*condition*/){
       return true;
     } else {
       return delegate.test(text);
     }
   }
 }
 
 Invocation(Through EL): #{myService.test('aString')}
 Expected Invocation-Chain: 
 OWB-Proxy.test(String)-...-ServiceDecoratorA.test(String)-ServiceDecoratorB.test(String)-MyService.test(String)
 Actual Invocation-Chain: 
 OWB-Proxy.test(String)-...-ServiceDecoratorA.test(String)-MyService.test(String)
 
 When I call the method test(String) decorator A is accessed when the 
 condition 
 evaluates to false I would expect the next decorator to be called, instead 
 MyService.test(String) is called. If I put the expression 
 delegate.test(String) 
 to the first line in the decorator method, temporary put the result in a 
 local 
 var and return the local vars content, everything works as expected.
 
 I think that the invocation of the delegate mixes up a state of the OWB proxy 
 or 
 so. I have no idea about what happens here but it sucks and I think that this 
 behavior is wrong.
 I fixed this problem right now with temporary saving the delegates return 
 into a 
 local var and the do other invocations on the delegate.
 
 Is this a bug or is it not allowed to call other methods than the decorated 
 one 
 in the decorator method?
 
 Regards,
 
 Christian



Re: OWB Decorators

2012-04-02 Thread Eric Covener
 Is this a bug or is it not allowed to call other methods than the decorated 
 one
 in the decorator method?

I think the behavior he expects is the correct behavior, having not
looked at the code, as the stack unwinds we need to back up the
decorator we're looking at as next.


[jira] [Updated] (OWB-647) [PERF] Avoid unnecessary StringBuilder instances - improve checkNullInstance, checkScopeType, ... methods

2012-04-02 Thread Updated

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

Martin Kočí updated OWB-647:


Attachment: OWB-647.patch

 [PERF] Avoid unnecessary StringBuilder instances - improve checkNullInstance, 
 checkScopeType, ... methods
 -

 Key: OWB-647
 URL: https://issues.apache.org/jira/browse/OWB-647
 Project: OpenWebBeans
  Issue Type: Improvement
Affects Versions: 1.1.4
 Environment: OWB trunk
Reporter: Martin Kočí
Priority: Trivial
 Fix For: 1.1.4

 Attachments: OWB-647.patch


 methods like 
 org.apache.webbeans.component.ProducerMethodBean.checkNullInstance(Object) or 
 org.apache.webbeans.component.ProducerMethodBean.checkScopeType() create 
 StringBuilder instance in every invocation, but that String is useful only in 
 a buggy application
 Improve check* method with support of {0} {1}  placeholders (like 
 java.util.logging has) or/and combine those checks with 
 production/development project stage check.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Assigned] (OWB-647) [PERF] Avoid unnecessary StringBuilder instances - improve checkNullInstance, checkScopeType, ... methods

2012-04-02 Thread Assigned

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

Martin Kočí reassigned OWB-647:
---

Assignee: Martin Kočí

 [PERF] Avoid unnecessary StringBuilder instances - improve checkNullInstance, 
 checkScopeType, ... methods
 -

 Key: OWB-647
 URL: https://issues.apache.org/jira/browse/OWB-647
 Project: OpenWebBeans
  Issue Type: Improvement
Affects Versions: 1.1.4
 Environment: OWB trunk
Reporter: Martin Kočí
Assignee: Martin Kočí
Priority: Trivial
 Fix For: 1.1.4

 Attachments: OWB-647.patch


 methods like 
 org.apache.webbeans.component.ProducerMethodBean.checkNullInstance(Object) or 
 org.apache.webbeans.component.ProducerMethodBean.checkScopeType() create 
 StringBuilder instance in every invocation, but that String is useful only in 
 a buggy application
 Improve check* method with support of {0} {1}  placeholders (like 
 java.util.logging has) or/and combine those checks with 
 production/development project stage check.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (OWB-659) An annotated interface class is being seen as a manage bean.

2012-04-02 Thread Mark Struberg (Resolved) (JIRA)

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

Mark Struberg resolved OWB-659.
---

Resolution: Fixed

Christian, can you please try with the latest owb-snapshot? Should be fixed as 
we now ignore annotations, interfaces and enums as being subject to injection.

 An annotated interface class is being seen as a manage bean.
 

 Key: OWB-659
 URL: https://issues.apache.org/jira/browse/OWB-659
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: 1.1.3
 Environment: Linux
Reporter: Christian Nuesa
Assignee: Mark Struberg
  Labels: annotation, exception, interface, managedbeans, 
 validation
 Fix For: 1.1.4


 I have an interface class generated by Apache CXF 2.4.3 in my project which 
 comes out to have @WebService annotation in it.  This interface causes a 
 runtime exception coming from WebBeansUtil.checkManagedBeanCondition(..) 
 which states ManagedBean implementation class : class may not defined as 
 interface.
 This exception tells me that during the scanning of classes this interface is 
 being mistaken as a managed bean, but it is not, hence the exception.  I 
 investigated the code and narrowed my problem with BeansDeployer.java and 
 surely enough its method called defineManagedBean(..) fails to validate if 
 the class is an interface first before processing (so leading to the 
 exception).
 This method must check if the incoming class is an interface so then must 
 return a false value.  This way, any interface like this is avoided as 
 managed bean.
 Here is the exception:
 org.apache.webbeans.exception.WebBeansConfigurationException: ManagedBean 
 implementation class : 
 com.mgmmirage.playersclub.definitions.PlayersClubPlayerPortType may not 
 defined as interface
 at 
 org.apache.webbeans.util.WebBeansUtil.checkManagedBeanCondition(WebBeansUtil.java:3042)
 at 
 org.apache.webbeans.component.creation.ManagedBeanCreatorImpl.checkCreateConditions(ManagedBeanCreatorImpl.java:65)
 at 
 org.apache.webbeans.util.WebBeansUtil.defineManagedBean(WebBeansUtil.java:2894)
 at 
 org.apache.webbeans.container.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1143)
 at 
 org.apache.webbeans.util.WebBeansUtil.fireProcessInjectionTargetEventForJavaEeComponents(WebBeansUtil.java:2173)
 at 
 org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.java:788)
 at 
 org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDeployer.java:558)
 at 
 org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.java:788)
 at 
 org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDeployer.java:558)
 at 
 org.apache.webbeans.config.BeansDeployer.deployFromClassPath(BeansDeployer.java:494)
 at 
 org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:166)
 at 
 org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:127)
 at 
 org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:88)
 at 
 org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:85)
 at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4765)
 at 
 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5260)
 at 
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:866)
 at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:842)
 at 
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
 at 
 org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:958)
 at 
 org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1599)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:680)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: 

[jira] [Commented] (OWB-659) An annotated interface class is being seen as a manage bean.

2012-04-02 Thread Christian Nuesa (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/OWB-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244656#comment-13244656
 ] 

Christian Nuesa commented on OWB-659:
-

Mark, where do I download the owb-snapshot?

 An annotated interface class is being seen as a manage bean.
 

 Key: OWB-659
 URL: https://issues.apache.org/jira/browse/OWB-659
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: 1.1.3
 Environment: Linux
Reporter: Christian Nuesa
Assignee: Mark Struberg
  Labels: annotation, exception, interface, managedbeans, 
 validation
 Fix For: 1.1.4


 I have an interface class generated by Apache CXF 2.4.3 in my project which 
 comes out to have @WebService annotation in it.  This interface causes a 
 runtime exception coming from WebBeansUtil.checkManagedBeanCondition(..) 
 which states ManagedBean implementation class : class may not defined as 
 interface.
 This exception tells me that during the scanning of classes this interface is 
 being mistaken as a managed bean, but it is not, hence the exception.  I 
 investigated the code and narrowed my problem with BeansDeployer.java and 
 surely enough its method called defineManagedBean(..) fails to validate if 
 the class is an interface first before processing (so leading to the 
 exception).
 This method must check if the incoming class is an interface so then must 
 return a false value.  This way, any interface like this is avoided as 
 managed bean.
 Here is the exception:
 org.apache.webbeans.exception.WebBeansConfigurationException: ManagedBean 
 implementation class : 
 com.mgmmirage.playersclub.definitions.PlayersClubPlayerPortType may not 
 defined as interface
 at 
 org.apache.webbeans.util.WebBeansUtil.checkManagedBeanCondition(WebBeansUtil.java:3042)
 at 
 org.apache.webbeans.component.creation.ManagedBeanCreatorImpl.checkCreateConditions(ManagedBeanCreatorImpl.java:65)
 at 
 org.apache.webbeans.util.WebBeansUtil.defineManagedBean(WebBeansUtil.java:2894)
 at 
 org.apache.webbeans.container.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1143)
 at 
 org.apache.webbeans.util.WebBeansUtil.fireProcessInjectionTargetEventForJavaEeComponents(WebBeansUtil.java:2173)
 at 
 org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.java:788)
 at 
 org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDeployer.java:558)
 at 
 org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.java:788)
 at 
 org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDeployer.java:558)
 at 
 org.apache.webbeans.config.BeansDeployer.deployFromClassPath(BeansDeployer.java:494)
 at 
 org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:166)
 at 
 org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:127)
 at 
 org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:88)
 at 
 org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:85)
 at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4765)
 at 
 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5260)
 at 
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:866)
 at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:842)
 at 
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
 at 
 org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:958)
 at 
 org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1599)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:680)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (OWB-636) Samples point to parent pom file that doesn't exist

2012-04-02 Thread Mark Struberg (Resolved) (JIRA)

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

Mark Struberg resolved OWB-636.
---

   Resolution: Fixed
Fix Version/s: 1.1.4

 Samples point to parent pom file that doesn't exist
 ---

 Key: OWB-636
 URL: https://issues.apache.org/jira/browse/OWB-636
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Samples  Documentation
Affects Versions: 1.1.3
 Environment: Any
Reporter: Esteve
Assignee: Mark Struberg
Priority: Minor
  Labels: samples
 Fix For: 1.1.4


 In the samples directory all samples point to a pom.xml file in the parent 
 directory that doesn't exist.
 parent
 artifactIdsamples/artifactId
 groupIdorg.apache.openwebbeans/groupId
 version1.1.3/version
 relativePath../pom.xml/relativePath
 /parent

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (OWB-602) OpenWebBeans OpenEJB integration OSGi bundle declares the wrong version for the javax.transaction package

2012-04-02 Thread Mark Struberg (Resolved) (JIRA)

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

Mark Struberg resolved OWB-602.
---

   Resolution: Fixed
Fix Version/s: (was: 1.2.0)
   1.1.4

openwebbeans-openejb got removed, thus we don't need to fix it anymore ;)

 OpenWebBeans OpenEJB integration OSGi bundle declares the wrong version for 
 the javax.transaction package
 -

 Key: OWB-602
 URL: https://issues.apache.org/jira/browse/OWB-602
 Project: OpenWebBeans
  Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Timothy Ward
Assignee: David Blevins
 Fix For: 1.1.4


 The OpenWebBeans OSGi bundle for integrating with OpenEJB declares a package 
 import for javax.transaction at version 5.0.0. This is not the correct 
 version for javax.transaction, which should be version 1.1.0.
 The correct version range for this import should be [1.1,2) or [1.1,1.2) if 
 any javax.transaction interfaces are being implemented.
 This packaging error prevents the bundle from being able to be deployed 
 correctly in an OSGi runtime.
 Other locations in the OpenWebBeans project import at version 1.1, which is 
 correct, however they do not specify version ranges and they probably should.
 [Framework Event Dispatcher] DEBUG openwebbeans-openejb - FrameworkEvent ERROR
 org.osgi.framework.BundleException: The bundle could not be resolved. Reason: 
 Missing Constraint: Import-Package: javax.transaction; version=5.0.0
   at 
 org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
   at 
 org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
   at 
 org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
   at 
 org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:370)
   at 
 org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1068)
   at 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:557)
   at 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:464)
   at 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:248)
   at 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:445)
   at 
 org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
   at 
 org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:330)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (OWB-659) An annotated interface class is being seen as a manage bean.

2012-04-02 Thread Mark Struberg (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/OWB-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244692#comment-13244692
 ] 

Mark Struberg commented on OWB-659:
---

I've now deployed the latest owb snapshot to our apache.snapshots repo.
If you are using maven, then just configure a repositories section and add a 
repository with the following url
https://repository.apache.org/content/repositories/snapshots/

 An annotated interface class is being seen as a manage bean.
 

 Key: OWB-659
 URL: https://issues.apache.org/jira/browse/OWB-659
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: 1.1.3
 Environment: Linux
Reporter: Christian Nuesa
Assignee: Mark Struberg
  Labels: annotation, exception, interface, managedbeans, 
 validation
 Fix For: 1.1.4


 I have an interface class generated by Apache CXF 2.4.3 in my project which 
 comes out to have @WebService annotation in it.  This interface causes a 
 runtime exception coming from WebBeansUtil.checkManagedBeanCondition(..) 
 which states ManagedBean implementation class : class may not defined as 
 interface.
 This exception tells me that during the scanning of classes this interface is 
 being mistaken as a managed bean, but it is not, hence the exception.  I 
 investigated the code and narrowed my problem with BeansDeployer.java and 
 surely enough its method called defineManagedBean(..) fails to validate if 
 the class is an interface first before processing (so leading to the 
 exception).
 This method must check if the incoming class is an interface so then must 
 return a false value.  This way, any interface like this is avoided as 
 managed bean.
 Here is the exception:
 org.apache.webbeans.exception.WebBeansConfigurationException: ManagedBean 
 implementation class : 
 com.mgmmirage.playersclub.definitions.PlayersClubPlayerPortType may not 
 defined as interface
 at 
 org.apache.webbeans.util.WebBeansUtil.checkManagedBeanCondition(WebBeansUtil.java:3042)
 at 
 org.apache.webbeans.component.creation.ManagedBeanCreatorImpl.checkCreateConditions(ManagedBeanCreatorImpl.java:65)
 at 
 org.apache.webbeans.util.WebBeansUtil.defineManagedBean(WebBeansUtil.java:2894)
 at 
 org.apache.webbeans.container.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1143)
 at 
 org.apache.webbeans.util.WebBeansUtil.fireProcessInjectionTargetEventForJavaEeComponents(WebBeansUtil.java:2173)
 at 
 org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.java:788)
 at 
 org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDeployer.java:558)
 at 
 org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.java:788)
 at 
 org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDeployer.java:558)
 at 
 org.apache.webbeans.config.BeansDeployer.deployFromClassPath(BeansDeployer.java:494)
 at 
 org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:166)
 at 
 org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:127)
 at 
 org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:88)
 at 
 org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:85)
 at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4765)
 at 
 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5260)
 at 
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:866)
 at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:842)
 at 
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
 at 
 org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:958)
 at 
 org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1599)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:680)

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

Jenkins build is back to normal : OpenWebBeans-trunk #777

2012-04-02 Thread Apache Jenkins Server
See https://builds.apache.org/job/OpenWebBeans-trunk/777/