[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
13 years, 11 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
13 years, 11 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
13 years, 11 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
13 years, 11 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
13 years, 11 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
13 years, 11 months
[JBoss JIRA] (AS7-2168) TimerServicePersistenceSecondTestCase fails
by Brian Stansberry (Created) (JIRA)
TimerServicePersistenceSecondTestCase fails
-------------------------------------------
Key: AS7-2168
URL: https://issues.jboss.org/browse/AS7-2168
Project: Application Server 7
Issue Type: Bug
Components: EJB
Reporter: Brian Stansberry
Assignee: Carlo de Wolf
It has been @Ignored because it fails with:
20:54:59,422 ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (RMI TCP Connection(3)-127.0.0.1) Failed: org.jboss.as.test.integration.ejb.timerservice.persistence.TimerServicePersistenceSecondTestCase.testTimerServiceCalled: java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92) [arquillian-service:]
at org.junit.Assert.assertTrue(Assert.java:43) [arquillian-service:]
at org.junit.Assert.assertTrue(Assert.java:54) [arquillian-service:]
at org.jboss.as.test.integration.ejb.timerservice.persistence.TimerServicePersistenceSecondTestCase.testTimerServiceCalled(TimerServicePersistenceSecondTestCase.java:58) [classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) [arquillian-service:]
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [arquillian-service:]
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:246) [arquillian-service:]
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [arquillian-service:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) [arquillian-service:]
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) [arquillian-service:]
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) [arquillian-service:]
at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) [arquillian-service:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:82) [arquillian-service:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68) [arquillian-service:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54) [arquillian-service:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) [arquillian-service:]
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:239) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:202) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:216) [arquillian-service:]
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) [arquillian-service:]
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) [arquillian-service:]
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) [arquillian-service:]
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) [arquillian-service:]
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) [arquillian-service:]
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) [arquillian-service:]
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) [arquillian-service:]
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:161) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175) [arquillian-service:]
at org.junit.runners.ParentRunner.run(ParentRunner.java:300) [arquillian-service:]
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123) [arquillian-service:]
at org.junit.runner.JUnitCore.run(JUnitCore.java:157) [arquillian-service:]
at org.junit.runner.JUnitCore.run(JUnitCore.java:136) [arquillian-service:]
at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) [arquillian-service:]
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128) [arquillian-service:]
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107) [arquillian-service:]
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:226) [arquillian-service:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) [:1.6.0_26]
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) [:1.6.0_26]
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) [:1.6.0_26]
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) [:1.6.0_26]
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) [:1.6.0_26]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) [:1.6.0_26]
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) [:1.6.0_26]
at org.jboss.as.jmx.tcl.TcclMBeanServer.invoke(TcclMBeanServer.java:218)
at org.jboss.as.jmx.model.ModelControllerMBeanServer.invoke(ModelControllerMBeanServer.java:202)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) [:1.6.0_26]
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) [:1.6.0_26]
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) [:1.6.0_26]
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) [:1.6.0_26]
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) [:1.6.0_26]
at sun.rmi.transport.Transport$1.run(Transport.java:159) [:1.6.0_26]
at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
at sun.rmi.transport.Transport.serviceCall(Transport.java:155) [:1.6.0_26]
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) [:1.6.0_26]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) [:1.6.0_26]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) [:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
--
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
13 years, 11 months
[JBoss JIRA] (AS7-3157) Methods getHomeHandle() and getPrimaryKey() throw exception
by Ondřej Chaloupka (Created) (JIRA)
Methods getHomeHandle() and getPrimaryKey() throw exception
-----------------------------------------------------------
Key: AS7-3157
URL: https://issues.jboss.org/browse/AS7-3157
Project: Application Server 7
Issue Type: Bug
Components: EJB
Reporter: Ondřej Chaloupka
Assignee: John Bailey
The call of getHomeHandle() and getPrimaryKey() methods cause a throw of exceptions. I get following ones:
{code}
ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (management-handler-threads - 1) Failed: org.jboss.as.test.integration.ejb.ejb2.reference.annotation.ReferenceAnnotationDescriptorTestCase.testStateful21Interfaces: java.rmi.RemoteException: Cannot invoke getHomeHandle() on Proxy for remote EJB StatefulEJBLocator{appName='', moduleName='reference-ejb2-ejb3', distinctName='', beanName='StatefulSession30', view='interface org.jboss.as.test.integration.ejb.ej b2.reference.annotation.StatefulSession30Home', sessionId='{[89, -118, 54, 120, -112, 29, 76, -4, -113, -108, -109, -61, 57, -32, -47, 21]}'}
at org.jboss.ejb.client.EJBInvocationHandler$GetHomeHandleHandler.invoke(EJBInvocationHandler.java:304) [jboss-ejb-client-1.0.0.Beta11.jar:1.0.0.Beta11]
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:89) [jboss-ejb-client-1.0.0.Beta11.jar:1.0.0.Beta11]
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:83) [jboss-ejb-client-1.0.0.Beta11.jar:1.0.0.Beta11]
at $Proxy34.getHomeHandle(Unknown Source)
at org.jboss.as.test.integration.ejb.ejb2.reference.annotation.ReferenceAnnotationDescriptorTestCase.testStateful21Interfaces(ReferenceAnnotationDescriptorTestCase.java:311) [referenc e-ejb2-ejb3.jar:]
{code}
and
{code}
ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (management-handler-threads - 2) Failed: org.jboss.as.test.integration.ejb.ejb2.reference.annotation.ReferenceAnnotationDescriptorTestCase.testStateless21Interfaces: java.rmi.RemoteException: Cannot invoke getPrimaryKey() om Proxy for remote EJB StatelessEJBLocator{appName='', moduleName='reference-ejb2-ejb3', distinctName='', beanName='Session30', view='interface org.jboss.as.test.integration.ejb.ejb2.ref erence.global.Session30'}
at org.jboss.ejb.client.EJBInvocationHandler$GetPrimaryKeyHandler.invoke(EJBInvocationHandler.java:252) [jboss-ejb-client-1.0.0.Beta11.jar:1.0.0.Beta11]
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:89) [jboss-ejb-client-1.0.0.Beta11.jar:1.0.0.Beta11]
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:83) [jboss-ejb-client-1.0.0.Beta11.jar:1.0.0.Beta11]
at $Proxy33.getPrimaryKey(Unknown Source)
at org.jboss.as.test.integration.ejb.ejb2.reference.annotation.ReferenceAnnotationDescriptorTestCase.testStateless21Interfaces(ReferenceAnnotationDescriptorTestCase.java:368) [referen ce-ejb2-ejb3.jar:]
{code}
Method getHomeHandle() does not work for stateful bean. It works for stateless bean.
Method getPrimaryKey() does not work for stateless and stateful beans.
Test for check:
https://github.com/ochaloup/jboss-as/blob/JBQA-5483-test-migration-ejb2re...
--
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
13 years, 11 months
[JBoss JIRA] (AS7-1449) Incorrect statistcs returned by the EJB MBean
by Stuart Douglas (Closed) (JIRA)
[ https://issues.jboss.org/browse/AS7-1449?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas closed AS7-1449.
-------------------------------
Resolution: Rejected
This appears to be an EAP 5.1 issue. It does not appear to be relevant to AS7
> Incorrect statistcs returned by the EJB MBean
> ---------------------------------------------
>
> Key: AS7-1449
> URL: https://issues.jboss.org/browse/AS7-1449
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: No Release
> Reporter: Biljana Kramer
> Assignee: Carlo de Wolf
> Attachments: CallTimeStatistics_stop1.png, etat.ear.tar.gz
>
>
> Issue appears to be with the stats returned by the EJB MBean. The following twiddle command reveals the strange statistics:
> serverUrl='http://localhost:8080'
> jmxUser='admin'
> jmxPassword='admin'
> mBeanName='jboss.j2ee:jndiName=TestBean,service=EJB'
> mBeanAttr='DetypedInvocationStatistics'
> ./twiddle.sh -s "${serverUrl}" -u "${jmxUser}" -p "${jmxPassword}" get
> "${mBeanName}" "${mBeanAttr}"
> Essentially, you need to deploy the EAR attached to this jira to an EAP 5.1 instance and then push some load to it to see the strange return values.
--
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
13 years, 11 months