[JBoss JIRA] (WFLY-5875) Some domain tests fail with security manager
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5875?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-2471 to WFLY-5875:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5875 (was: JBEAP-2471)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Domain Management
Test Suite
(was: Domain Management)
(was: Test Suite)
Target Release: (was: 7.0.0.GA)
Affects Version/s: (was: 7.0.0.ER3)
> Some domain tests fail with security manager
> --------------------------------------------
>
> Key: WFLY-5875
> URL: https://issues.jboss.org/browse/WFLY-5875
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Ondrej Kotek
> Assignee: Brian Stansberry
>
> *org.jboss.as.test.integration.domain.mixed.eap640.MixedDomainDeployment640TestCase#testJsfWorks*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dts.noSmoke -Dtest=MixedDomainDeployment640TestCase#testJsfWorks -Djboss.test.mixed.domain.dir=/home/okotek/test/ -Dsecurity.manager}}
> fails with:
> {noformat}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (http-/10.16.95.147:8080-1) Error Rendering View[/home.xhtml]: javax.el.ELException: /home.xhtml: java.lang.RuntimeException: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")[0m
> [Server:server-one] [31m at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:88)[0m
> [Server:server-one] [31m at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)[0m
> [Server:server-one] [31m at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:207)[0m
> [Server:server-one] [31m at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822)[0m
> [Server:server-one] [31m at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447)[0m
> [Server:server-one] [31m at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125)[0m
> [Server:server-one] [31m at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286)[0m
> [Server:server-one] [31m at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)[0m
> [Server:server-one] [31m at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)[0m
> [Server:server-one] [31m at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)[0m
> [Server:server-one] [31m at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)[0m
> [Server:server-one] [31m at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[0m
> [Server:server-one] [31m at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[0m
> [Server:server-one] [31m at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[0m
> [Server:server-one] [31m at java.lang.reflect.Method.invoke(Method.java:497)[0m
> [Server:server-one] [31m at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:264)[0m
> [Server:server-one] [31m at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:262)[0m
> [Server:server-one] [31m at java.security.AccessController.doPrivileged(Native Method)[0m
> [Server:server-one] [31m at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)[0m
> [Server:server-one] [31m at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:296)[0m
> [Server:server-one] [31m at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:156)[0m
> [Server:server-one] [31m at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:288)[0m
> [Server:server-one] [31m at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:59)[0m
> [Server:server-one] [31m at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:197)[0m
> [Server:server-one] [31m at java.security.AccessController.doPrivileged(Native Method)[0m
> [Server:server-one] [31m at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)[0m
> [Server:server-one] [31m at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)[0m
> [Server:server-one] [31m at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)[0m
> [Server:server-one] [31m at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)[0m
> [Server:server-one] [31m at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)[0m
> [Server:server-one] [31m at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)[0m
> [Server:server-one] [31m at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)[0m
> [Server:server-one] [31m at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)[0m
> [Server:server-one] [31m at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)[0m
> [Server:server-one] [31m at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)[0m
> [Server:server-one] [31m at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)[0m
> [Server:server-one] [31m at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)[0m
> [Server:server-one] [31m at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)[0m
> [Server:server-one] [31m at java.lang.Thread.run(Thread.java:745)[0m
> [Server:server-one] [31mCaused by: java.lang.RuntimeException: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")[0m
> [Server:server-one] [31m at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:65)[0m
> [Server:server-one] [31m at org.jboss.weld.util.reflection.SecureReflections.ensureAccessible(SecureReflections.java:283)[0m
> [Server:server-one] [31m at org.jboss.weld.introspector.jlr.WeldConstructorImpl.newInstance(WeldConstructorImpl.java:206)[0m
> [Server:server-one] [31m at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:117)[0m
> [Server:server-one] [31m at org.jboss.weld.bean.ManagedBean.createInstance(ManagedBean.java:340)[0m
> [Server:server-one] [31m at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.java:204)[0m
> [Server:server-one] [31m at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:296)[0m
> [Server:server-one] [31m at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:103)[0m
> [Server:server-one] [31m at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90)[0m
> [Server:server-one] [31m at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)[0m
> [Server:server-one] [31m at org.jboss.as.test.integration.domain.mixed.jsf.Bean$Proxy$_$$_WeldClientProxy.getMessage(Bean$Proxy$_$$_WeldClientProxy.java)[0m
> [Server:server-one] [31m at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[0m
> [Server:server-one] [31m at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[0m
> [Server:server-one] [31m at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[0m
> [Server:server-one] [31m at java.lang.reflect.Method.invoke(Method.java:497)[0m
> [Server:server-one] [31m at javax.el.BeanELResolver.getValue(BeanELResolver.java:304)[0m
> [Server:server-one] [31m at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)[0m
> [Server:server-one] [31m at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)[0m
> [Server:server-one] [31m at org.apache.el.parser.AstValue.getValue(AstValue.java:166)[0m
> [Server:server-one] [31m at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189)[0m
> [Server:server-one] [31m at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)[0m
> [Server:server-one] [31m at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:227)[0m
> [Server:server-one] [31m at com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:150)[0m
> [Server:server-one] [31m at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)[0m
> [Server:server-one] [31m ... 38 more[0m
> [Server:server-one] [31mCaused by: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")[0m
> [Server:server-one] [31m at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)[0m
> [Server:server-one] [31m at java.security.AccessController.checkPermission(AccessController.java:884)[0m
> [Server:server-one] [31m at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)[0m
> [Server:server-one] [31m at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)[0m
> [Server:server-one] [31m at org.jboss.weld.util.reflection.SecureReflections$14.work(SecureReflections.java:288)[0m
> [Server:server-one] [31m at org.jboss.weld.util.reflection.SecureReflections$14.work(SecureReflections.java:283)[0m
> [Server:server-one] [31m at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)[0m
> [Server:server-one] [31m at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63)[0m
> {noformat}
> *org.jboss.as.test.integration.domain.suites.ReadEnvironmentVariablesTestCase#testReadEnvironmentVariablesForServers*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.domain -Dts.noSmoke -Dtest=org.jboss.as.test.integration.domain.suites.ReadEnvironmentVariablesTestCase#testReadEnvironmentVariablesForServers}}
> fails with:
> {noformat}
> ERROR [io.undertow.request] (default task-43) UT005023: Exception handling request to /env-test/env: java.security.Access
> ControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getenv.*")" in code source "(vfs:/content/env-test.war/WEB-INF/classes <no signer certificates>)" of "null")
> [Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> [Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> [Server:main-one] at java.lang.System.getenv(System.java:944) [rt.jar:1.8.0_60]
> [Server:main-one] at org.jboss.as.test.integration.domain.suites.EnvironmentTestServlet.doGet(EnvironmentTestServlet.java:44) [classes:]
> [Server:main-one] at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
> [Server:main-one] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_60]
> [Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177) [undertow-servlet-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) [undertow-core-1.3.7.Final-redhat-1.jar:1.3.7.Final-redhat-1]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> [Server:main-one] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5874) Some JPA compat tests fail with security manager
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5874?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-2468 to WFLY-5874:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5874 (was: JBEAP-2468)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: JPA / Hibernate
Test Suite
(was: JPA / Hibernate)
(was: Test Suite)
Target Release: (was: 7.0.0.GA)
Affects Version/s: (was: 7.0.0.ER3)
> Some JPA compat tests fail with security manager
> ------------------------------------------------
>
> Key: WFLY-5874
> URL: https://issues.jboss.org/browse/WFLY-5874
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Test Suite
> Reporter: Ondrej Kotek
> Assignee: Scott Marlow
>
> *EclipseLinkSharedModuleProviderTestCase#testSimpleCreateAndLoadEntities*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.compat -Dts.noSmoke -Dtest=org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase#testSimpleCreateAndLoadEntities}}
> fails with:
> {noformat}
> javax.ejb.EJBException: javax.persistence.PersistenceException: Exception [EclipseLink-28019] (Eclipse Persistence Services - 2.6.0.v20150309-bf26070): org.eclipse.persistence.exceptions.EntityManagerSetupException
> Exception Description: Deployment of PersistenceUnit [hibernate3_pc] failed. Close all factories for this PersistenceUnit.
> Internal Exception: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/toplink_module_test.ear/beans.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Class.checkMemberAccess(Class.java:2348)
> at java.lang.Class.getDeclaredMethods(Class.java:1974)
> at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getDeclaredMethods(PrivilegedAccessHelper.java:339)
> at org.eclipse.persistence.internal.jpa.metadata.listeners.EntityListenerMetadata.getDeclaredMethods(EntityListenerMetadata.java:249)
> at org.eclipse.persistence.internal.jpa.metadata.listeners.EntityClassListenerMetadata.process(EntityClassListenerMetadata.java:89)
> at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.processListeners(EntityAccessor.java:1226)
> at org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor.addEntityListeners(MetadataProcessor.java:140)
> at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:634)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:205)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:305)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:337)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:303)
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.createEntityManager(TransactionScopedEntityManager.java:186)
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.getOrCreateTransactionScopedEntityManager(TransactionScopedEntityManager.java:157)
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:87)
> at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:580)
> at org.jboss.as.test.compat.jpa.eclipselink.SFSB1.createEmployee(SFSB1.java:44)
> {noformat}
> *HibernateJarsInDeploymentTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.compat -Dts.noSmoke -Dtest=org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase}}
> fails with:
> {noformat}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 58) MSC000001: Failed to start service jboss.persistenceunit."HibernateJarsInDeploymentTestCase.ear/beans.jar#hibernate_pc".__FIRST_PHASE__: org.jboss.msc.service.StartException in service jboss.persistenceunit."HibernateJarsInDeploymentTestCase.ear/beans.jar#hibernate_pc".__FIRST_PHASE__: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createClassLoader")" in code source "(vfs:/content/HibernateJarsInDeploymentTestCase.ear/lib/hibernate-core.jar <no signer certificates>)" of "null")
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:120)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:102)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1.run(PhaseOnePersistenceUnitServiceImpl.java:129)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createClassLoader")" in code source "(vfs:/content/HibernateJarsInDeploymentTestCase.ear/lib/hibernate-core.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
> at org.wildfly.security.manager.WildFlySecurityManager.checkCreateClassLoader(WildFlySecurityManager.java:335)
> at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274)
> at java.lang.ClassLoader.<init>(ClassLoader.java:316)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.<init>(ClassLoaderServiceImpl.java:164)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.<init>(ClassLoaderServiceImpl.java:160)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.<init>(ClassLoaderServiceImpl.java:94)
> at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:206)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:288)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:161)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:144)
> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:28)
> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:40)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:39)
> at org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:159)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:242)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:59)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:117)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5873) Can't set static-connectors on AMQ bridge, if discovery-group were set before
by Tomas Hofman (JIRA)
Tomas Hofman created WFLY-5873:
----------------------------------
Summary: Can't set static-connectors on AMQ bridge, if discovery-group were set before
Key: WFLY-5873
URL: https://issues.jboss.org/browse/WFLY-5873
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 10.0.0.CR4
Reporter: Tomas Hofman
Assignee: Tomas Hofman
When AMQ bridge is created with static-connectors field set, and then static-connectors are undefined and discovery-group is set (in a single batch), following error is thrown:
"WFLYMSGAMQ0069: Attribute (static-connectors) can not been undefined as the resource does not define any alternative to this attribute."
Problem seems to be missing {{STATIC_CONNECTORS.setAlternatives(CommonAttributes.DISCOVERY_GROUP)}} in resource definition, which is causing {{!attr.hasAlternative(resource.getModel())}} check to fail in following code:
{code:title=AlternativeAttributeCheckHandler.java}
private void checkAlternativeAttribute(OperationContext context, String attributeName, boolean alternativeMustBeSet) throws OperationFailedException {
if (attributeDefinitions.containsKey(attributeName)) {
AttributeDefinition attr = attributeDefinitions.get(attributeName);
final Resource resource = context.readResource(EMPTY_ADDRESS);
if (alternativeMustBeSet) {
if (!attr.hasAlternative(resource.getModel())) {
throw new OperationFailedException(MessagingLogger.ROOT_LOGGER.undefineAttributeWithoutAlternative(attributeName));
}
} else {
if (attr.hasAlternative(resource.getModel())) {
throw new OperationFailedException(MessagingLogger.ROOT_LOGGER.altAttributeAlreadyDefined(attributeName));
}
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1998) Transport: reuse of incoming buffers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1998?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1998 at 12/18/15 5:51 AM:
----------------------------------------------------------
h3. UDP
* The same buffer (66000 bytes) is reused
* Message batches are de-serialized off of the UDP buffer and passed to a thread pool for further processing. *No copy*
* Single messages: the buffer is copied and passed to the thread pool where de-serialization happens
** If we made processing of single messsages similar to that of message batches, we could get rid of the buffer copy: do the de-serialization directly in the {{TP.receive()}} method and pass the message to the thread pool for further processing
*** Look at whether this hampers performance
*** Should nt be the case as we're already de-serializing message batches in the {{TP.receive()}} method
*** Most of the time (when receiving a lot of messages), messages will be received as message batches, not single messages anyway, so de-serialization of single messages shouldn't matter (perf-wise)
h3. TCP
* Every connection creates a new buffer for *every* incoming message, based on the length which is sent first
* I think we can safely switch to reusable buffers as both single message and message batches get de-serialized in {{TP.receive()}} and therefore implicitly already make a copy.
** Alternative 1: every {{TcpConnection}} has its own buffer. On reception of {{length}}, if the buffer is too small, we grow it. Downside: large buffers tend to hang around. Upside: idle connections are reaped, gc'ing the buffer. Also, buffer sizes are never more than {{TP.max_bundle_size}} (plus some constant overhead) anyway. The other downside is that we keep 1 buffer per connection, which means {{buffer-size * members}} overhead; not nice in a large cluster...
** Alterntive 2: use a *buffer pool*. Buffers are only used for a brief period of time: to de-serialize single messages or message batches. A fixed-size pool might be a more memory efficient solution, especially in large clusters. On reception of {{length}}, a connection grabs a right-sized buffer from the pool and returns it after de-serialization and passing of the de-serialized message to a thread pool. When the buffer is exhausted, a new temp buffer will be created.
h3. TCP_NIO2
* Every connection has a {{Buffers}} instance for reading. On reception of {{length}}, a new buffer for the message is created.
* Similar to TCP, we could hang on to that buffer and grow it if needed, or use a buffer pool (see above)
was (Author: belaban):
h3. UDP
* The same buffer (66000 bytes) is reused
* Message batches are de-serialized off of the UDP buffer and passed to a thread pool for further processing. *No copy*
* Single messages: the buffer is copied and passed to the thread pool where de-serialization happens
** If we made processing of single messsages similar to that of message batches, we could get rid of the buffer copy: do the de-serialization directly in the {{TP.receive()}} method and pass the message to the thread pool for further processing
*** Look at whether this hampers performance
*** Should nt be the case as we're already de-serializing message batches in the {{TP.receive()}} method
*** Most of the time (when receiving a lot of messages), messages will be received as message batches, not single messages anyway, so de-serialization of single messages shouldn't matter (perf-wise)
h3. TCP
* Every connection creates a new buffer for *every* incoming message, based on the length which is sent first
* I think we can safely switch to reusable buffers as both single message and message batches get de-serialized in {{TP.receive()}} and therefore implicitly already make a copy.
** Alternative 1: every {{TcpConnection}} has its own buffer. On reception of {{length}}, if the buffer is too small, we grow it. Downside: large buffers tend to hang around. Upside: idle connections are reaped, gc'ing the buffer. Also, buffer sizes are never more than {{TP.max_bundle_size}} (plus some constant overhead) anyway. The other downside is that we keep 1 buffer per connection, which means {{buffer-size * members}} overhead; not nice in a large cluster...
** Alterntive 2: use a *buffer pool*. Buffers are only used for a brief period of time: to de-serialize single messages or message batches. A fixed-size pool might be a more memory efficient solution, especially in large clusters. On reception of {{length}}, a connection grabs a right-sized buffer from the pool and returns it after de-serialization and passing of the de-serialized message to a thread pool. When the buffer is exhausted, a new temp buffer will be created.
h3. TCP_NIO2
> Transport: reuse of incoming buffers
> ------------------------------------
>
> Key: JGRP-1998
> URL: https://issues.jboss.org/browse/JGRP-1998
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> Investigate whether buffers can be reused on the receive side. JGRP-1989 already provides this on the send side. Goal: reduction of memory allocation rate.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1998) Transport: reuse of incoming buffers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1998?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1998 at 12/18/15 5:49 AM:
----------------------------------------------------------
h3. UDP
* The same buffer (66000 bytes) is reused
* Message batches are de-serialized off of the UDP buffer and passed to a thread pool for further processing. *No copy*
* Single messages: the buffer is copied and passed to the thread pool where de-serialization happens
** If we made processing of single messsages similar to that of message batches, we could get rid of the buffer copy: do the de-serialization directly in the {{TP.receive()}} method and pass the message to the thread pool for further processing
*** Look at whether this hampers performance
*** Should nt be the case as we're already de-serializing message batches in the {{TP.receive()}} method
*** Most of the time (when receiving a lot of messages), messages will be received as message batches, not single messages anyway, so de-serialization of single messages shouldn't matter (perf-wise)
h3. TCP
* Every connection creates a new buffer for *every* incoming message, based on the length which is sent first
* I think we can safely switch to reusable buffers as both single message and message batches get de-serialized in {{TP.receive()}} and therefore implicitly already make a copy.
** Alternative 1: every {{TcpConnection}} has its own buffer. On reception of {{length}}, if the buffer is too small, we grow it. Downside: large buffers tend to hang around. Upside: idle connections are reaped, gc'ing the buffer. Also, buffer sizes are never more than {{TP.max_bundle_size}} (plus some constant overhead) anyway. The other downside is that we keep 1 buffer per connection, which means {{buffer-size * members}} overhead; not nice in a large cluster...
** Alterntive 2: use a *buffer pool*. Buffers are only used for a brief period of time: to de-serialize single messages or message batches. A fixed-size pool might be a more memory efficient solution, especially in large clusters. On reception of {{length}}, a connection grabs a right-sized buffer from the pool and returns it after de-serialization and passing of the de-serialized message to a thread pool. When the buffer is exhausted, a new temp buffer will be created.
h3. TCP_NIO2
was (Author: belaban):
h3. UDP
* The same buffer (66000 bytes) is reused
* Message batches are de-serialized off of the UDP buffer and passed to a thread pool for further processing. *No copy*
* Single messages: the buffer is copied and passed to the thread pool where de-serialization happens
** If we made processing of single messsages similar to that of message batches, we could get rid of the buffer copy: do the de-serialization directly in the {{TP.receive()}} method and pass the message to the thread pool for further processing
*** Look at whether this hampers performance
*** Should nt be the case as we're already de-serializing message batches in the {{TP.receive()}} method
*** Most of the time (when receiving a lot of messages), messages will be received as message batches, not single messages anyway, so de-serialization of single messages shouldn't matter (perf-wise)
> Transport: reuse of incoming buffers
> ------------------------------------
>
> Key: JGRP-1998
> URL: https://issues.jboss.org/browse/JGRP-1998
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> Investigate whether buffers can be reused on the receive side. JGRP-1989 already provides this on the send side. Goal: reduction of memory allocation rate.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5872) Upgrade Artemis to 1.1.0.wildfly-010
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5872?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-2465 to WFLY-5872:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5872 (was: JBEAP-2465)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: JMS
(was: JMS)
(was: ActiveMQ)
Target Release: (was: 7.0.0.GA)
> Upgrade Artemis to 1.1.0.wildfly-010
> ------------------------------------
>
> Key: WFLY-5872
> URL: https://issues.jboss.org/browse/WFLY-5872
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> A major change in this version is
> The default global thread pool used by Artemis client is now fixed (it was unbounded before). Default size is 500.
> TO use an unbounded thread pool, you need to set ActiveMQClient.GLOBAL_THREAD_POOL_MAX_SIZE=-1 or use the sysprop activemq.artemis.client.global.thread.pool.max.size
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ]
Ladislav Thon commented on WFLY-5822:
-------------------------------------
[~rachmato] The steps for adding Byteman to a SmartFrog job are different for client and for servers. In any case, you have to put the Byteman JAR and your Byteman script somewhere where all the machines in the test can find it (in my case, I believe that both {{/home/lthon/...}} and {{/home/hudson/users-tmp/lthon/...}} would work). And then:
For server:
For 4-node cluster, the {{sfConfigTemplate}} contains something like
{code}
CLUSTER_JVM_ARGS [
["-Xmx5g -XX:+UseLargePages -Djava.net.preferIPv4Stack=true"],
["-Xmx5g -XX:+UseLargePages -Djava.net.preferIPv4Stack=true"],
["-Xmx5g -XX:+UseLargePages -Djava.net.preferIPv4Stack=true"],
["-Xmx5g -XX:+UseLargePages -Djava.net.preferIPv4Stack=true"]
];
{code}
You can override it in {{sfConfig}} in the Jenkins job under _Deployment configuration_ to contain system properties needed for Byteman. For example:
{code}
CLUSTER_JVM_ARGS [
["-Xmx5g -XX:+UseLargePages -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.transform.all -Dorg.jboss.byteman.compile.to.bytecode -javaagent:/home/lthon/byteman.jar=script:/home/lthon/script-server.btm,boot:/home/lthon/byteman.jar"],
["-Xmx5g -XX:+UseLargePages -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.transform.all -Dorg.jboss.byteman.compile.to.bytecode -javaagent:/home/lthon/byteman.jar=script:/home/lthon/script-server.btm,boot:/home/lthon/byteman.jar"],
["-Xmx5g -XX:+UseLargePages -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.transform.all -Dorg.jboss.byteman.compile.to.bytecode -javaagent:/home/lthon/byteman.jar=script:/home/lthon/script-server.btm,boot:/home/lthon/byteman.jar"],
["-Xmx5g -XX:+UseLargePages -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.transform.all -Dorg.jboss.byteman.compile.to.bytecode -javaagent:/home/lthon/byteman.jar=script:/home/lthon/script-server.btm,boot:/home/lthon/byteman.jar"]
];
{code}
For client:
The client runs in the SmartFrog process, so it's enough to pass the Byteman arguments to that. In the Jenkins job, you can do that by modifying a configuration variable {{SF_OPTS}} under _SmartFrog environment_.
For example, the {{eap-7x-failover-ejb-ejbremote-jvmkill-repl-async}} job contains this settings there:
{code}
-Xmx5g -XX:+UseLargePages -DXlog4j.configuration=clustering/client/log4j-ejbclient-trace.properties
{code}
To add Byteman, it would look like this:
{code}
-Xmx5g -XX:+UseLargePages -DXlog4j.configuration=clustering/client/log4j-ejbclient-trace.properties -Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.transform.all -Dorg.jboss.byteman.compile.to.bytecode -javaagent:/home/lthon/byteman.jar=script:/home/lthon/script-client.btm,boot:/home/lthon/byteman.jar"
{code}
Here's a job I created to demonstrate both client and server: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/lthon___byteman___ea... Look for a string of "!!!!!" in all the workers logs (perf17 to perf21).
I used Byteman 3.0.3 (i.e., the latest). The scripts I used were:
{code:title=script-client.btm|borderStyle=solid}
RULE test
CLASS org.jboss.ejb.client.EJBClient
METHOD createSession
AT ENTRY
IF TRUE
DO traceln("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")
ENDRULE
{code}
{code:title=script-server.btm|borderStyle=solid}
RULE test
CLASS org.jgroups.protocols.UDP
METHOD createSockets
AT ENTRY
IF TRUE
DO traceln("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")
ENDRULE
{code}
If you understand Byteman, you know that you can remove a lot of options that I used (and how to put additional options if you need them). Also, if your Byteman script for the client contains a syntax error, you won't get an error message and you will kill the Jenkins slave process (learned the hard way!), so beware :-)
> Clustering performance regression in ejbremote-dist-sync scenario
> ------------------------------------------------------------------
>
> Key: WFLY-5822
> URL: https://issues.jboss.org/browse/WFLY-5822
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Priority: Critical
>
> Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why?
> Compare these results:
> stress-ejbremote-dist-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
> ---------------------------------------
> Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand:
> stress-ejbremote-repl-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1998) Transport: reuse of incoming buffers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1998?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1998:
--------------------------------
h3. UDP
* The same buffer (66000 bytes) is reused
* Message batches are de-serialized off of the UDP buffer and passed to a thread pool for further processing. *No copy*
* Single messages: the buffer is copied and passed to the thread pool where de-serialization happens
** If we made processing of single messsages similar to that of message batches, we could get rid of the buffer copy: do the de-serialization directly in the {{TP.receive()}} method and pass the message to the thread pool for further processing
*** Look at whether this hampers performance
*** Should nt be the case as we're already de-serializing message batches in the {{TP.receive()}} method
*** Most of the time (when receiving a lot of messages), messages will be received as message batches, not single messages anyway, so de-serialization of single messages shouldn't matter (perf-wise)
> Transport: reuse of incoming buffers
> ------------------------------------
>
> Key: JGRP-1998
> URL: https://issues.jboss.org/browse/JGRP-1998
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> Investigate whether buffers can be reused on the receive side. JGRP-1989 already provides this on the send side. Goal: reduction of memory allocation rate.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JASSIST-256) Javassist - add annotation to class doesn't work on reflections
by Rui C. (JIRA)
[ https://issues.jboss.org/browse/JASSIST-256?page=com.atlassian.jira.plugi... ]
Rui C. commented on JASSIST-256:
--------------------------------
Hi,
I have resolve this problem. I fogot to specify the annotation type
{code:java}
CtClass entityclass = pool.getCtClass(Entity.class.getName());
Annotation entityAnno = new Annotation(constpool, entityclass);
{code}
But I found there's some wrong with ArrayMemberValue
if I don't initialization the value for Annotation array paramter. It will produce an null exception with ArrayMemberValue in line 133.
{code:java}
public void write(AnnotationsWriter writer) throws IOException {
int num = values.length;
writer.arrayValue(num);
for (int i = 0; i < num; ++i)
values[i].write(writer);
}
{code}
> Javassist - add annotation to class doesn't work on reflections
> ---------------------------------------------------------------
>
> Key: JASSIST-256
> URL: https://issues.jboss.org/browse/JASSIST-256
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: JDK1.7, IDEA
> Reporter: Rui C.
> Assignee: Shigeru Chiba
> Priority: Minor
>
> {code:java}
> ClassPool pool = ClassPool.getDefault();
> CtClass superclass = pool.getCtClass(AbstractEntity.class.getName());
> CtClass cc = pool.makeClass("com.rapid.develop.entity.Ponit", superclass);
> ClassFile ccFile = cc.getClassFile();
> ConstPool constpool = ccFile.getConstPool();
> AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
> Annotation entityAnno = new Annotation("Entity", constpool);
> Annotation tableAnno = new Annotation("Table", constpool);
> tableAnno.addMemberValue("name", new StringMemberValue("test", ccFile.getConstPool()));
> attr.addAnnotation(entityAnno);
> attr.addAnnotation(tableAnno);
> ccFile.addAttribute(attr);
> Class clazz = cc.toClass();
> Object o = clazz.newInstance();
> assertTrue(o.getClass().getName().equals("com.rapid.develop.entity.Ponit"));
> // annotations length = zero
> java.lang.annotation.Annotation[] annotations = clazz.getDeclaredAnnotations();
> assertEquals(2, annotations.length);
> {code}
> I used javassist to add annotation for class， I saw these annotations were added to class file.
> But I can't get them using java API clazz.getDeclaredAnnotations() and clazz.getAnnotations()
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JASSIST-256) Javassist - add annotation to class doesn't work on reflections
by Rui C. (JIRA)
[ https://issues.jboss.org/browse/JASSIST-256?page=com.atlassian.jira.plugi... ]
Rui C. updated JASSIST-256:
---------------------------
Description:
{code:java}
ClassPool pool = ClassPool.getDefault();
CtClass superclass = pool.getCtClass(AbstractEntity.class.getName());
CtClass cc = pool.makeClass("com.rapid.develop.entity.Ponit", superclass);
ClassFile ccFile = cc.getClassFile();
ConstPool constpool = ccFile.getConstPool();
AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
Annotation entityAnno = new Annotation("Entity", constpool);
Annotation tableAnno = new Annotation("Table", constpool);
tableAnno.addMemberValue("name", new StringMemberValue("test", ccFile.getConstPool()));
attr.addAnnotation(entityAnno);
attr.addAnnotation(tableAnno);
ccFile.addAttribute(attr);
Class clazz = cc.toClass();
Object o = clazz.newInstance();
assertTrue(o.getClass().getName().equals("com.rapid.develop.entity.Ponit"));
// annotations length = zero
java.lang.annotation.Annotation[] annotations = clazz.getDeclaredAnnotations();
assertEquals(2, annotations.length);
{code}
I used javassist to add annotation for class， I saw these annotations were added to class file.
But I can't get them using java API clazz.getDeclaredAnnotations() and clazz.getAnnotations()
was:
{code:java}
ClassPool pool = ClassPool.getDefault();
CtClass superclass = pool.getCtClass(AbstractEntity.class.getName());
CtClass cc = pool.makeClass("com.rapid.develop.entity.Ponit", superclass);
ClassFile ccFile = cc.getClassFile();
ConstPool constpool = ccFile.getConstPool();
AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
Annotation entityAnno = new Annotation("Entity", constpool);
Annotation tableAnno = new Annotation("Table", constpool);
tableAnno.addMemberValue("name", new StringMemberValue("test", ccFile.getConstPool()));
attr.addAnnotation(entityAnno);
attr.addAnnotation(tableAnno);
ccFile.addAttribute(attr);
Class clazz = cc.toClass();
Object o = clazz.newInstance();
assertTrue(o.getClass().getName().equals("com.rapid.develop.entity.Ponit"));
// annotations length = zero
java.lang.annotation.Annotation[] annotations = clazz.getDeclaredAnnotations();
assertEquals(2, annotations.length);
{code}
I used javassist to add annotation for class， I saw these annotations were added to class file.
But I can't get them using java API clazz.getDeclaredAnnotations() and clazz.getAnnotations()
> Javassist - add annotation to class doesn't work on reflections
> ---------------------------------------------------------------
>
> Key: JASSIST-256
> URL: https://issues.jboss.org/browse/JASSIST-256
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: JDK1.7, IDEA
> Reporter: Rui C.
> Assignee: Shigeru Chiba
> Priority: Minor
>
> {code:java}
> ClassPool pool = ClassPool.getDefault();
> CtClass superclass = pool.getCtClass(AbstractEntity.class.getName());
> CtClass cc = pool.makeClass("com.rapid.develop.entity.Ponit", superclass);
> ClassFile ccFile = cc.getClassFile();
> ConstPool constpool = ccFile.getConstPool();
> AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
> Annotation entityAnno = new Annotation("Entity", constpool);
> Annotation tableAnno = new Annotation("Table", constpool);
> tableAnno.addMemberValue("name", new StringMemberValue("test", ccFile.getConstPool()));
> attr.addAnnotation(entityAnno);
> attr.addAnnotation(tableAnno);
> ccFile.addAttribute(attr);
> Class clazz = cc.toClass();
> Object o = clazz.newInstance();
> assertTrue(o.getClass().getName().equals("com.rapid.develop.entity.Ponit"));
> // annotations length = zero
> java.lang.annotation.Annotation[] annotations = clazz.getDeclaredAnnotations();
> assertEquals(2, annotations.length);
> {code}
> I used javassist to add annotation for class， I saw these annotations were added to class file.
> But I can't get them using java API clazz.getDeclaredAnnotations() and clazz.getAnnotations()
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
