[JBoss JIRA] (WFLY-9919) Deployment throwing exception on upgrade to JBOSS EAP 7.1
by Sreecharan Challagundla (JIRA)
[ https://issues.jboss.org/browse/WFLY-9919?page=com.atlassian.jira.plugin.... ]
Sreecharan Challagundla commented on WFLY-9919:
-----------------------------------------------
hello Jai,
Its BPM tool ear( Pega v7.3.1 for JBoss7 ear)... already provided as part of RH case.
> Deployment throwing exception on upgrade to JBOSS EAP 7.1
> ---------------------------------------------------------
>
> Key: WFLY-9919
> URL: https://issues.jboss.org/browse/WFLY-9919
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Reporter: Sainath Machupalli
> Assignee: Jason Greene
>
> Our deployment worked on EAP 7 and we started seeing the below exception when we upgraded to EAP 7.1.
>
> 2018-02-07 09:19:46,234 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment inner.war
> 2018-02-07 09:19:46,239 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "inner.war" of deployment "myEAR.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: VFS000025: Given parent ("/content/myEAR.ear/inner.war") is not an ancestor of this virtual file
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:119)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:112)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.createBeanArchiveId(BeanArchiveProcessor.java:348)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.processResourceRoot(BeanArchiveProcessor.java:296)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.handleResourceRoot(BeanArchiveProcessor.java:237)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.access$100(BeanArchiveProcessor.java:206)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor.deploy(BeanArchiveProcessor.java:113)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
>
> Our jboss-deployment-structure.xml is as below.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <sub-deployment name="inner.war">
> <dependencies>
> <module name="org.jboss.remote-naming"/>
> </dependencies>
> <resources>
> <resource-root path="APP-INF/lib/dep1.jar" />
> <resource-root path="APP-INF/lib/dep2.jar" />
> </resources>
> </sub-deployment>
> </jboss-deployment-structure>
>
> Our EAR structure is below,
> >myEAR.ear
> >inner.war
> >APP-INF
> >lib
> >dep1.jar
> >dep2.jar
> >META-INF
> >jboss-deployment-structure.xml
>
> The same structure and jboss-deployment-structure.xml worked for us on JBOSS EAP 7.
>
> Is there any change in deployment structure? or is it a BUG?
> More details @ https://developer.jboss.org/message/980164#980164
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10373) Standard undertow subsystem config should declare the default-[server|virtual-host|servlet-container|security-domain] attributes
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-10373:
---------------------------------------
Summary: Standard undertow subsystem config should declare the default-[server|virtual-host|servlet-container|security-domain] attributes
Key: WFLY-10373
URL: https://issues.jboss.org/browse/WFLY-10373
Project: WildFly
Issue Type: Enhancement
Components: Web (Undertow)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
The various default-xxx attributes on root undertow subsystem element if not set have default values that map to the standard child elements in the config. The problem with relying on those defaults and not specifying the values is their usage becomes "black magic" and the fact that things will fail if the child elements are removed or renamed is lost.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10372) Upgrade to Hibernate Validator 6.0.10.Final
by Guillaume Smet (JIRA)
[ https://issues.jboss.org/browse/WFLY-10372?page=com.atlassian.jira.plugin... ]
Guillaume Smet updated WFLY-10372:
----------------------------------
Description:
This version fixes a couple of important issues:
* https://hibernate.atlassian.net/browse/HV-1604 - Initializing {{JPATraversableResolver}} fails with {{IllegalAccessException}}: this is a regression from 6.0.3.Final, the {{JPATraversableResolver}} was not correctly instantiated and thus not used, even in a JPA environment.
* https://hibernate.atlassian.net/browse/HV-1609 - CDI extension should not rely on {{@WithAnnotations}} filtering: {{@WithAnnotations}} does not consider the annotations in the class hierarchy so a bean with constraint annotations only in the class hierarchy would not see these constraints applied.
* https://hibernate.atlassian.net/browse/HV-1614 - Unable to specify constraints at more than 1 nested parameter of a typed container: in the programmatic API, nested container element constraints and cascading were not working as expected.
It is only available in EE8 preview mode.
Note: this upgrade will require we upgrade the Bean Validation TCK used to validate EE8 to 2.0.3.Final (some tests will fail otherwise).
was:
This version fixes a couple of important issues:
* https://hibernate.atlassian.net/browse/HV-1604 - Initializing {{JPATraversableResolver}} fails with {{IllegalAccessException}}: this is a regression from 6.0.3.Final, the {{JPATraversableResolver}} was not correctly instantiated and thus not used, even in a JPA environment.
* https://hibernate.atlassian.net/browse/HV-1609 - CDI extension should not rely on {{@WithAnnotations}} filtering: {{@WithAnnotations}} does not consider the annotations in the class hierarchy so a bean with constraint annotations only in the class hierarchy would not see these constraints applied.
* https://hibernate.atlassian.net/browse/HV-1614 - Unable to specify constraints at more than 1 nested parameter of a typed container: in the programmatic API, nested container element constraints and cascading were not working as expected.
It is only available in EE8 preview mode.
> Upgrade to Hibernate Validator 6.0.10.Final
> -------------------------------------------
>
> Key: WFLY-10372
> URL: https://issues.jboss.org/browse/WFLY-10372
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Bean Validation
> Reporter: Guillaume Smet
> Assignee: Guillaume Smet
>
> This version fixes a couple of important issues:
> * https://hibernate.atlassian.net/browse/HV-1604 - Initializing {{JPATraversableResolver}} fails with {{IllegalAccessException}}: this is a regression from 6.0.3.Final, the {{JPATraversableResolver}} was not correctly instantiated and thus not used, even in a JPA environment.
> * https://hibernate.atlassian.net/browse/HV-1609 - CDI extension should not rely on {{@WithAnnotations}} filtering: {{@WithAnnotations}} does not consider the annotations in the class hierarchy so a bean with constraint annotations only in the class hierarchy would not see these constraints applied.
> * https://hibernate.atlassian.net/browse/HV-1614 - Unable to specify constraints at more than 1 nested parameter of a typed container: in the programmatic API, nested container element constraints and cascading were not working as expected.
> It is only available in EE8 preview mode.
> Note: this upgrade will require we upgrade the Bean Validation TCK used to validate EE8 to 2.0.3.Final (some tests will fail otherwise).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10372) Upgrade to Hibernate Validator 6.0.10.Final
by Guillaume Smet (JIRA)
[ https://issues.jboss.org/browse/WFLY-10372?page=com.atlassian.jira.plugin... ]
Guillaume Smet updated WFLY-10372:
----------------------------------
Description:
This version fixes a couple of important issues:
* https://hibernate.atlassian.net/browse/HV-1604 - Initializing {{JPATraversableResolver}} fails with {{IllegalAccessException}}: this is a regression from 6.0.3.Final, the {{JPATraversableResolver}} was not correctly instantiated and thus not used, even in a JPA environment.
* https://hibernate.atlassian.net/browse/HV-1609 - CDI extension should not rely on {{@WithAnnotations}} filtering: {{@WithAnnotations}} does not consider the annotations in the class hierarchy so a bean with constraint annotations only in the class hierarchy would not see these constraints applied.
* https://hibernate.atlassian.net/browse/HV-1614 - Unable to specify constraints at more than 1 nested parameter of a typed container: in the programmatic API, nested container element constraints and cascading were not working as expected.
It is only available in EE8 preview mode.
*Note: this upgrade will require we upgrade the Bean Validation TCK used to validate EE8 to 2.0.3.Final (some tests will fail otherwise).*
was:
This version fixes a couple of important issues:
* https://hibernate.atlassian.net/browse/HV-1604 - Initializing {{JPATraversableResolver}} fails with {{IllegalAccessException}}: this is a regression from 6.0.3.Final, the {{JPATraversableResolver}} was not correctly instantiated and thus not used, even in a JPA environment.
* https://hibernate.atlassian.net/browse/HV-1609 - CDI extension should not rely on {{@WithAnnotations}} filtering: {{@WithAnnotations}} does not consider the annotations in the class hierarchy so a bean with constraint annotations only in the class hierarchy would not see these constraints applied.
* https://hibernate.atlassian.net/browse/HV-1614 - Unable to specify constraints at more than 1 nested parameter of a typed container: in the programmatic API, nested container element constraints and cascading were not working as expected.
It is only available in EE8 preview mode.
Note: this upgrade will require we upgrade the Bean Validation TCK used to validate EE8 to 2.0.3.Final (some tests will fail otherwise).
> Upgrade to Hibernate Validator 6.0.10.Final
> -------------------------------------------
>
> Key: WFLY-10372
> URL: https://issues.jboss.org/browse/WFLY-10372
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Bean Validation
> Reporter: Guillaume Smet
> Assignee: Guillaume Smet
>
> This version fixes a couple of important issues:
> * https://hibernate.atlassian.net/browse/HV-1604 - Initializing {{JPATraversableResolver}} fails with {{IllegalAccessException}}: this is a regression from 6.0.3.Final, the {{JPATraversableResolver}} was not correctly instantiated and thus not used, even in a JPA environment.
> * https://hibernate.atlassian.net/browse/HV-1609 - CDI extension should not rely on {{@WithAnnotations}} filtering: {{@WithAnnotations}} does not consider the annotations in the class hierarchy so a bean with constraint annotations only in the class hierarchy would not see these constraints applied.
> * https://hibernate.atlassian.net/browse/HV-1614 - Unable to specify constraints at more than 1 nested parameter of a typed container: in the programmatic API, nested container element constraints and cascading were not working as expected.
> It is only available in EE8 preview mode.
> *Note: this upgrade will require we upgrade the Bean Validation TCK used to validate EE8 to 2.0.3.Final (some tests will fail otherwise).*
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10372) Upgrade to Hibernate Validator 6.0.10.Final
by Guillaume Smet (JIRA)
Guillaume Smet created WFLY-10372:
-------------------------------------
Summary: Upgrade to Hibernate Validator 6.0.10.Final
Key: WFLY-10372
URL: https://issues.jboss.org/browse/WFLY-10372
Project: WildFly
Issue Type: Component Upgrade
Components: Bean Validation
Reporter: Guillaume Smet
Assignee: Jason Greene
This version fixes a couple of important issues:
* https://hibernate.atlassian.net/browse/HV-1604 - Initializing {{JPATraversableResolver}} fails with {{IllegalAccessException}}: this is a regression from 6.0.3.Final, the {{JPATraversableResolver}} was not correctly instantiated and thus not used, even in a JPA environment.
* https://hibernate.atlassian.net/browse/HV-1609 - CDI extension should not rely on {{@WithAnnotations}} filtering: {{@WithAnnotations}} does not consider the annotations in the class hierarchy so a bean with constraint annotations only in the class hierarchy would not see these constraints applied.
* https://hibernate.atlassian.net/browse/HV-1614 - Unable to specify constraints at more than 1 nested parameter of a typed container: in the programmatic API, nested container element constraints and cascading were not working as expected.
It is only available in EE8 preview mode.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10260) NullPointerException when read deployment with jpa
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10260?page=com.atlassian.jira.plugin... ]
Claudio Miranda commented on WFLY-10260:
----------------------------------------
As WFLY-10364 is merged, I see there is no more errors when reading the entity-cache, so this is working now, thanks.
> NullPointerException when read deployment with jpa
> --------------------------------------------------
>
> Key: WFLY-10260
> URL: https://issues.jboss.org/browse/WFLY-10260
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Claudio Miranda
> Assignee: Gail Badner
> Priority: Blocker
> Fix For: 13.0.0.Beta1
>
> Attachments: wildfly-kitchensink.war
>
>
> There is a bug when reading deployment information with runtime and recursive.
> Looks like this is a regression from an older bug WFLY-1753
> {code}
> /host=master/server=server-three/deployment=kitchensink.war/subsystem=jpa:read-resource(include-runtime,recursive)
> {code}
> {code}
> [Server:server-three] 12:16:11,551 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 75) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> [Server:server-three] ("deployment" => "kitchensink.war"),
> [Server:server-three] ("subsystem" => "jpa"),
> [Server:server-three] ("hibernate-persistence-unit" => "kitchensink.war#primary"),
> [Server:server-three] ("entity-cache" => "org.jboss.as.quickstarts.kitchensink.model.Member")
> [Server:server-three] ]): java.lang.NullPointerException
> [Server:server-three] at org.hibernate.internal.CacheImpl.getSecondLevelCacheRegion(CacheImpl.java:376)
> [Server:server-three] at org.hibernate.internal.SessionFactoryImpl.getSecondLevelCacheRegion(SessionFactoryImpl.java:1171)
> [Server:server-three] at org.hibernate.stat.internal.ConcurrentStatisticsImpl.getSecondLevelCacheStatistics(ConcurrentStatisticsImpl.java:334)
> [Server:server-three] at org.jboss.as.jpa.hibernate5.management.HibernateEntityCacheStatistics.getStatistics(HibernateEntityCacheStatistics.java:94)
> [Server:server-three] at org.jboss.as.jpa.hibernate5.management.HibernateEntityCacheStatistics$4.invoke(HibernateEntityCacheStatistics.java:126)
> [Server:server-three] at org.jboss.as.jpa.hibernate5.management.HibernateAbstractStatistics.getValue(HibernateAbstractStatistics.java:99)
> [Server:server-three] at org.jboss.as.jpa.management.ManagementResourceDefinition$1.handle(ManagementResourceDefinition.java:130)
> [Server:server-three] at org.jboss.as.jpa.management.ManagementResourceDefinition$AbstractMetricsHandler.executeRuntimeStep(ManagementResourceDefinition.java:268)
> [Server:server-three] at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:59)
> [Server:server-three] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> [Server:server-three] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> [Server:server-three] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> [Server:server-three] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
> [Server:server-three] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> [Server:server-three] at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> [Server:server-three] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> [Server:server-three] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> [Server:server-three] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:249)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:190)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:143)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:139)
> [Server:server-three] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> [Server:server-three] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> [Server:server-three] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:198)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:162)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:158)
> [Server:server-three] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:158)
> [Server:server-three] at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> [Server:server-three] at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> [Server:server-three] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [Server:server-three] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [Server:server-three] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [Server:server-three] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [Server:server-three] at java.lang.Thread.run(Thread.java:748)
> [Server:server-three] at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months