[JBoss JIRA] (WFLY-5039) Batch JobXmlResolverService should safe copy values from the maps
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5039?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5039.
----------------------------
> Batch JobXmlResolverService should safe copy values from the maps
> -----------------------------------------------------------------
>
> Key: WFLY-5039
> URL: https://issues.jboss.org/browse/WFLY-5039
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 10.0.0.Beta1
>
>
> {code}
> 2015-07-30 12:37:31,658 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."jslxml_ejb_vehicle.ear"."jslxml_ejb_vehicle_client.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."jslxml_ejb_vehicle.ear"."jslxml_ejb_vehicle_client.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "jslxml_ejb_vehicle_client.jar" of deployment "jslxml_ejb_vehicle.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.Alpha11.jar:2.0.0.Alpha11]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> Caused by: java.util.ConcurrentModificationException
> at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) [rt.jar:1.8.0_40]
> at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) [rt.jar:1.8.0_40]
> at org.wildfly.extension.batch.jberet.deployment.BatchDeploymentResourceProcessor.deploy(BatchDeploymentResourceProcessor.java:60)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.Alpha11.jar:2.0.0.Alpha11]
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-4754) NPE is thrown if @LocalBean is used on a WebService
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4754?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4754.
----------------------------
> NPE is thrown if @LocalBean is used on a WebService
> ---------------------------------------------------
>
> Key: WFLY-4754
> URL: https://issues.jboss.org/browse/WFLY-4754
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Dmitry Lisovsky
> Fix For: 10.0.0.Alpha4
>
>
> If you create a WebService without interface and use @LocalBean on it, during deploy you get:
> (stacktrace for 9 CR1)
> {noformat}
> 15:26:18,439 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."mms.ear"."rvm.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."mms.ear"."rvm.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "rvm.jar" of deployment "mms.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0024: Could not configure component ReviewManagerSoapService
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:95)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.security.EJBSecurityViewConfigurator.handlePermissions(EJBSecurityViewConfigurator.java:215)
> at org.jboss.as.ejb3.security.EJBSecurityViewConfigurator.configure(EJBSecurityViewConfigurator.java:123)
> at org.jboss.as.ee.component.DefaultComponentViewConfigurator.configure(DefaultComponentViewConfigurator.java:67)
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81)
> ... 6 more
> {noformat}
> The same issue in EAP: JBEAP-66
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-5207) Timestamp rounding issues on Microsoft SQL Server
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5207?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5207.
----------------------------
> Timestamp rounding issues on Microsoft SQL Server
> -------------------------------------------------
>
> Key: WFLY-5207
> URL: https://issues.jboss.org/browse/WFLY-5207
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Beta2
> Environment: all supported Microsoft SQL Server versions (2008, 2012, 2014)
> Reporter: Jan Martiska
> Assignee: Jan Martiska
> Priority: Critical
> Fix For: 10.0.0.CR1
>
>
> The DATETIME datatype in SQL Server has a precision of ~0.003 seconds.
> It sometimes can happen that an EJB timer gets scheduled to a timestamp which will get rounded after its insertion into the database, because the timestamps are generated with precision to miliseconds.
> After that, the timer service will be unable to locate this row, because it attempts to select using WHERE NEXT_DATE=$timestamp, where $timestamp is the original unrounded java.sql.Timestamp, and this condition no longer holds true.
> After a timer is scheduled to go off at such unfortunate timestamp, it will never go off again.
> The solution is to either truncate the milisecond part, or to use the newer DATETIME2 datatype, which has an accuracy of 100 nanoseconds (https://msdn.microsoft.com/en-us/library/bb677335.aspx). DATETIME2 is supported on SQL Server 2008+.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-4831) Clean up HornetQ modules
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4831?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4831.
----------------------------
> Clean up HornetQ modules
> ------------------------
>
> Key: WFLY-4831
> URL: https://issues.jboss.org/browse/WFLY-4831
> Project: WildFly
> Issue Type: Sub-task
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.Alpha5
>
>
> With the messaging subsystem becoming legacy and its runtime being removed, there is no sense to keep modules for HornetQ server runtime.
> However, we still need modules for:
> * HornetQ client (required for forward protocol compatibility)
> * HornetQ journal (used by other modules such as the transaction subsystem to provide its logging store)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months