[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
I think we have a discussion about this with Paul Gier, and the problem was with the fact that one never knows what will end up as a product, so the information is added when it pops out of Brew/Mead. Bringing Paul's attention.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2391) Wildfly caches content in exploded mode, breaking developer productivity
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis commented on WFLY-2391:
------------------------------------------
We definitely need to schedule a fix before final goes out.
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
> Key: WFLY-2391
> URL: https://issues.jboss.org/browse/WFLY-2391
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Environment: MacOSX with JBossTools 4.1.1.Beta1
> Reporter: Xavier Coulon
> Assignee: Stuart Douglas
> Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2391) Wildfly caches content in exploded mode, breaking developer productivity
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis updated WFLY-2391:
-------------------------------------
Priority: Critical (was: Major)
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
> Key: WFLY-2391
> URL: https://issues.jboss.org/browse/WFLY-2391
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Environment: MacOSX with JBossTools 4.1.1.Beta1
> Reporter: Xavier Coulon
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2341:
-----------------------------------
Verified that this is fixed in b114
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-2341
> URL: https://issues.jboss.org/browse/WFLY-2341
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Denis Kostousov
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> ... 8 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2386) Hibernate envers related issues on JDK8
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2386?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2386:
-----------------------------------
Just tested and can verify that this is fixed in b114
> Hibernate envers related issues on JDK8
> ---------------------------------------
>
> Key: WFLY-2386
> URL: https://issues.jboss.org/browse/WFLY-2386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Environment: latest JDK8 build
> Reporter: Tomaz Cerar
> Assignee: Scott Marlow
>
> There are many hibernate / envers related tests that fail when running Testsuite on JDK8
> {noformat}
> [31m17:03:15,195 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 4) MSC000001: Failed to start service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": org.jboss.msc.service.StartException in service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {noformat}
> for details see:
> http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WF_Master...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2441) Make Servlet container the default in Arquillian WildFly
by Karel Piwko (JIRA)
Karel Piwko created WFLY-2441:
---------------------------------
Summary: Make Servlet container the default in Arquillian WildFly
Key: WFLY-2441
URL: https://issues.jboss.org/browse/WFLY-2441
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: 8.0.0.Beta1
Reporter: Karel Piwko
Assignee: Ondrej Zizka
Priority: Critical
Current setting of jmx-as7 as default protocol complicated setup for consumers of Arquillian platform.
JMX-AS7 protocol should be used for testing container implementation, not for testing applications deployed on WildFly.
For that reason, WildFly testsuite should be the place where protocol is overridden to jmx-as7, not the other way around.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2440) Thread pool AccessControlContext Propagation
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2440:
--------------------------------------
Summary: Thread pool AccessControlContext Propagation
Key: WFLY-2440
URL: https://issues.jboss.org/browse/WFLY-2440
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.CR1
A decision was made within Java that newly created threads should inherit the access control context of their creator.
In general this was justified on the basis that if you are creating a thread you want it to inherit the permissions you already have.
Once we introduce thread pooling that logic no longer makes as much sense and there is not the same relationship between the thread that triggers it's creation and the long term life of that thread.
This may affect components outside of WildFly but I am raising it here as a top level task.
Should also note that JBoss Threads does already have some protection built in if a security manager is in use but there are times the AccessControlContext will be used without a security manager so more control is required.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2203) Error deploying multiple *-ds.xml files
by Isa Isa (JIRA)
[ https://issues.jboss.org/browse/WFLY-2203?page=com.atlassian.jira.plugin.... ]
Isa Isa commented on WFLY-2203:
-------------------------------
Hi Nick Howes Did you manage to get this resolved
> Error deploying multiple *-ds.xml files
> ---------------------------------------
>
> Key: WFLY-2203
> URL: https://issues.jboss.org/browse/WFLY-2203
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: Nick Howes
> Assignee: Stefano Maestri
> Priority: Minor
> Fix For: 8.0.0.Final
>
>
> Our individual *-ds.xml datasources were all deploying fine in Alpha4 but in the Beta1 nightlies this error appears on startup:
> {noformat}
> 15:07:52,111 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.D
> ataSourceStatisticsListener@7d18ac99" failed: java.lang.IllegalArgumentException: JBAS014742: A node is already registered at '(deployment => *)(subsy
> stem => datasources)(data-source => *)(statistics => jdbc)'
> at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1
> -SNAPSHOT]
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:149) [wildfly-controller-8
> .0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.
> 0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connec
> tor-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> {noformat}
> Our datasource files look like this. I haven't tried putting all the datasource elements into one file.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
> <datasource jndi-name="java:/AlphaDS" enabled="true" use-java-context="true" pool-name="AlphaDS">
> <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url>
> <driver>oracle</driver>
> <security>
> <user-name>XXX</user-name>
> <password>YYY</password>
> </security>
> <connection-property name="defaultNChar">true</connection-property>
> </datasource>
> </datasources>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
> <datasource jndi-name="java:/BetaDS" enabled="true" use-java-context="true" pool-name="BetaDS">
> <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url>
> <driver>oracle</driver>
> <security>
> <user-name>XXX</user-name>
> <password>YYY</password>
> </security>
> <connection-property name="defaultNChar">true</connection-property>
> </datasource>
> </datasources>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months