[JBoss JIRA] (WFCORE-209) do not export api if excluded within jboss-deployment-structure.xml
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-209?page=com.atlassian.jira.plugin... ]
Tomaz Cerar closed WFCORE-209.
------------------------------
Fix Version/s: 2.0.0.Final
Resolution: Out of Date
Fixed in WildFly 9.
> do not export api if excluded within jboss-deployment-structure.xml
> -------------------------------------------------------------------
>
> Key: WFCORE-209
> URL: https://issues.jboss.org/browse/WFCORE-209
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Environment: JBoss EAP 6.3 + Spring 3.2.11.RELEASE
> Reporter: Mathieu Lachance
> Fix For: 2.0.0.Final
>
>
> I'm currently trying to upgrade JPA 2.0 to JPA 2.1 in JBoss EAP 6.3 by leveraging the jboss-deployment-structure.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclude-subsystems>
> <subsystem name="jpa" />
> <subsystem name="webservices" />
> <subsystem name="weld" />
> </exclude-subsystems>
> <exclusions>
> <module name="javax.persistence.api" />
> <module name="org.hibernate" />
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> {code}
> When trying to deploy my war (containing all hibernate 4.3.6 jars) I get the following error:
> {quote}
> Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
> at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:936) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:824) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3788) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3742) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1410) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1844) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:398) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:152) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:290) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:310) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1573) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1511) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> ... 23 more
> {quote}
> {{Index}} was introduced with JPA 2.1 and even though:
> 1. my application bundle the correct JPA jar
> 2. my application excluded the javax.persistence.api
> 3. my application excluded the jpa subsystem
> I get a conflict.
> The only way I made it possible to upgrade the JPA version was to explicitely state to not export the javax.persistence.api (see workaround). This way of doing thing though is not portable (as it impacts all other war deployed in the JBoss server) and is critical in our situation.
> The issue might/is probably not be related to jboss-modules component but I was not able to find within the jboss sources the explicit line of code responsible of reading the jboss-deployment-structure.xml.
> If you can point me out the correct component it will be a pleasure to help resolve the issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1160) It is possible to create duplicate drools runtime
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1160?page=com.atlassian.jira.plugi... ]
Tomas David updated DROOLS-1160:
--------------------------------
Labels: reported-by-qe (was: )
> It is possible to create duplicate drools runtime
> -------------------------------------------------
>
> Key: DROOLS-1160
> URL: https://issues.jboss.org/browse/DROOLS-1160
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Environment: Drools plugin 6.4.1
> Reporter: Tomas David
> Assignee: Robert (Bob) Brodt
> Priority: Minor
> Labels: reported-by-qe
>
> It is possible to create drools runtime with a name of runtime which already exists. If the location or version text input is changed, the OK button is enabled. Only case when it is not possible to create duplicate runtime is when the name input is changed as the last input to the duplicate name.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-209) do not export api if excluded within jboss-deployment-structure.xml
by Antoine Rey (JIRA)
[ https://issues.jboss.org/browse/WFCORE-209?page=com.atlassian.jira.plugin... ]
Antoine Rey commented on WFCORE-209:
------------------------------------
I've got the same Issue with JBoss 6.4 EAP.
The workarround 1 works fine but this is non-portable.
The workarround 2 works with WAR but not EAR. Do you have any idea?
> do not export api if excluded within jboss-deployment-structure.xml
> -------------------------------------------------------------------
>
> Key: WFCORE-209
> URL: https://issues.jboss.org/browse/WFCORE-209
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Environment: JBoss EAP 6.3 + Spring 3.2.11.RELEASE
> Reporter: Mathieu Lachance
>
> I'm currently trying to upgrade JPA 2.0 to JPA 2.1 in JBoss EAP 6.3 by leveraging the jboss-deployment-structure.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclude-subsystems>
> <subsystem name="jpa" />
> <subsystem name="webservices" />
> <subsystem name="weld" />
> </exclude-subsystems>
> <exclusions>
> <module name="javax.persistence.api" />
> <module name="org.hibernate" />
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> {code}
> When trying to deploy my war (containing all hibernate 4.3.6 jars) I get the following error:
> {quote}
> Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
> at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:936) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:824) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3788) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3742) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1410) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1844) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:398) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:152) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:290) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:310) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1573) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1511) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> ... 23 more
> {quote}
> {{Index}} was introduced with JPA 2.1 and even though:
> 1. my application bundle the correct JPA jar
> 2. my application excluded the javax.persistence.api
> 3. my application excluded the jpa subsystem
> I get a conflict.
> The only way I made it possible to upgrade the JPA version was to explicitely state to not export the javax.persistence.api (see workaround). This way of doing thing though is not portable (as it impacts all other war deployed in the JBoss server) and is critical in our situation.
> The issue might/is probably not be related to jboss-modules component but I was not able to find within the jboss sources the explicit line of code responsible of reading the jboss-deployment-structure.xml.
> If you can point me out the correct component it will be a pleasure to help resolve the issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1160) It is possible to create duplicate drools runtime
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1160?page=com.atlassian.jira.plugi... ]
Tomas David updated DROOLS-1160:
--------------------------------
Steps to Reproduce:
# Create runtime with name "aaa", some location and the version will be automatically completed.
# Try to create a second runtime with the same name.
# First type the name to the input and then select the location of runtime.
was:
# Create runtime with name "aaa", some location and the version will be automatically completed.
# Try to create a second runtime with the same name.
# First type name to the input and then select location of runtime.
> It is possible to create duplicate drools runtime
> -------------------------------------------------
>
> Key: DROOLS-1160
> URL: https://issues.jboss.org/browse/DROOLS-1160
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Environment: Drools plugin 6.4.1
> Reporter: Tomas David
> Assignee: Robert (Bob) Brodt
> Priority: Minor
>
> It is possible to create drools runtime with a name of runtime which already exists. If the location or version text input is changed, the OK button is enabled. Only case when it is not possible to create duplicate runtime is when the name input is changed as the last input to the duplicate name.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1160) It is possible to create duplicate drools runtime
by Tomas David (JIRA)
Tomas David created DROOLS-1160:
-----------------------------------
Summary: It is possible to create duplicate drools runtime
Key: DROOLS-1160
URL: https://issues.jboss.org/browse/DROOLS-1160
Project: Drools
Issue Type: Bug
Components: eclipse plugin
Environment: Drools plugin 6.4.1
Reporter: Tomas David
Assignee: Robert (Bob) Brodt
Priority: Minor
It is possible to create drools runtime with a name of runtime which already exists. If the location or version text input is changed, the OK button is enabled. Only case when it is not possible to create duplicate runtime is when the name input is changed as the last input to the duplicate name.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6583) Session leak on SmartOS hosts
by Michael Noack (JIRA)
[ https://issues.jboss.org/browse/WFLY-6583?page=com.atlassian.jira.plugin.... ]
Michael Noack commented on WFLY-6583:
-------------------------------------
[~pferraro] I used both approaches. I started out with the HttpSessionListener for unrelated reasons. When wildfly would start to crash every so often being OOM, I started to investigate and found unclosed sessions. I had help from my database here and only confirmed later that the session close was missing in the logs as well.
So when running a test "grep sessionCreated server.log | wc -l" returns a number higher than "grep sessionDestroyed server.log | wc -l" on both server nodes.
Running the management operation to count active sessions on both nodes returns a similar discrepancy.
Both approaches have been taken after all sessions should have been timed out long ago.
I can only reproduce this behavior when running on Solaris kernels. So far I have only tried it on SmartOS and BrandZ kernels running on SmartOS though. I would expect to see the same issue on Illumous and OpenSolaris as well.
> Session leak on SmartOS hosts
> -----------------------------
>
> Key: WFLY-6583
> URL: https://issues.jboss.org/browse/WFLY-6583
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.0.Final, 9.0.0.Final, 10.0.0.Final
> Environment: CentOS 7 or SmartOS instance using Joyents Infrastructure/Bare metal container.
> [root@979638eb-b45c-45b3-9fdb-d7f48276e4ef /]# java -version
> java version "1.8.0_77"
> Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> [root@979638eb-b45c-45b3-9fdb-d7f48276e4ef /]# uname -a
> Linux 979638eb-b45c-45b3-9fdb-d7f48276e4ef 3.10.0 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux
> [root@979638eb-b45c-45b3-9fdb-d7f48276e4ef /]# cat /etc/issue
> \S
> Kernel \r on an \m
> Reporter: Michael Noack
> Assignee: Paul Ferraro
> Priority: Minor
>
> When running Wildfly 8.2.0-Final, 9.0.0-Final or 10.0.0-Final in domain mode using the full-ha profile some sessions never get closed when running on SmartOS or a BrandZ kernel on SmartOS. The amount of unclosed sessions rises slowly. With 1 session per second and server created, roughly 30-50 sessions are left unclosed on each server. I've been keeping track of this issue for almost a year now and handled it by restarting the entire cluster at first. It took me a while to connect the dots here.
> When registering a HttpSessionListener and logging any sessionCreated(HttpSessionEvent se) and sessionDestroyed(HttpSessionEvent se) one can cleary see some sessions never generate the sessionDestroyed event.
> The problem disappears when running the very same setup on a KVM instance of CentOS 6 or 7 (regardless whether the KVM host is SmartOS or Linux).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years