[JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.x
by Emmanuel Bernard (JIRA)
[ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.... ]
Emmanuel Bernard commented on WFLY-6854:
----------------------------------------
[~smarlow] about the failed PR, who is tracking and dispatching the necessary work? You? Better get that moving :)
> Upgrade Hibernate ORM to 5.1.x
> ------------------------------
>
> Key: WFLY-6854
> URL: https://issues.jboss.org/browse/WFLY-6854
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Emmanuel Bernard
> Assignee: Scott Marlow
> Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.x
by Emmanuel Bernard (JIRA)
[ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.... ]
Emmanuel Bernard commented on WFLY-6854:
----------------------------------------
I think WF 11 is a good target, we never know what the TCK will bring as surprise. I don't see WF 10.1 as a necessary target at all, it stresses everyone for not much.
> Upgrade Hibernate ORM to 5.1.x
> ------------------------------
>
> Key: WFLY-6854
> URL: https://issues.jboss.org/browse/WFLY-6854
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Emmanuel Bernard
> Assignee: Scott Marlow
> Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6868) Remove deprecated and duplicated class AcceptEncodingGZIPInterceptor in rts subsystem
by Jim Ma (JIRA)
Jim Ma created WFLY-6868:
----------------------------
Summary: Remove deprecated and duplicated class AcceptEncodingGZIPInterceptor in rts subsystem
Key: WFLY-6868
URL: https://issues.jboss.org/browse/WFLY-6868
Project: WildFly
Issue Type: Task
Components: XTS
Affects Versions: 10.0.0.Final
Reporter: Jim Ma
Assignee: Jim Ma
Fix For: 10.1.0.CR1
AcceptEncodingGZIPInterceptor is a deprecated class and AcceptEncodingGZIPFilter is a replacement since jaxrs 2.0. We can remove this deprecated class because AcceptEncodingGZIPFilter is already added in AbstractRTSApplication.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6867) "JVM Options" should not be marked with asterisk
by Chao Wang (JIRA)
Chao Wang created WFLY-6867:
-------------------------------
Summary: "JVM Options" should not be marked with asterisk
Key: WFLY-6867
URL: https://issues.jboss.org/browse/WFLY-6867
Project: WildFly
Issue Type: Bug
Components: Web Console
Affects Versions: 10.0.0.Final
Reporter: Chao Wang
Assignee: Chao Wang
When editing a JVM configuration through the console in domain mode, "JVM Options" is marked with an asterisk. But "JVM Options" are not required so this asterisk should be removd.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6866) "JVM Options" should not be marked with asterisk
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6866?page=com.atlassian.jira.plugin.... ]
Chao Wang updated WFLY-6866:
----------------------------
Summary: "JVM Options" should not be marked with asterisk (was: [GSS](7.0.z) "JVM Options" should not be marked with asterisk)
> "JVM Options" should not be marked with asterisk
> ------------------------------------------------
>
> Key: WFLY-6866
> URL: https://issues.jboss.org/browse/WFLY-6866
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 10.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Original Estimate: 3 hours
> Remaining Estimate: 3 hours
>
> When editing a JVM configuration through the console in domain mode, "JVM Options" is marked with an asterisk. But "JVM Options" are not required so this asterisk should be removd.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6866) [GSS](7.0.z) "JVM Options" should not be marked with asterisk
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6866?page=com.atlassian.jira.plugin.... ]
Chao Wang moved JBEAP-5339 to WFLY-6866:
----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6866 (was: JBEAP-5339)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web Console
(was: Web Console)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.GA)
> [GSS](7.0.z) "JVM Options" should not be marked with asterisk
> -------------------------------------------------------------
>
> Key: WFLY-6866
> URL: https://issues.jboss.org/browse/WFLY-6866
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 10.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Original Estimate: 3 hours
> Remaining Estimate: 3 hours
>
> When editing a JVM configuration through the console in domain mode, "JVM Options" is marked with an asterisk. But "JVM Options" are not required so this asterisk should be removd.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1561) read-resource responds with incorrect address when going through host controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1561?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1561:
-------------------------------------
Fix Version/s: 3.0.0.Alpha4
(was: 3.0.0.Alpha2)
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1561
> URL: https://issues.jboss.org/browse/WFCORE-1561
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: John Mazzitelli
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha4
>
>
> I have a typical small domain setup: one master host controller (aka domain controller) and one slave host controller with "server-one" and "server-two" servers.
> I need to discover things running in those two servers (server-one and server-two). As part of the discovery, I invoke read-resource operations via the management interface - for example, to discover all the datasources in server-one:
> /host=slave/server=server-one/subsystem=datasources/data-source=*/:read-resource(include-runtime=true)
> For each returned datasource, I need to know that datasource's full address. The problem is, I do not get the full address. Instead, the CLI returns the following partial address:
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> "outcome" => "success",
> "result" => {
> "allocation-retry" => undefined,
> ...and the rest of the properties for the ExampleDS datasource...
> }
> }
> }]
> }
> The address should be the full address of:
> "address" => [
> ("host" => "slave"),
> ("server" => "server-one"),
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> NOTE! This problem occurs both when I connect to the domain controller and when I connect to the slave host controller - it doesn't matter, the CLI returns the same erroneous address if connected to either one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6865) org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-6865?page=com.atlassian.jira.plugin.... ]
Brad Maxwell updated WFLY-6865:
-------------------------------
Description:
{code}
helloWorld.ear
- helloWorld-ejb.jar
- HelloBean - @Stateless EJB extends AbstractBean
- lib
- helloWorld-api.jar
- META-INF
- jandex.idx
- Hello - EJB interface
- AbstractBean - abstract class which has @PostConstruct and implements Hello
helloWorld2.ear
- helloWorld2-ejb.jar
- HelloBean2 - @Startup @Singleton extends AbstractBean
- META-INF
- jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
{code}
To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
{code}
19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
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:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
... 6 more
{code}
was:
helloWorld.ear
- helloWorld-ejb.jar
- HelloBean - @Stateless EJB extends AbstractBean
- lib
- helloWorld-api.jar
- META-INF
- jandex.idx
- Hello - EJB interface
- AbstractBean - abstract class which has @PostConstruct and implements Hello
helloWorld2.ear
- helloWorld2-ejb.jar
- HelloBean2 - @Startup @Singleton extends AbstractBean
- META-INF
- jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
{code}
19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
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:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
... 6 more
{code}
> org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6865
> URL: https://issues.jboss.org/browse/WFLY-6865
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Jason Greene
> Attachments: reproducer.zip
>
>
> {code}
> helloWorld.ear
> - helloWorld-ejb.jar
> - HelloBean - @Stateless EJB extends AbstractBean
> - lib
> - helloWorld-api.jar
> - META-INF
> - jandex.idx
> - Hello - EJB interface
> - AbstractBean - abstract class which has @PostConstruct and implements Hello
> helloWorld2.ear
> - helloWorld2-ejb.jar
> - HelloBean2 - @Startup @Singleton extends AbstractBean
> - META-INF
> - jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
> {code}
> To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
> When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
> It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
> {code}
> 19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 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:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6865) org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-6865?page=com.atlassian.jira.plugin.... ]
Brad Maxwell moved JBEAP-5337 to WFLY-6865:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6865 (was: JBEAP-5337)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Server
(was: Server)
Affects Version/s: 10.0.0.Final
(was: 7.0.1.GA)
> org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6865
> URL: https://issues.jboss.org/browse/WFLY-6865
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Jason Greene
> Attachments: reproducer.zip
>
>
> helloWorld.ear
> - helloWorld-ejb.jar
> - HelloBean - @Stateless EJB extends AbstractBean
> - lib
> - helloWorld-api.jar
> - META-INF
> - jandex.idx
> - Hello - EJB interface
> - AbstractBean - abstract class which has @PostConstruct and implements Hello
> helloWorld2.ear
> - helloWorld2-ejb.jar
> - HelloBean2 - @Startup @Singleton extends AbstractBean
> - META-INF
> - jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
> To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
> When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
> It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
> {code}
> 19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 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:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months