February 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3870) Stateful beans should enlist the extended persistence context into the JTA indepedently of EntityManager invocation

by Scott Marlow (JIRA)

Scott Marlow created AS7-3870: --------------------------------- Summary: Stateful beans should enlist the extended persistence context into the JTA indepedently of EntityManager invocation Key: AS7-3870 URL: https://issues.jboss.org/browse/AS7-3870 Project: Application Server 7 Issue Type: Bug Components: JPA / Hibernate Affects Versions: 7.1.0.Final Reporter: Scott Marlow Assignee: Scott Marlow Fix For: 7.1.1.Final "7.9.1 Container Responsibilities: ... For stateful session beans with extended persistence contexts: ... When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and calls EntityManager.joinTransaction. " -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
4
0 / 0

[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ] Stuart Douglas updated AS7-3199: -------------------------------- Fix Version/s: (was: 7.1.1.Final) Priority: Major (was: Critical) Labels: (was: eap6_prd_req) > RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present > --------------------------------------------------------------------------------------------- > > Key: AS7-3199 > URL: https://issues.jboss.org/browse/AS7-3199 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Stuart Douglas > Attachments: ExampleJAXRS.war > > > If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed." > This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for > more than one application to be deployed +at the same effective servlet mapping+". > If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present

by Bill Burke (JIRA)

[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ] Bill Burke commented on AS7-3199: --------------------------------- What's amazing is that this is marked as a "BLOCKER" where there are a number of bugs fixed and scheduled for 2.3.2 that are vastly more critical than this. Let the project leads and people that actually answer user questions decide whether or not a bug/feature is a "BLOCKER" or not. > RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present > --------------------------------------------------------------------------------------------- > > Key: AS7-3199 > URL: https://issues.jboss.org/browse/AS7-3199 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Stuart Douglas > Priority: Critical > Labels: eap6_prd_req > Fix For: 7.1.1.Final > > Attachments: ExampleJAXRS.war > > > If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed." > This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for > more than one application to be deployed +at the same effective servlet mapping+". > If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-3817) Remove test topics and queues from default configurations

by Shelly McGowan (JIRA)

Shelly McGowan created AS7-3817: ----------------------------------- Summary: Remove test topics and queues from default configurations Key: AS7-3817 URL: https://issues.jboss.org/browse/AS7-3817 Project: Application Server 7 Issue Type: Bug Components: Server, Test Suite Reporter: Shelly McGowan Assignee: Jason Greene Highlighed in JBPAPP-6738, the default configuration files contain JMS destinations that are present only to satisfy tests in the integration test suite. {code} <jms-destinations> <jms-queue name="testQueue"> <entry name="queue/test"/> <entry name="java:jboss/exported/jms/queue/test"/> </jms-queue> <jms-topic name="testTopic"> <entry name="topic/test"/> <entry name="java:jboss/exported/jms/topic/test"/> </jms-topic> </jms-destinations> {code} The following tests are dependent on those: org.jboss.as.test.integration.ee.injection.resource.resourceref.ResourceRefTestCase.org.jboss.as.test.integration.ee.injection.resource.resourceref.ResourceRefTestCase org.jboss.as.test.integration.ejb.mdb.JMSMessageDrivenBeanTestCase.testSendMessage org.jboss.as.test.integration.ejb.mdb.timerservice.SimpleTimerMDBTestCase.testAnnotationTimeoutMethod org.jboss.as.test.integration.ejb.mdb.timerservice.SimpleTimerMDBTestCase.testTimedObjectTimeoutMethod org.jboss.as.test.integration.ejb.pool.lifecycle.PooledEJBLifecycleTestCase.testMDB Probably should consider a common target to create these for these and other tests to use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
10
0 / 0

[JBoss JIRA] (AS7-3888) Loading custom login module from ear without the need for installing it as a jboss module

by Daniel Jipa (JIRA)

Daniel Jipa created AS7-3888: -------------------------------- Summary: Loading custom login module from ear without the need for installing it as a jboss module Key: AS7-3888 URL: https://issues.jboss.org/browse/AS7-3888 Project: Application Server 7 Issue Type: Enhancement Components: Security Affects Versions: 7.1.0.Final Environment: Reproduced on Ubuntu 10.04.3 LTS, CentOS release 5.7, Windows 7 Reporter: Daniel Jipa Assignee: Anil Saldhana When using a remote jndi connection to AS and a custom security-realm for it that is tied to a custom login module the authentication only works when packaging the class in a jar and installing it on jboss_install_dir/modules/org/jboss/as/remoting/main. It should be loadable from ear also. More details here: https://community.jboss.org/thread/195501 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
9
0 / 0

[JBoss JIRA] (AS7-3770) Expose external mechanism to determine master status of SingletonService

by Paul Ferraro (JIRA)

Paul Ferraro created AS7-3770: --------------------------------- Summary: Expose external mechanism to determine master status of SingletonService Key: AS7-3770 URL: https://issues.jboss.org/browse/AS7-3770 Project: Application Server 7 Issue Type: Feature Request Components: Clustering Affects Versions: 7.1.0.CR1b Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 7.1.1.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
2
0 / 0

[JBoss JIRA] (AS7-3506) SSL configuration properties should support expressions

by Tomas Repel (JIRA)

Tomas Repel created AS7-3506: -------------------------------- Summary: SSL configuration properties should support expressions Key: AS7-3506 URL: https://issues.jboss.org/browse/AS7-3506 Project: Application Server 7 Issue Type: Enhancement Affects Versions: 7.1.0.CR1b Reporter: Tomas Repel Priority: Minor Configuration of SSL/HTTPS in standalone.xml (element connector and its sub-element ssl) would be much more convenient if the ssl-element's attributes certificate-key-file and ca-certificate-file support expressions. See similar issue https://issues.jboss.org/browse/AS7-3356. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
4
0 / 0

[JBoss JIRA] (AS7-3882) Configuration for Jacorb does not use jboss.bind.address config property

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-3882?page=com.atlassian.jira.plugin.s... ] Brian Stansberry resolved AS7-3882. ----------------------------------- Fix Version/s: 7.1.1.Final (was: 7.1.2.Final) Resolution: Done > Configuration for Jacorb does not use jboss.bind.address config property > ------------------------------------------------------------------------ > > Key: AS7-3882 > URL: https://issues.jboss.org/browse/AS7-3882 > Project: Application Server 7 > Issue Type: Bug > Components: IIOP > Affects Versions: 7.1.0.Final > Reporter: Pavel Slavicek > Assignee: Brian Stansberry > Fix For: 7.1.1.Final > > > Configuration for Jacorb in socket-binding-group (standalone-*.xml) does not use jboss.bind.address config property and uses 127.0.0.1. > We are not able to start two EAPs on one machine with different IPs. > {code} > <interfaces> > <interface name="management"> > <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> > </interface> > <interface name="public"> > <inet-address value="${jboss.bind.address:127.0.0.1}"/> > </interface> > <interface name="unsecure"> >  > <inet-address value="127.0.0.1"/> > </interface> > </interfaces> > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-3893) org.jboss.as.clustering.infinispan should not have dependency on org.hibernate.infinispan

by Paul Ferraro (JIRA)

Paul Ferraro created AS7-3893: --------------------------------- Summary: org.jboss.as.clustering.infinispan should not have dependency on org.hibernate.infinispan Key: AS7-3893 URL: https://issues.jboss.org/browse/AS7-3893 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 7.1.1.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
2
0 / 0

[JBoss JIRA] (AS7-3847) Non-standard format of IPv6 address(-es) in LOG files

by Pavel Janousek (JIRA)

[ https://issues.jboss.org/browse/AS7-3847?page=com.atlassian.jira.plugin.s... ] Pavel Janousek updated AS7-3847: -------------------------------- Description: There are several places where some IPv6 address related info is logged. The format of a such info is formally correct, but used format is against [RFC-5952|http://tools.ietf.org/html/rfc5952] - this RFC has status of +Proposed standard+ and I don't know any software product which doesn't follow it (at least by-default). I think in enterprise product we should not violate this RFC. I'm mentioning about LOG messages like: {code} 15:14:15,985 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on /0:0:0:0:0:0:0:1%1:9999 15:14:15,990 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on localhost6.localdomain6/0:0:0:0:0:0:0:1%1:4447 {code} In both lines IPv6 address should be stretched to "::1" string. The second related issue (JBossWeb part) is tracked as AS7-3851. was: There are several places where some IPv6 address related info is logged. The format of a such info is formally correct, but used format is against [RFC-5952|http://tools.ietf.org/html/rfc5952] - this RFC has status of +Proposed standard+ and I don't know any software product which doesn't follow it (at least by-default). I think in enterprise product we should not violate this RFC. I'm mentioning about LOG messages like: {code} 15:14:15,985 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on /0:0:0:0:0:0:0:1%1:9999 15:14:15,990 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on localhost6.localdomain6/0:0:0:0:0:0:0:1%1:4447 {code} In both lines IPv6 address should be stretched to "::1" string. More "funny" and obfuscated version of the same LOG content is LOG line like this: {code} 15:14:14,363 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http--0%3A0%3A0%3A0%3A0%3A0%3A0%3A1%251-8080 {code} But both version of the issue is almost unreadable by human. > Non-standard format of IPv6 address(-es) in LOG files > ----------------------------------------------------- > > Key: AS7-3847 > URL: https://issues.jboss.org/browse/AS7-3847 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.0.Final > Reporter: Pavel Janousek > > There are several places where some IPv6 address related info is logged. The format of a such info is formally correct, but used format is against [RFC-5952|http://tools.ietf.org/html/rfc5952] - this RFC has status of +Proposed standard+ and I don't know any software product which doesn't follow it (at least by-default). > I think in enterprise product we should not violate this RFC. > I'm mentioning about LOG messages like: > {code} > 15:14:15,985 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on /0:0:0:0:0:0:0:1%1:9999 > 15:14:15,990 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on localhost6.localdomain6/0:0:0:0:0:0:0:1%1:4447 > {code} > In both lines IPv6 address should be stretched to "::1" string. > The second related issue (JBossWeb part) is tracked as AS7-3851. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2012