[JBoss JIRA] (AS7-5877) ClassCastException with ResteasyProviderFactory when including RESTEasy in two WARs
by Eric Wittmann (JIRA)
Eric Wittmann created AS7-5877:
----------------------------------
Summary: ClassCastException with ResteasyProviderFactory when including RESTEasy in two WARs
Key: AS7-5877
URL: https://issues.jboss.org/browse/AS7-5877
Project: Application Server 7
Issue Type: Bug
Components: Class Loading, REST
Affects Versions: 7.1.1.Final
Reporter: Eric Wittmann
Assignee: David Lloyd
Found what I think may be a classloading issue while working on the S-RAMP project.
We include RESTEasy in our WARs because we want a single WAR that runs in multiple containers *and* because we need a newer version of RESTEasy. If you deploy two WARs that both package RESTEasy, then you will get a ClassCastException. See the linked RESTEasy Jira issue I entered for this problem (I'm not sure if it's a bug in resteasy or jboss).
Ultimately it seems that a class is loaded from the RESTEasy module included in JBoss AS, despite that module being excluded via the jboss-deployment-structure.xml file.
A sample maven project showing this problem is included on the linked RESTEasy issue.
--
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, 11 months
[JBoss JIRA] (AS7-5875) Re-review CLI server certificate acceptance.
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-5875:
-------------------------------------
Summary: Re-review CLI server certificate acceptance.
Key: AS7-5875
URL: https://issues.jboss.org/browse/AS7-5875
Project: Application Server 7
Issue Type: Task
Components: CLI
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1
Can we remove the call loop and manage the user prompt and trust store replacement all within the trust manager?
--
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, 11 months
[JBoss JIRA] Created: (JBAS-9433) JBoss-6.1.0-SNAPSHOT - Adding @WebService causes EJBException "Named query not found"
by Ralf Battenfeld (JIRA)
JBoss-6.1.0-SNAPSHOT - Adding @WebService causes EJBException "Named query not found"
-------------------------------------------------------------------------------------
Key: JBAS-9433
URL: https://issues.jboss.org/browse/JBAS-9433
Project: Legacy JBoss Application Server 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB
Affects Versions: 6.0.0.Final
Environment: Windows Vista 32-bit, JDK 1.6.0_21-b07
Reporter: Ralf Battenfeld
Assignee: Carlo de Wolf
Attachments: TestNamedQueryException.zip
We faced an issue when a webservice annotation is added to a session bean and there are two persistence units defined. All of them are in the same ejb module defined and packed in an ear. The behaviour is not predictable, some times it works but most of the times, not. Without the @Webservice annotation, we don't have deployment issues.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (JBAS-9391) EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored
by Pierre Kobylanski (JIRA)
EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored
---------------------------------------------------------------------------------------------
Key: JBAS-9391
URL: https://issues.jboss.org/browse/JBAS-9391
Project: Legacy JBoss Application Server 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB
Affects Versions: 6.0.0.Final
Environment: $ uname -a
Linux tumlatum 2.6.38-2-686-bigmem #1 SMP Sun May 8 15:43:39 UTC 2011 i686 GNU/Linux
Reporter: Pierre Kobylanski
Assignee: Carlo de Wolf
ejb 3.1 spec [4.8.4 Singleton Error Handling] says that "Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance."
I tried to raise a system exception in the @PostConstruct method of a singleton bean. Logs show the deployment error. But I then can access and call the singleton methods.
-- Full paragraph 4.8.4: -----------------------------
Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance. Possible initialization errors include injection failure, a system exception thrown from a PostConstruct method, or the failure of a PostConstruct method container-managed transaction to successfully commit. If a singleton fails to initialize, attempted invocations on the Singleton result in an exception as defined by Section 3.4.3 and Section 3.4.4.
------------------------------------------------------
I tested to raise a system exception (throw new RuntimeException()) in the @PostConstruct method.
-- Logs show the error -------------------------------
ERROR [AbstractKernelController] Error installing to Start: name=startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter aliases=[startup-singleton-initiator:bean=counter,topLevelUnit=ts.ear,unit=testSingletonEjb.jar] state=Create: java.lang.RuntimeException: Could not invoke PostConstruct on the newly created bean instance
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:137) [:1.0.0-alpha-28]
...
Caused by: testsingleton.exn.SE // class SE extends RuntimeException{}
at testsingleton.ejb.CounterEjb.pc(CounterEjb.java:28)
DEPLOYMENTS IN ERROR:
Deployment "startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter" is in error due to the following reason(s): testsingleton.exn.SE
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1228) [:2.2.0.GA]
------------------------------------------------------
However, it is after that possible to access the singleton through a JNDI lookup and successfully call its methods.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (EJBTHREE-2255) @SecurityDomain has no equivalent for <security-domain/>
by Richard Kennard (JIRA)
@SecurityDomain has no equivalent for <security-domain/>
--------------------------------------------------------
Key: EJBTHREE-2255
URL: https://issues.jboss.org/browse/EJBTHREE-2255
Project: EJB 3.0
Issue Type: Bug
Environment: JBoss 6.0.0.Final
Reporter: Richard Kennard
Test case attached.
We have found it useful to turn off the security-domain for certain EJBs so that they can be accessed from unauthenticated clients. We can do this in jboss.xml using <security-domain /> but not, it seems, from an EJB using the @SessionDomain annotation.
A @SessionDomain( "" ) is simply ignored.
We're not a big fan of hard-coding security domain names inside EJBs, but it seems fine to be able to say 'this EJB has no security domain at all'. Should the annotation work for this?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months