[JBoss JIRA] (WFLY-3489) Allow custom EJB pools
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-3489?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-3489.
--------------------------------
Resolution: Out of Date
> Allow custom EJB pools
> ----------------------
>
> Key: WFLY-3489
> URL: https://issues.jboss.org/browse/WFLY-3489
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 8.1.0.Final
> Reporter: James Livingston
> Priority: Major
>
> The only type of EJB pool that can currently be specified is strict-max-pool. It would be useful to be able to specify a custom pool class similar to other subsystems.
> For example:
> <custom-pool module="my.module" class="example.SomePool">
> <properties>
> <property name="x" value="y"/>
> </properties>
> </custom-pool>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-2939) JBAS014194 Extended Implementation of 'import javax.jms.MessageListener' not accepted
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-2939?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-2939.
--------------------------------
Resolution: Duplicate Issue
> JBAS014194 Extended Implementation of 'import javax.jms.MessageListener' not accepted
> -------------------------------------------------------------------------------------
>
> Key: WFLY-2939
> URL: https://issues.jboss.org/browse/WFLY-2939
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Environment: Windows 7, 64bit, JDK 1.7
> Reporter: Eugen Eisler
> Priority: Major
>
> I am trying to deploy working Weblogic EAR to WildFly and it is not working, because a MDB (ExampleTopic1Mdb) can not be deployed, what extends a super class(SingleTypeEventListenerBridgeByJms) which implements MessageListener, but the MDB itself does not have "implements javax.jms.MessageListener".
> Error Message:
> JBAS014194: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface.
> @SuppressWarnings("unused")
> @MessageDriven(mappedName = ExampleConstants.JMS_TOPIC1,
> activationConfig = { @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),
> @ActivationConfigProperty(propertyName = "topicMessagesDistributionMode", propertyValue = "One-Copy-Per-Application") })
> @Traceable
> public class ExampleTopic1Mdb extends SingleTypeEventListenerBridgeByJms<Task> {
> @Inject
> public void setExampleSynchronizer(EventListener<Task> exampleSynchronizer) {
> super.setEventListener(exampleSynchronizer);
> }
> }
> public class SingleTypeEventListenerBridgeByJms<T> implements javax.jms.MessageListener {
> ....
> The class SingleTypeEventListenerBridgeByJms is in different ejb module of the EAR.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-917) jboss-ejb3.xml faults fail silently and result in a hanging thread
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-917?page=com.atlassian.jira.plugin.s... ]
Tomasz Adamski closed WFLY-917.
-------------------------------
Resolution: Out of Date
> jboss-ejb3.xml faults fail silently and result in a hanging thread
> ------------------------------------------------------------------
>
> Key: WFLY-917
> URL: https://issues.jboss.org/browse/WFLY-917
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Environment: MacOS X 10.8.2
> java version "1.6.0_35"
> Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
> Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
> Reporter: Stephen Coy
> Assignee: Eduardo Martins
> Priority: Major
> Attachments: migration-demo.tar.gz
>
>
> The attached maven application project has a subtle typo in a JNDI name in the jboss-ejb3.xml file.
> The deployment process results in a hanging thread shown below. There are no diagnostic log messages at all to indicate what the problem could be.
> A second consequence of this hung thread is that the server process can only be terminated with a "kill -9 <pid>".
> Note that it is deliberately a JEE5 compatible application.
> "management-handler-thread - 4" prio=5 tid=7f843c0bf000 nid=0x10a866000 in Object.wait() [10a864000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7d42d05f8> (a org.jboss.as.controller.ContainerStateMonitor)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158)
> - locked <7d42d05f8> (a org.jboss.as.controller.ContainerStateMonitor)
> at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:442)
> at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:147)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:261)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.server.deployment.DeploymentHandlerUtil$1.execute(DeploymentHandlerUtil.java:123)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.server.deployment.DeploymentDeployHandler.execute(DeploymentDeployHandler.java:75)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:168)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.controller.CompositeOperationHandler.execute(CompositeOperationHandler.java:85)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:473)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:126)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Locked ownable synchronizers:
> - <7d42a5150> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> - <7d4f3b598> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (SWSQE-1014) Workload pod Created_at Date comparison
by Hayk Hovsepyan (Jira)
Hayk Hovsepyan created SWSQE-1014:
-------------------------------------
Summary: Workload pod Created_at Date comparison
Key: SWSQE-1014
URL: https://issues.jboss.org/browse/SWSQE-1014
Project: Kiali QE
Issue Type: QE Task
Reporter: Hayk Hovsepyan
Currently Created_at Date is not validated for WorkloadPod object, because it need to read dates from table, and when there are sum up of pods, it needs a regexp parser there.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-2486) EJBComponentDescription#isSecurityEnabled() is incorrect
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-2486?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-2486.
--------------------------------
Resolution: Out of Date
> EJBComponentDescription#isSecurityEnabled() is incorrect
> --------------------------------------------------------
>
> Key: WFLY-2486
> URL: https://issues.jboss.org/browse/WFLY-2486
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Stuart Douglas
> Priority: Major
>
> This assumes that if the security domain is null, then the there is no security. This is incorrect, as there could be a default security domain. There could also be a security domain set, but not security annotations/metadata that is applicable to the bean. On the whole I think we should remove this method, as its use is problematic, and move any code that relies on it to org.jboss.as.ejb3.security.EJBSecurityViewConfigurator, so all the security stuff is setup in one place.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-3630) NonPersistentIntervalTimerManagementTestCase fails sometimes
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-3630?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-3630.
--------------------------------
Resolution: Out of Date
> NonPersistentIntervalTimerManagementTestCase fails sometimes
> ------------------------------------------------------------
>
> Key: WFLY-3630
> URL: https://issues.jboss.org/browse/WFLY-3630
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite
> Affects Versions: 9.0.0.Alpha1
> Environment: Windows 7 SP1, Oracle JDK 1.7.0_60
> Reporter: Frank Langelage
> Priority: Major
>
> Testcase org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase fails sometimes for me when running build with all tests on Windows machine. I never saw this failure on my Solaris box using the same JDK version. And somehow the appearance of the failure seem to be related to the execution time.
> Executing the testsuite during the day does not show me this error. Only in the very late evening / early morning hours the error appeared. (All related to Central European Summer time in my case.)
> I added some debug output an saw, that, in case of failure, after "activateTimer" the timer fires immediately so that there is one timeout too much then. The initial timeout time of the timer is passed, when it's suspended. When activated it seems to make good for the missed timeout sometimes.
> The persistent version of this testcase located in the same package with exactly same logic never fails for me.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months