[JBoss JIRA] (AS7-3162) RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
by Pavel Janousek (Moved) (JIRA)
[ https://issues.jboss.org/browse/AS7-3162?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek moved JBPAPP-7833 to AS7-3162:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-3162 (was: JBPAPP-7833)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.0.CR1b
(was: EAP 6.0.0 DR 11)
Component/s: REST
(was: RESTEasy)
Security: (was: JBoss Internal)
Docs QE Status: (was: NEW)
> RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3162
> URL: https://issues.jboss.org/browse/AS7-3162
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Weinan Li
> Priority: Blocker
>
> I've deployment like this:
> {code}
> @Deployment
> public static Archive<?> deploy() {
> WebArchive war = ShrinkWrap.create(WebArchive.class, "jaxrsnoap.war");
> war.addPackage(HttpRequest.class.getPackage());
> war.addClasses(ApplicationTestCase.class, ApplicationInvalid1.class);
> war.addAsWebInfResource(
> WebXml.get("<servlet-mapping>\n"
> + " <servlet-name>javax.ws.rs.core.Application</servlet-name>\n"
> + " <url-pattern>/myjaxrs/*</url-pattern>\n"
> + "</servlet-mapping>\n" + "\n"), "web.xml");
> return war;
> }
> {code}
> This deployment fails during deploying because of "Context [/jaxrsnoap] startup failed due to previous errors: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name javax.ws.rs.core.Application"
> ApplicationInvalid1 is empty subclass of javax.ws.rs.core.Application like:
> {code}
> public class ApplicationInvalid1 extends Application {
> private Set<Class<?>> classes = new HashSet<Class<?>>();
> public ApplicationInvalid1() {
> }
> @Override
> public Set<Class<?>> getClasses() {
> return classes;
> }
> }
> {code}
> There isn't any reference to this class in web.xml or somewhere else. Only class is placed on classpath. If I remove this class from deployment (= change appropriate line to "war.addClasses(ApplicationTestCase.class);", everything will be OK.
--
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, 3 months
[JBoss JIRA] Created: (AS7-1230) Exception during message inflow is not properly logged
by Carlo de Wolf (JIRA)
Exception during message inflow is not properly logged
------------------------------------------------------
Key: AS7-1230
URL: https://issues.jboss.org/browse/AS7-1230
Project: Application Server 7
Issue Type: Bug
Reporter: Carlo de Wolf
Fix For: 7.1.0.CR1
{noformat}
11:56:03,323 ERROR [stderr] (jca-short-running-threads-threads - 2) java.lang.IllegalStateException: No component instance associated
11:56:03,323 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:196)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.as.demos.ejb3.rar.PostmanPat$$$view17.deliver(Unknown Source)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) at java.lang.reflect.Method.invoke(Method.java:597)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:140)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) at $Proxy19.deliver(Unknown Source)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.as.demos.ejb3.rar.SimpleQueueResourceAdapter.process(SimpleQueueResourceAdapter.java:112)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.as.demos.ejb3.rar.SimpleQueueResourceAdapter.access$000(SimpleQueueResourceAdapter.java:51)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.as.demos.ejb3.rar.SimpleQueueResourceAdapter$1.run(SimpleQueueResourceAdapter.java:79)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:211)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) at java.lang.Thread.run(Thread.java:662)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) at org.jboss.threads.JBossThread.run(JBossThread.java:122)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-2559) Make HibernateAnnotationScanning more lenient in handling annotated entities
by Marius Bogoevici (Created) (JIRA)
Make HibernateAnnotationScanning more lenient in handling annotated entities
----------------------------------------------------------------------------
Key: AS7-2559
URL: https://issues.jboss.org/browse/AS7-2559
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.0.Alpha1
Reporter: Marius Bogoevici
Assignee: Marius Bogoevici
Fix For: 7.1.0.Beta1
Frameworks such as Spring Roo may place @Entity annotations via bytecode manipulation (since compilation is impossible) on methods, as in:
{code}
@Aspect
@ajcPrivileged
public class Owner_Roo_Entity
{
....
@Entity
@ajcDeclareAnnotation(pattern="com.springsource.petclinic.domain.Owner", annotation="@Entity", kind="at_type")
void ajc$declare_at_type_1()
{
}
....
}
{code}
This causes HibernateAnnotationScanner to crash with a CNFE on 'ajc$declare_at_type_1'.
Solution: make HibernateAnnotationScanner ignore these
--
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, 3 months
[JBoss JIRA] (AS7-2994) Wrong exception RollesAllowed constraint is not fulfilled
by Jan Lanik (Created) (JIRA)
Wrong exception RollesAllowed constraint is not fulfilled
---------------------------------------------------------
Key: AS7-2994
URL: https://issues.jboss.org/browse/AS7-2994
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.0.Beta1b
Environment: If you have a SB with a method annotated with RollesAllowed({a,b,c}) and a SFSB which injects this bean. We also have client tries to access a method which calls a restricted method on injected bean. This client does not possess a security role specified in RolesAllowed , so the call should be rejected with EJBAccessException. However, what I get is NoSuchEjbException.
Notes:
- this doesn't happen if there is only one security role in RollesAllowed
- this doesn't happen if the bean is injected to SLSB
- the NoSuchElement exception is thrown by org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor:66 snipplet follows:
ROOT_LOGGER.debug("Looking for stateful component instance with session id: " + sessionId);
StatefulSessionComponentInstance instance = component.getCache().get(sessionId);
if (instance == null) {
//This exception will be transformed into the correct exception type by the exception transforming interceptor
throw new NoSuchEJBException("Could not find SFSB " + component.getComponentName() + " with " + sessionId);
}
- I'll provide a reproducer for this, it' ll be available in my git repo (https://github.com/jlanik/jboss-as), branch EJBSecurity
classes: InjectionAnnSFSBtoSFSBTestCase, InjectionAnnSLSBtoSFSBTestCase
you can also look at InjectionAnnSFSBtoSLSBTestCase InjectionAnnSLSBtoSLSBTestCase (which work ok)
I'll create a pull request with this and some other tests, so hopefully, It'll be accessible in the main jboss-as repo soon.
Reporter: Jan Lanik
Assignee: jaikiran pai
Fix For: 7.1.0.CR1
--
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, 3 months
[JBoss JIRA] (AS7-2830) AS incorrectly rewrites standalone.xml
by Michael Musgrove (Created) (JIRA)
AS incorrectly rewrites standalone.xml
--------------------------------------
Key: AS7-2830
URL: https://issues.jboss.org/browse/AS7-2830
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.0.Beta1
Reporter: Michael Musgrove
Assignee: Jason Greene
jboss-as-datasources_1_0.xsd contains an element for configuring security for recovering datasources. I added this to standalone.xml:
<recovery>
<recover-credential>
<user-name>sa</user-name>
<password>sa</password>
</recovery-credential>
</recovery>
but the AS rewrites this section as follows:
<recovery>
<recover-credential>
<recover-credential>
sa
</recover-credential>
<recover-credential>
sa
</recover-credential>
</recover-credential>
</recovery>
--
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, 3 months
[JBoss JIRA] (JBRULES-2936) Importing decision table from Excel: Non Ascii chars should not be corrupted
by Jesper S. Møller (Issue Comment Edited) (JIRA)
[ https://issues.jboss.org/browse/JBRULES-2936?page=com.atlassian.jira.plug... ]
Jesper S. Møller edited comment on JBRULES-2936 at 1/2/12 9:44 PM:
-------------------------------------------------------------------
I was bitten by this too, but a bit of digging solved the mystery:
JXL gets this wrong, at least for BIFF8 files (binary Excel 97 files). They are not environment-dependent at all.
Excel stores all strings in the Shared String Table (SST) record, and always as Unicode. For strings where all the high-order-bytes are 0x00, Excel uses a compressed format, where they leave all the high-order bytes out. JXL wrongly tries to tackle those as though they were MBCS using the file.encoding (or jxl.encoding, if set). This is very wrong. (POI gets it right. BTW)
Hardcoding "jxl.encoding" to ISO-8859-1 fixes JXL for you - for BIFF8 and up. This is because Unicode code points U+0000 - U+00FF is exactly ISO-8859-1.
For versions prior to Excel 97 (BIFF8), string values were stored in LABEL records, according to the CODEPAGE record (which is in fact stored in the file). I don't see neither POI or JXL doing this quite right when reading an Excel 95 file, but it would require a "codepage number -> Java encoding" table, which is hard work.
Additionally, the JXL version I tried had a different bug in reading Excel95 files (containing WRITEACCESS records), so that's likely not a very popular file format.
Yeah, yeah, one day I'll do "The OSS Right Thing" and produce a proper patch for JXL and perhaps POI.
For now, set the system properties (System.setProperty("jxl.encoding", "ISO-8859-1");) and enjoy your decision tables!
Note how this problem is unlikely to hit you if you
A) Primarily use English text
B) Use an 8-bit "file.encoding" which has all the characters you need in the same place as ISO-8859-1 (i.e. Windows for most Europeans)
Diversity matters! (I say from Denmark running Mac OS X)
was (Author: jespersm):
I was bitten by this too, but a bit of digging solved the mystery:
JXL gets this wrong, at least for BIFF8 files (binary Excel 97 files). They store all strings in the Shared String Table (SST), and always as Unicode. For strings where all the high-order-bytes are 0x00, they use a compressed format, where they leave all the high-order bytes out. JXL wrongly tries to tackle those as though they were MBCS using the system.encoding (or jxl.encoding). This is very wrong. POI gets it right. Hardcoding jxl.encoding to ISO-8859-1 (a.k.a. Windows-1252) fixes JXL for you - for BIFF8 and up. This is because code points U+00 - U+FF is exactly ISO-8859-1.
For versions prior to Excel 97 (BIFF8), string values were stored in LABEL followed the codepage record which is stored in the file. I don't see neither POI or JXL doing this right when reading an Excel 95 file, but it requires a "codepage number -> Java encoding" table to get right, which is hard work.
But the JXL version I tried had a different bug in reading Excel95 files (containing WRITEACCESS records, which I guess are common), so that's likely not a problem at all.
Yeah, yeah, one day I'll do "The OSS Right Thing" and produce a proper patch for JXL and POI.
For now, set the system properties (System.setProperty("jxl.encoding", "ISO-8859-1");) and enjoy your decision tables!
Note how this problem is unlikely to hit you if you
A) Primarily use English text
B) Use an 8-bit "file.encoding" which has all the characters you need in the same place as ISO-8859-1 (i.e. Windows for most Europeans)
Diversity matters! (I say from Denmark running Mac OS X)
> Importing decision table from Excel: Non Ascii chars should not be corrupted
> ----------------------------------------------------------------------------
>
> Key: JBRULES-2936
> URL: https://issues.jboss.org/browse/JBRULES-2936
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Fix For: 5.4.0.Beta2
>
>
> see
> http://stackoverflow.com/questions/5298748/guvnor-rules-encoding
> Excel (like windows) probably has crappy encoding standardization (as in none at all), so I suspect that we 'll need to ask the excel document what encoding (or even what locale) it is and read the data in that encoding.
--
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, 3 months
[JBoss JIRA] (JBRULES-2936) Importing decision table from Excel: Non Ascii chars should not be corrupted
by Jesper S. Møller (Commented) (JIRA)
[ https://issues.jboss.org/browse/JBRULES-2936?page=com.atlassian.jira.plug... ]
Jesper S. Møller commented on JBRULES-2936:
-------------------------------------------
I was bitten by this too, but a bit of digging solved the mystery:
JXL gets this wrong, at least for BIFF8 files (binary Excel 97 files). They store all strings in the Shared String Table (SST), and always as Unicode. For strings where all the high-order-bytes are 0x00, they use a compressed format, where they leave all the high-order bytes out. JXL wrongly tries to tackle those as though they were MBCS using the system.encoding (or jxl.encoding). This is very wrong. POI gets it right. Hardcoding jxl.encoding to ISO-8859-1 (a.k.a. Windows-1252) fixes JXL for you - for BIFF8 and up. This is because code points U+00 - U+FF is exactly ISO-8859-1.
For versions prior to Excel 97 (BIFF8), string values were stored in LABEL followed the codepage record which is stored in the file. I don't see neither POI or JXL doing this right when reading an Excel 95 file, but it requires a "codepage number -> Java encoding" table to get right, which is hard work.
But the JXL version I tried had a different bug in reading Excel95 files (containing WRITEACCESS records, which I guess are common), so that's likely not a problem at all.
Yeah, yeah, one day I'll do "The OSS Right Thing" and produce a proper patch for JXL and POI.
For now, set the system properties (System.setProperty("jxl.encoding", "ISO-8859-1");) and enjoy your decision tables!
Note how this problem is unlikely to hit you if you
A) Primarily use English text
B) Use an 8-bit "file.encoding" which has all the characters you need in the same place as ISO-8859-1 (i.e. Windows for most Europeans)
Diversity matters! (I say from Denmark running Mac OS X)
> Importing decision table from Excel: Non Ascii chars should not be corrupted
> ----------------------------------------------------------------------------
>
> Key: JBRULES-2936
> URL: https://issues.jboss.org/browse/JBRULES-2936
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Fix For: 5.4.0.Beta2
>
>
> see
> http://stackoverflow.com/questions/5298748/guvnor-rules-encoding
> Excel (like windows) probably has crappy encoding standardization (as in none at all), so I suspect that we 'll need to ask the excel document what encoding (or even what locale) it is and read the data in that encoding.
--
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, 3 months
[JBoss JIRA] (AS7-3062) Unable to access a jar file in the bootclass path
by Dave Chestnutt (Created) (JIRA)
Unable to access a jar file in the bootclass path
-------------------------------------------------
Key: AS7-3062
URL: https://issues.jboss.org/browse/AS7-3062
Project: Application Server 7
Issue Type: Task
Components: Class Loading
Affects Versions: 7.0.2.Final
Environment: Windows XP, probably RedHat, too
Reporter: Dave Chestnutt
Assignee: David Lloyd
We are injecting code (like a profiler) using the JVMTI interface. Normally, we use the JVM options -Xbootclasspath and -agentpath to get our code running, like so:
set JAVA_OPTS=-Xmx1024m -Xms1024m -Xbootclasspath/a:C:\\Panorama\\hedzup\\mn\\lib\\awcore\\JIDAcore.jar -agentpath:C:\\Panorama\\hedzup\\mn\\bin\\AwProfile.dll=verbose -Dpanorama.jida.instance=jboss-1
With JBoss 7, we get a NoClassDefFoundError:
Exception in thread "main" java.lang.NoClassDefFoundError: com/altaworks/da/jida/AwMisc
at org.jboss.as.server.Main.main(Main.java)
. . .
This is the exact same kind of error that we used to get with OSGI before we modified our code to account for it - in that case we had to inject our package name into the list of packages that OSGI would search the bootclass path for. As we discussed on the phone today (Rich S), this is likely a similar class loader issue that we're running into with the new JBoss Modules. I can tell that we are successfully using JVMTI to inject our code. The problem is that the injected code, as it runs, tries to access classes in our package (com.altaworks.*) which are in our JIDAcore.jar file -- but due to the new class loading scheme, it's unable to find those classes.
How I reproduce this problem:
1. [download and unzip jboss-as-7.0.2.Final.zip]
2. SET JAVA_OPTS=... (as above)
3. standalone.bat
============[ Full Error from startup ] ================
16:53:41.91> standalone.bat
Calling C:\Documents and Settings\dchestnutt\My Documents\Downloads\jboss-as-7.0
.2.Final\jboss-as-7.0.2.Final\bin\standalone.conf.bat
===============================================================================
JBoss Bootstrap Environment
JBOSS_HOME: C:\Documents and Settings\dchestnutt\My Documents\Downloads\jboss-
as-7.0.2.Final\jboss-as-7.0.2.Final
JAVA: C:\Progra~1\Java\jdk1.6.0_25\bin\java
JAVA_OPTS: -Dprogram.name=standalone.bat -Xmx1024m -Xms1024m -Xbootclasspath/a
:C:\\Panorama\\hedzup\\mn\\lib\\awcore\\JIDAcore.jar -agentpath:C:\\Panorama\\he
dzup\\mn\\bin\\AwProfile.dll=verbose -Dpanorama.jida.instance=jboss-1 -server
===============================================================================
**set CODE_SIZE_LIMIT = 8
OPNET JIDA jvmti monitoring initialized
***** Panorama JIDA configuration enhanced for your monitoring pleasure *****
- C:\Panorama\hedzup\mn/lib/awapp/JIDAapp.jar added to system classpath
Minimum active percentage for metrics set to 1.0
Minimum duration percentage for metrics set to 2.0
AwLogFile: Logger is using properties file C:/Panorama/hedzup/mn/data/DA-JIDA_jb
oss-1_logger.properties
logging verbosity changed to 0
16:53:51,761 INFO [org.jboss.modules] JBoss Modules version 1.0.2.GA
Exception in thread "main" java.lang.NoClassDefFoundError: com/altaworks/da/jida
/AwMisc
at org.jboss.as.server.Main.main(Main.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.modules.Module.run(Module.java:272)
at org.jboss.modules.Main.__AW_main(Main.java:313)
at org.jboss.modules.Main.main(Main.java)
Caused by: java.lang.ClassNotFoundException: com.altaworks.da.jida.AwMisc from [
Module "org.jboss.as.server:main" from local module loader @3c0007 (roots: C:\Do
cuments and Settings\dchestnutt\My Documents\Downloads\jboss-as-7.0.2.Final\jbos
s-as-7.0.2.Final\modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:
191)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(Concu
rrentClassLoader.java:361)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(Concu
rrentClassLoader.java:333)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentCl
assLoader.java:310)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoad
er.java:103)
... 8 more
--
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, 3 months