[JBoss JIRA] (SECURITY-695) Backport SECURITY-631 to negotiation trunk
by Marek Posolda (JIRA)
Marek Posolda created SECURITY-695:
--------------------------------------
Summary: Backport SECURITY-631 to negotiation trunk
Key: SECURITY-695
URL: https://issues.jboss.org/browse/SECURITY-695
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Negotiation
Affects Versions: Negotiation_2_2_1
Environment: Negotiation 2.2.1.Final, JBoss AS 7.1.2, GateIn portal configured for SPNEGO
Reporter: Marek Posolda
Assignee: Darran Lofthouse
Attachments: SECURITY-695.patch
The issue SECURITY-631 was fixed in JBoss Negotiation 2.0.4, which was the negotiation version used by EPP. But for some reason, this feature was fixed only in 2.0 branch, but not in negotiation trunk.
Currently we need to upgrade GateIn to be used by AS7 and so we use negotiation 2.2.1.Final but feature is not available here.
--
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
13 years, 9 months
[JBoss JIRA] (JBRULES-3590) ClassCastException in RuleTerminalNode.retractLeftTuple()
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created JBRULES-3590:
------------------------------------------
Summary: ClassCastException in RuleTerminalNode.retractLeftTuple()
Key: JBRULES-3590
URL: https://issues.jboss.org/browse/JBRULES-3590
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.4.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mark Proctor
ruleflow-group + lock-on-activate may cause a ClassCastException.
{noformat}
import org.drools.Person;
import org.drools.Cheese;
rule R1
ruleflow-group "group1"
lock-on-active true
when
$p : Person()
then
$p.setName("John");
end
rule R2
ruleflow-group "group1"
lock-on-active true
when
$p : Person( name == null )
forall ( Cheese ( type == "cheddar" ))
then
end
{noformat}
{noformat}
Exception executing consequence for rule "R1" in defaultpkg: java.lang.ClassCastException: java.lang.Boolean cannot be cast to org.drools.spi.Activation
at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1212)
at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1446)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230)
...
Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast to org.drools.spi.Activation
at org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:309)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:224)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:98)
at org.drools.reteoo.NotNode.retractLeftTuple(NotNode.java:216)
at org.drools.reteoo.LeftTupleSource.doModifyLeftTuple(LeftTupleSource.java:286)
at org.drools.reteoo.AbstractTerminalNode.modifyLeftTuple(AbstractTerminalNode.java:104)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateModifyLeftTuple(SingleLeftTupleSinkAdapter.java:205)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyObject(SingleLeftTupleSinkAdapter.java:235)
at org.drools.reteoo.LeftInputAdapterNode.modifyObject(LeftInputAdapterNode.java:170)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:507)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:432)
at org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:314)
at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:265)
at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:470)
at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:370)
at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:319)
at defaultpkg.Rule_R1_71208af44b274026888141d4be342303.defaultConsequence(Rule_R1_71208af44b274026888141d4be342303.java:8)
at defaultpkg.Rule_R1_71208af44b274026888141d4be342303DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
at defaultpkg.Rule_R1_71208af44b274026888141d4be342303DefaultConsequenceInvoker.evaluate(Unknown Source)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1277)
... 35 more
{noformat}
It's probably due to the change introduced by the commit c6a3beea974234df599c4b3b80749f8ff15d3149 which sets a Boolean to the tuple.
{noformat}
public boolean createActivation(final LeftTuple tuple,
final PropagationContext context,
final InternalWorkingMemory workingMemory,
final RuleTerminalNode rtn,
final boolean reuseActivation ) {
...
InternalAgendaGroup agendaGroup = (InternalAgendaGroup) getAgendaGroup( rule.getAgendaGroup() );
if ( rule.getRuleFlowGroup() == null ) {
// No RuleFlowNode so add it directly to the Agenda
// do not add the activation if the rule is "lock-on-active" and the
// AgendaGroup is active
if ( rule.isLockOnActive() && agendaGroup.isActive() && agendaGroup.getAutoFocusActivator() != context) {
if ( tuple.getObject() == null ) {
tuple.setObject( Boolean.TRUE ); // this is so we can do a check with a bit more intent than a null check on modify
}
return false;
}
} else {
// There is a RuleFlowNode so add it there, instead of the Agenda
InternalRuleFlowGroup rfg = (InternalRuleFlowGroup) getRuleFlowGroup( rule.getRuleFlowGroup() );
// do not add the activation if the rule is "lock-on-active" and the
// RuleFlowGroup is active
if ( rule.isLockOnActive() && rfg.isActive() && agendaGroup.getAutoFocusActivator() != context) {
if ( tuple.getObject() == null ) {
tuple.setObject( Boolean.TRUE ); // this is so we can do a check with a bit more intent than a null check on modify
}
return false;
}
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (JBRULES-3604) Updating a fact causes NPE with extends
by Bobby Graham (JIRA)
Bobby Graham created JBRULES-3604:
-------------------------------------
Summary: Updating a fact causes NPE with extends
Key: JBRULES-3604
URL: https://issues.jboss.org/browse/JBRULES-3604
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.4.0.Final
Reporter: Bobby Graham
Assignee: Mark Proctor
Problem: When there are two rules (A and B) such that B extends A and both A and B reference the same fact in their conditions, calling update on that fact after calling fireAllRules causes a NPE.
DRL:
{code}
package inheritance
import org.drools.Address
rule "Parent"
enabled false
when
Address(suburb == "xyz")
then
end
rule "Child" extends "Parent"
when
$addy:Address(street == "123 some street")
then
System.out.println($addy);
end
{code}
Test:
{code}
package org.drools.testframework;
import org.drools.Address;
import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.Resource;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;
import org.drools.runtime.rule.FactHandle;
import org.junit.Test;
public class ExternalUpdateInheritanceTest {
@Test
public void testExternalInheritanceFactUpdates() {
KnowledgeBase knowledgeBase = null;
KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
Resource newClassPathResource = ResourceFactory.newClassPathResource("org/drools/lang/inheritance.drl");
builder.add(newClassPathResource, ResourceType.DRL);
if (builder.hasErrors()) {
throw new RuntimeException(builder.getErrors().toString());
}
knowledgeBase = KnowledgeBaseFactory.newKnowledgeBase();
knowledgeBase.addKnowledgePackages(builder.getKnowledgePackages());
StatefulKnowledgeSession ksession = knowledgeBase.newStatefulKnowledgeSession();
Address address = new Address();
address.setSuburb("xyz");
FactHandle addressHandle = ksession.insert(address);
int rulesFired = ksession.fireAllRules();
address.setStreet("123 some street");
ksession.update(addressHandle, address);
System.out.println(rulesFired);
}
}
{code}
Stack Trace:
java.lang.NullPointerException
at org.drools.common.DefaultAgenda.createActivation(DefaultAgenda.java:572)
at org.drools.reteoo.RuleTerminalNode.modifyLeftTuple(RuleTerminalNode.java:297)
at org.drools.reteoo.LeftTupleSource.doModifyLeftTuple(LeftTupleSource.java:297)
at org.drools.reteoo.AbstractTerminalNode.modifyLeftTuple(AbstractTerminalNode.java:104)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateModifyLeftTuple(SingleLeftTupleSinkAdapter.java:205)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyObject(SingleLeftTupleSinkAdapter.java:235)
at org.drools.reteoo.LeftInputAdapterNode.modifyObject(LeftInputAdapterNode.java:170)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateModifyObject(SingleObjectSinkAdapter.java:68)
at org.drools.reteoo.AlphaNode.modifyObject(AlphaNode.java:157)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:507)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:421)
at org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:314)
at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:265)
at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:474)
at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:960)
at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:933)
at org.drools.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:284)
at org.drools.testframework.ExternalUpdateInheritanceTest.testExternalInheritanceFactUpdates(ExternalUpdateInheritanceTest.java:44)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5567) Resolve AS7/OSGi disconnects
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5567:
-----------------------------------
Summary: Resolve AS7/OSGi disconnects
Key: AS7-5567
URL: https://issues.jboss.org/browse/AS7-5567
Project: Application Server 7
Issue Type: Task
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
An umbrella issue that collects tasks that need to be resolved to improve (or make it even work) OSGi/AS7 integration
#1 Framework Startup
At Framework startup a number bootstrap and persistent bundles (from a former run) need to be deployed before the Framework reaches its ACTIVE state. This cannot be modelled with service dependencies because must be possible to uninstall the persistent bundles without taking the Framework down. Tracked by AS7-5365
#2 Defer Resolution Phase
It is a MUST HAVE requirement that the user can deploy a large set of bundles in an arbitrary order. In OSGi we talk about a bundle states like
* INSTALLED (metadata is known and valid)
* RESOLVED (wiring is available, classes can get loaded)
* ACTIVE (services that the bundle provides have started)
Currently, any deployment running through the chain of deployment unit processors get a module created and a classloader associated. DUPs in the following phases assume that a classloader is available, which is currently not the case for unresolved bundles.
This simplistic approach causes an ordering issue and does not work with OSGi bundles. Here it must be possible to install multiple bundles before the set can be resolved. Technically, bundle deployment must stop before the module phase and resume when bundle resolution is triggered. If this is done, the following DUPs can correctly assume that a classloader is available. Tracked by AS7-5477
#3 Deployment Properties
It is a MUST HAVE requirement that users can associate properties with a bundle deployment. This would for example be a bundle start-level or an auto-start flag that determines whether a bundle deployment should automatically resolve/start. This issue is a dependency of #2. On a technical level this needs to be supported by the management API and later by the higher levels (i.e. console & cli). Tracked by AS7-3694
--
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
13 years, 9 months
[JBoss JIRA] (JBRULES-3528) Deadlock when using pseudo session clock
by Cyril Sochor (JIRA)
Cyril Sochor created JBRULES-3528:
-------------------------------------
Summary: Deadlock when using pseudo session clock
Key: JBRULES-3528
URL: https://issues.jboss.org/browse/JBRULES-3528
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.4.0.Final, 5.3.0.Final
Reporter: Cyril Sochor
Assignee: Mark Proctor
Deadlock when using fireUntilHalt in one thread and PseudoClockScheduler.advanceTime() in second thread.
Surroundings:
I read many events from JMS queue, each event has timestamp. I need temporal operations measured by time in timestamps. E.g. SomeEvent() over window:time(10s) means events with timestamps in interval 10s, not events inserted in interval 10s. So, I must use pseudo session clock and advance time before event insert into statefull session. Sometimes deadlock occured or NullPointerException is thrown.
I created test case.
Deadlock stacktraces:
Name: Thread-1
State: BLOCKED on org.drools.time.impl.PseudoClockScheduler@4599d5b owned by: Thread-0
Total blocked: 6 Total waited: 3
Stack trace:
org.drools.time.impl.PseudoClockScheduler.getCurrentTime(PseudoClockScheduler.java:104)
org.drools.common.AbstractWorkingMemory.endOperation(AbstractWorkingMemory.java:1345)
org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1240)
- locked org.drools.common.DefaultAgenda@57e2793d
org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1126)
org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1327)
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:754)
- locked org.drools.reteoo.ReteooStatefulSession@31d8d237
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:730)
org.drools.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:245)
org.drools.integrationtests.StreamsTest$1.run(StreamsTest.java:526)
java.lang.Thread.run(Thread.java:662)
Name: Thread-0
State: BLOCKED on org.drools.common.DefaultAgenda@57e2793d owned by: Thread-1
Total blocked: 2 Total waited: 0
Stack trace:
org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1168)
org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:86)
org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:1)
org.drools.time.impl.PseudoClockScheduler.runCallBacks(PseudoClockScheduler.java:203)
org.drools.time.impl.PseudoClockScheduler.advanceTime(PseudoClockScheduler.java:156)
- locked org.drools.time.impl.PseudoClockScheduler@4599d5b
org.drools.integrationtests.StreamsTest.processStocks(StreamsTest.java:533)
org.drools.integrationtests.StreamsTest.testEvenFirePseudoClockRulesAB(StreamsTest.java:500)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5508) Activation of OSGi causes missing/unsatisfied service dependencies
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5508:
-----------------------------------
Summary: Activation of OSGi causes missing/unsatisfied service dependencies
Key: AS7-5508
URL: https://issues.jboss.org/browse/AS7-5508
Project: Application Server 7
Issue Type: Bug
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Activating OSGi through management op (console/cli) will get
{code}
13:15:06,192 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011006: OSGi Framework - 2.0.0.CR21
13:15:06,561 INFO [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011001: Bundle installed: org.apache.felix.configadmin:1.2.8
13:15:06,562 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: org.apache.felix.log:1.0.0
13:15:06,563 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011001: Bundle installed: jboss-osgi-logging:1.0.0
13:15:06,565 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
13:15:06,739 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
JBAS014775: New missing/unsatisfied dependencies:
service jbosgi.integration.BootstrapBundles.COMPLETE (missing) dependents: [service jbosgi.internal.framework.INIT, service jbosgi.integration.PersistentBundles.INSTALL, service jboss.osgi.as.module.registration]
service jbosgi.integration.PersistentBundles.COMPLETE (missing) dependents: [service jbosgi.internal.framework.INIT]
13:15:06,758 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011011: Starting bundles for start level: 1
13:15:06,778 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: jboss-osgi-logging:1.0.0
13:15:06,791 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
13:15:06,816 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: org.apache.felix.log:1.0.0
13:15:06,864 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: org.apache.felix.configadmin:1.2.8
13:15:06,867 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011000: OSGi Framework started
13:15:06,887 INFO [org.jboss.web] (MSC service thread 1-1) JBAS018210: Register web context: /httpservice
13:15:06,905 INFO [org.jboss.as.controller] (MSC service thread 1-3) JBAS014774: Service status report
JBAS014776: Newly corrected services:
service jbosgi.integration.BootstrapBundles.COMPLETE (no longer required)
service jbosgi.integration.PersistentBundles.COMPLETE (no longer required)
{code}
This is related to AS7-5365 but now easily re-producable in master. More background is given here
https://community.jboss.org/wiki/OSGiSubsystemActivationProcess
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5320) Intermittent failure in RestEasyIntegrationTestCase
by Kabir Khan (JIRA)
Kabir Khan created AS7-5320:
-------------------------------
Summary: Intermittent failure in RestEasyIntegrationTestCase
Key: AS7-5320
URL: https://issues.jboss.org/browse/AS7-5320
Project: Application Server 7
Issue Type: Feature Request
Reporter: Kabir Khan
Assignee: Thomas Diesler
Priority: Critical
Fix For: 7.2.0.Alpha1
org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCase.org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCase
Failing for the past 1 build (Since #4631 )
Took 1 sec.
add description
Error Message
Cannot deploy: jaxrs-osgi-target
Stacktrace
org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: jaxrs-osgi-target
at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:145)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
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.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Standard Output
[0m06:36:14,314 INFO [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/basic/target/jbossas/standalone/data/content/75/39124d9f1c4c8cdd55cb6bc684c6475deaa113/content
[0m[0m06:36:14,320 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "jaxrs-osgi-target"
[0m[0m06:36:14,366 INFO [org.jboss.osgi.framework] (MSC service thread 1-6) JBOSGI011006: OSGi Framework - 2.0.0.CR15
[0m[0m06:36:14,694 INFO [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011001: Bundle installed: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
[0m[0m06:36:14,713 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: jboss-osgi-logging:1.0.0
[0m[0m06:36:14,733 INFO [org.jboss.osgi.framework] (MSC service thread 1-5) JBOSGI011001: Bundle installed: org.apache.felix.log:1.0.0
[0m[0m06:36:14,798 INFO [org.jboss.osgi.framework] (MSC service thread 1-6) JBOSGI011001: Bundle installed: org.apache.felix.configadmin:1.2.8
[0m[0m06:36:15,029 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "jaxrs-osgi-target" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.jaxrs-osgi-target.REGISTER Missing[JBAS014861: <one or more transitive dependencies>]","jbosgi.integration.PersistentBundles.INSTALL Missing[JBAS014861: <one or more transitive dependencies>]"]}
[0m[0m06:36:15,036 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment jaxrs-osgi-target in 6ms
[0m
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months