[JBoss JIRA] (WFLY-3823) Memory leak with EJB Timer service
by Matus Zamborsky (JIRA)
Matus Zamborsky created WFLY-3823:
-------------------------------------
Summary: Memory leak with EJB Timer service
Key: WFLY-3823
URL: https://issues.jboss.org/browse/WFLY-3823
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 8.1.0.Final
Environment: Windows 8.1 64bit, Java 1.7.0_40-b43
Reporter: Matus Zamborsky
Assignee: David Lloyd
There is a memory leak during undeploy (redeploy) when there is a timer used in EJB bean.
When the timer is created (using @Schedule or programmatically), it is put in queue on Timer thread. According to JDK sources (http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u... line 552) The queue is processed if new timer is created or the next timer task is due to be run and the reference to last timer is retained on stack (line 521). Therefore after the module undeploy there is still a reference to TimerTask from the module.
It is not a true memory leak, because the reference will be removed when the task is due, but in environment with many redeploys (development and continuous integration) will soon hit the java.lang.OutOfMemoryError: PermGen space.
One workaround is to have another Scheduler, which will schedule job for every second. This way, the timer thread will process the queue and throw away the reference to last timerTask.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (DROOLS-594) Accumulation causes node propagation failure which results in rule firing when it is not supposed to
by John Le (JIRA)
[ https://issues.jboss.org/browse/DROOLS-594?page=com.atlassian.jira.plugin... ]
John Le updated DROOLS-594:
---------------------------
Attachment: AggregateIssue.java
sample code to reproduce the accumulate issue
> Accumulation causes node propagation failure which results in rule firing when it is not supposed to
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-594
> URL: https://issues.jboss.org/browse/DROOLS-594
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1
> Reporter: John Le
> Assignee: Mark Proctor
> Attachments: AggregateIssue.java
>
>
> Accumulation causes node propagation failure which results in rule firing when it is not supposed to. Please see attached code file to reproduce the issue. Rule "RS7402.42.2" is supposed to fire once but it manages to fire twice without getting deactivate.
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT ASSERTED value:EvaluatedData factId: 13
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:BenefitAssessmentResults factId: 12
> RS7365.4.6_ FIRED
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:EvaluatedData factId: 13
> RS7402.42.2_ FIRED
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=9180.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=9180.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:EvaluatedData factId: 13
> RS7402.42.2_ FIRED
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=18360.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (DROOLS-594) Accumulation causes node propagation failure which results in rule firing when it is not supposed to
by John Le (JIRA)
John Le created DROOLS-594:
------------------------------
Summary: Accumulation causes node propagation failure which results in rule firing when it is not supposed to
Key: DROOLS-594
URL: https://issues.jboss.org/browse/DROOLS-594
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.Beta1, 6.1.0.Final
Reporter: John Le
Assignee: Mark Proctor
Accumulation causes node propagation failure which results in rule firing when it is not supposed to. Please see attached code file to reproduce the issue. Rule "RS7402.42.2" is supposed to fire once but it manages to fire twice without getting deactivate.
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT ASSERTED value:EvaluatedData factId: 13
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:BenefitAssessmentResults factId: 12
RS7365.4.6_ FIRED
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:EvaluatedData factId: 13
RS7402.42.2_ FIRED
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=9180.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=9180.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:EvaluatedData factId: 13
RS7402.42.2_ FIRED
2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=18360.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-3822) Upgrade to JBossWS 4.3.1
by Frank Langelage (JIRA)
Frank Langelage created WFLY-3822:
-------------------------------------
Summary: Upgrade to JBossWS 4.3.1
Key: WFLY-3822
URL: https://issues.jboss.org/browse/WFLY-3822
Project: WildFly
Issue Type: Component Upgrade
Components: Web Services
Affects Versions: 8.2.0.CR1
Reporter: Frank Langelage
Assignee: Alessio Soldano
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFCORE-87) Display deployment timestamp
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-87?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-87:
----------------------------------------
Thanks. So, that code is my 3).
The URL protocol isn't the only issue with 1). It's just the one case where neither the client (CLI, console, whatever management tool) nor the server can get a timestamp. For other cases, it's possible the client can learn the local timestamp of the file it uploads. The server wouldn't know it though, as the server is usually presented by the client with a stream of bits, not a file. For the server to store this data, the client would have to provide it as part of the management operation that creates the deployment resource.
I'm not sure whether the web console could learn the timestamp of a file it's uploading. It's been too long since I did client-side web development. :(
We wouldn't make providing such info a required param in the management API (as that would be a breaking API change), so whether it would be present would depend on whether the client was written to provide it.
> Display deployment timestamp
> ----------------------------
>
> Key: WFCORE-87
> URL: https://issues.jboss.org/browse/WFCORE-87
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
> Priority: Minor
>
> Display the deployment timestamp, that is the date of last modified deployment. It is useful for users to see the date and time of deployments.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (DROOLS-242) Add out-of-the-box possibility to dump DRL created from decision tables
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-242?page=com.atlassian.jira.plugin... ]
Petr Široký updated DROOLS-242:
-------------------------------
Fix Version/s: 6.2.0.Beta2
> Add out-of-the-box possibility to dump DRL created from decision tables
> ------------------------------------------------------------------------
>
> Key: DROOLS-242
> URL: https://issues.jboss.org/browse/DROOLS-242
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.0.0.CR2
> Reporter: Petr Široký
> Assignee: Petr Široký
> Fix For: 6.2.0.Beta2
>
>
> To get the DRL generated from decision table one has to currently use following code:
> {code}
> File dtable = new File("../resources/dtable.xls");
> KieResources kieResources = KieServices.Factory.get().getResources();
> Resource dtableResource = kieResources.newFileSystemResource(dtable);
> SpreadsheetCompiler compiler = new SpreadsheetCompiler();
> String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
> {code}
> It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
> Using the 'drools.dump.dir' property seems like the best option. The name is general enough and users would have to use/remember yet another config. property.
> Looking at how the options are being used I see basically three possible solutions here (I maybe missing some other options):
> - get the value of `drools.dump.dir` manually using the ChainedProperties.
> - add this config. option into DecisionTableConfiguration. This would prevent the backwards compatibility issues when changing the DecisionTableProvider interface, but I am not entirely sure it is the right place for this kind of config.
> - pass the entire KnowledgeBuilderConfiguration object into DecisionTableProvider.loadFromInputStream(). This seems like the best option from the clean-code point of view, but it would mean that the DecisionTableProvider interface would have to altered.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFCORE-87) Display deployment timestamp
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-87?page=com.atlassian.jira.plugin.... ]
Claudio Miranda commented on WFCORE-87:
---------------------------------------
> I'm curious how that '"timestamp" => "Fri Sep 05 00:42:19 BRT 2014"' in your example was derived. Was it the time the deployment resource was added? That wouldn't be the
> upload time once the server is rebooted. Or you worked out some way to get hold of a file timestamp?
This is the piece of code that retrieve the timestamp. No matter if the server is restarted or enabled/disabled this timestamp is the same. It is the same timestamp of data/content/hash/content file
{code}
VirtualFile vfContent = contentRepository.getContent(contentItem.getHash());
Date contentLastModified = new Date(vfContent.getLastModified());
newModel.get(DeploymentAttributes.TIMESTAMP.getName()).set(contentLastModified.toString());
{code}
My experience with admin users on customers, says that option 1 would be the most interesting. As the most common storage mechanism for EAP/Wildfly is a local disk (file protocol) so they have access to the physical file. Perhaps there are users out there using other URL protocols, and the deployment time will not work with them.
But, I will follow your recommendation to use the enable/disable-time{stamp}. Later I can revisit this when things mature for me.
> Display deployment timestamp
> ----------------------------
>
> Key: WFCORE-87
> URL: https://issues.jboss.org/browse/WFCORE-87
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
> Priority: Minor
>
> Display the deployment timestamp, that is the date of last modified deployment. It is useful for users to see the date and time of deployments.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-673) The exception chain of DeploymentException never contains the actual cause
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-673?page=com.atlassian.jira.plugin.s... ]
Mark Struberg commented on WFLY-673:
------------------------------------
Came across this as well. This bug in Arquillian is responsible for the most of our failing TCK tests right now...
> The exception chain of DeploymentException never contains the actual cause
> --------------------------------------------------------------------------
>
> Key: WFLY-673
> URL: https://issues.jboss.org/browse/WFLY-673
> Project: WildFly
> Issue Type: Bug
> Reporter: Jason Porter
> Fix For: No Release
>
>
> You can see the exception here:
> -------------------------------------------------------------------------------
> Test set: org.jboss.seam.exception.control.test.extension.ExtensionErrorTest
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.711 sec <<< FAILURE!
> org.jboss.seam.exception.control.test.extension.ExtensionErrorTest Time elapsed: 0 sec <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container
> at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:111)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:148)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:115)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:246)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.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.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.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> at sun.reflect.GeneratedMethodAccessor7.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.GeneratedMethodAccessor6.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.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.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:86)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:79)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:238)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:222)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:78)
> 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:134)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:97)
> 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:68)
> at sun.reflect.GeneratedMethodAccessor4.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:54)
> 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.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:158)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
> 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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
> Caused by: java.lang.Exception: {
> "Failed services" => {"jboss.deployment.unit.\"extensionError.war\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"extensionError.war\".WeldService: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> java.lang.IllegalArgumentException: Handler method public void org.jboss.seam.exception.control.test.handler.HandlerWhichThrowsExceptions.throwsAnException(org.jboss.seam.exception.control.CaughtException) throws java.lang.Exception must not throw exceptions
> at org.jboss.seam.exception.control.extension.CatchExtension.findHandlers(CatchExtension.java:93)
> at sun.reflect.GeneratedMethodAccessor413.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
> at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
> at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
> at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
> at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
> at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
> at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:67)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
> at org.jboss.weld.bootstrap.events.ProcessManagedBeanImpl.fire(ProcessManagedBeanImpl.java:34)
> at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:126)
> at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:216)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370)
> at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
> at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 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:662)
> "},
> "Services with missing/unavailable dependencies" => [
> "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.seam.solder.resourceLoader.servlet.ResourceListener\".WeldInstantiator",
> "jboss.deployment.unit.\"extensionError.war\".jndiDependencyService",
> "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.as.weld.webtier.jsp.JspInitializationListener\".START",
> "jboss.web.\"extensionError.war\"",
> "jboss.naming.context.java.module.extensionError.extensionError.BeanManager",
> "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.seam.solder.resourceLoader.servlet.ResourceListener\".START",
> "jboss.deployment.unit.\"extensionError.war\".beanmanager",
> "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.as.weld.webtier.jsp.JspInitializationListener\".WeldInstantiator"
> ]
> }
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:99)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:88)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:70)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> at org.jboss.as.arquillian.container.ArchiveDeployer.executeDeploymentPlan(ArchiveDeployer.java:75)
> at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:56)
> ... 88 more
> The exception I'm expecting is the DefinitionException, not java.lang.Exception. Understandably it may not be correct to pass back the actual exception without wrapping it, but wrapping in java.lang.Exception doesn't really cut it either.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-3821) standalone.sh --debug without port number not working
by Cheng Fang (JIRA)
Cheng Fang created WFLY-3821:
--------------------------------
Summary: standalone.sh --debug without port number not working
Key: WFLY-3821
URL: https://issues.jboss.org/browse/WFLY-3821
Project: WildFly
Issue Type: Bug
Components: Scripts
Affects Versions: 9.0.0.Beta1
Reporter: Cheng Fang
Assignee: Jeff Mesnil
./standalone.sh --debug does not work, while ./standalone.sh --debug 8787 works.
Looks like the fix to WFLY-2261 is lost in later revisions of standalone.sh.
After the wildfly-core split, ./core-feature-pack/src/main/resources/content/bin/standalone.sh does not contain those lines of fix for WFLY-2261
This bug is the same as WFLY-2261, except on a later version of WildFly. To avoid confusing EAP issues, create a separate one.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months