[JBoss JIRA] (WFLY-11549) Wildfly-14 : ClassCastException while marshalling/unmarshalling
by Bhavesh Kharwa (Jira)
[ https://issues.jboss.org/browse/WFLY-11549?page=com.atlassian.jira.plugin... ]
Bhavesh Kharwa commented on WFLY-11549:
---------------------------------------
its happen while redeploying
> Wildfly-14 : ClassCastException while marshalling/unmarshalling
> ---------------------------------------------------------------
>
> Key: WFLY-11549
> URL: https://issues.jboss.org/browse/WFLY-11549
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 14.0.0.Final
> Reporter: Bhavesh Kharwa
> Assignee: Jason Greene
> Priority: Critical
> Attachments: hprofsnapshot.jpg
>
>
> I have configured wildfly-14 in domain mode and configured one profile "*full-ha-socket*" in domain.xml. Now I have deployed ear in wildfly.The application having functionality of marshalling/unmarshalling of content. Also I have provided jaxb dependency in maven as scope provided.
> So the issue is when I process the file the it throws classcastexception. Please refer below stackstrace.
> *Note: Sometimes it is working but sometimes giving exception*
> {code}
> Unhandled exception while procesing file 'testing.xml': java.lang.ClassCastException: com.commons.impl.NewsMessageImpl cannot be cast to com.commons.NewsMessage
> at com.common.transform.MessageTransformationService.transform(MessageTransformationService.java:521)
> at org.springframework.transaction.aspectj.AbstractTransactionAspect.ajc$around$org_springframework_transaction_aspectj_AbstractTransactionAspect$1$2a73e96cproceed(AbstractTransactionAspect.aj:59)
> at org.springframework.transaction.aspectj.AbstractTransactionAspect$AbstractTransactionAspect$1.proceedWithInvocation(AbstractTransactionAspect.aj:65)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:260)
> at org.springframework.transaction.aspectj.AbstractTransactionAspect.ajc$around$org_springframework_transaction_aspectj_AbstractTransactionAspect$1$2a73e96c(AbstractTransactionAspect.aj:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.springframework.expression.spel.support.ReflectiveMethodExecutor.execute(ReflectiveMethodExecutor.java:69)
> at org.springframework.expression.spel.ast.MethodReference.getValueInternal(MethodReference.java:122)
> at org.springframework.expression.spel.ast.MethodReference.access$000(MethodReference.java:44)
> at org.springframework.expression.spel.ast.MethodReference$MethodValueRef.getValue(MethodReference.java:258)
> at org.springframework.expression.spel.ast.CompoundExpression.getValueInternal(CompoundExpression.java:82)
> at org.springframework.expression.spel.ast.SpelNodeImpl.getTypedValue(SpelNodeImpl.java:102)
> at org.springframework.expression.spel.standard.SpelExpression.getValue(SpelExpression.java:103)
> at org.springframework.integration.util.AbstractExpressionEvaluator.evaluateExpression(AbstractExpressionEvaluator.java:126)
> at org.springframework.integration.util.MessagingMethodInvokerHelper.processInternal(MessagingMethodInvokerHelper.java:227)
> at org.springframework.integration.util.MessagingMethodInvokerHelper.process(MessagingMethodInvokerHelper.java:127)
> at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:73)
> at org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:67)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:134)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
> at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:128)
> at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
> at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
> at org.springframework.integration.router.AbstractMessageRouter.handleMessageInternal(AbstractMessageRouter.java:134)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
> at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:128)
> at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
> at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
> at org.springframework.integration.router.AbstractMessageRouter.handleMessageInternal(AbstractMessageRouter.java:134)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
> at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:128)
> at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
> at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
> at org.springframework.integration.router.AbstractMessageRouter.handleMessageInternal(AbstractMessageRouter.java:134)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
> at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:128)
> at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
> at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.sendMessage(AbstractReplyProducingMessageHandler.java:216)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.sendReplyMessage(AbstractReplyProducingMessageHandler.java:200)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.produceReply(AbstractReplyProducingMessageHandler.java:165)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleResult(AbstractReplyProducingMessageHandler.java:159)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:141)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.access$000(UnicastingDispatcher.java:52)
> at org.springframework.integration.dispatcher.UnicastingDispatcher$1.run(UnicastingDispatcher.java:97)
> at org.springframework.integration.util.ErrorHandlingTaskExecutor$1.run(ErrorHandlingTaskExecutor.java:52)
> at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:78)
> {code}
> Also i have added following dependencies in jboss-deployment-structure.xml
> - javax.mail.api
> - org.hibernate (slot=main)
> - javax.validation.api
> - com.sun.xml.bind (slot=main)
> - org.wildfly.clustering.singleton(slot=main)
> No duplicate classes/jars in application ear/lib...
> One thing I have noticed that if I undeploy & deploy the application then this issue start reproducing.
> One question: When I undeploy application, How can i verify application undeployed successfully (Removed all the application classes/lib from class loader while undeploy application)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-2722) [Guided Decision Tree] Unable to drag model to Decision tree when the model is huge
by How Fong Hew (Jira)
[ https://issues.jboss.org/browse/DROOLS-2722?page=com.atlassian.jira.plugi... ]
How Fong Hew updated DROOLS-2722:
---------------------------------
Issue Type: Bug (was: Feature Request)
> [Guided Decision Tree] Unable to drag model to Decision tree when the model is huge
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-2722
> URL: https://issues.jboss.org/browse/DROOLS-2722
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Tree Editor
> Affects Versions: 7.8.0.Final
> Reporter: How Fong Hew
> Assignee: Michael Anstis
> Priority: Major
> Attachments: unable to drag model to decision tree.gif
>
>
> *Problem:*
> When the list of properties/attributes in a particular model are huge (more than 20), not able to drag the last property of the model to the decision tree after scrolling down to the page where the property reside.
> *Steps to Reproduce:*
> * Refer to the attached file “unable to drag model to decision tree.gif”
> * Expand all the model in the Guided Decision Trees
> * Unable to drag and add the bottom property to the decision
> *Expected Result:*
> Just suggestion, screen should scroll to the top where the decision tree resides when drag toward to the decision tree, or the split the model and decision tree to two different section with different scroll bar.
> *Justification:*
> Having more than 20 properties/attributes under a model such as applicant / customer is common in the banking section for rule check. Even the decision tree is not officially released, everything works fantastic except this critical feature which prevent us from using it.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11616) CDIBuiltinInjectionTestCase fails with a security manager installed
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-11616:
---------------------------------------
Summary: CDIBuiltinInjectionTestCase fails with a security manager installed
Key: WFLY-11616
URL: https://issues.jboss.org/browse/WFLY-11616
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Reporter: Brian Stansberry
Assignee: Matej Novotny
New test case in https://github.com/wildfly/wildfly/pull/11996/files fails when a security manager is present. This is a pre-existing problem not introduced by the PR. The PR is just the first test coverage we have of using @Inject Principal.
I'll configure the test to be ignored if an s-m is present; this JIRA is to track a proper resolution.
Details:
{code}
Caused by: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:84)
at org.jboss.as.security.service.SimpleSecurityManager.getCallerPrincipal(SimpleSecurityManager.java:136)
at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:84)
at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:41)
at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:30)
at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:38)
at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
at org.jboss.weld.security.Principal$$Proxy$_$$_Weld$Proxy$.getName(Unknown Source)
at org.jboss.as.test.integration.weld.builtin.CDIResource.getMessage(CDIResource.java:40)
at org.jboss.as.test.integration.weld.builtin.CDIResource$Proxy$_$$_WeldClientProxy.getMessage(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
... 57 more
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
at org.jboss.security.identity.plugins.IdentityFactory.loadClass(IdentityFactory.java:91)
at org.jboss.security.identity.plugins.IdentityFactory.createPrincipal(IdentityFactory.java:49)
at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:80)
... 80 more
{code}
I don't know whether the spec has anything to say regarding any permissions that should be required in order to inject a Principal. If it says they shouldn't be required or is silent on the topic and we think they should not be necessary, then we are missing a privileged block. Otherwise I doubt what's being thrown here is what we'd want. If some permission is needed, checking for something more related to the use case (probably something new) would be better, and if that permission check passes then make the call in a privileged block.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11587) org.jboss.as.weld has optional dependency on org.jboss.as.security which causes regression
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11587?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11587:
-----------------------------------------
[~manovotn] [~dlofthouse] I added a simple test of injecting the Principal built-in bean to my PR for this at https://github.com/wildfly/wildfly/pull/11996. Unfortunately it's showing what looks like a pre-existing issue when the test is run with a security manager enabled:
{code}
Caused by: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:84)
at org.jboss.as.security.service.SimpleSecurityManager.getCallerPrincipal(SimpleSecurityManager.java:136)
at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:84)
at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:41)
at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:30)
at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:38)
at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
at org.jboss.weld.security.Principal$$Proxy$_$$_Weld$Proxy$.getName(Unknown Source)
at org.jboss.as.test.integration.weld.builtin.CDIResource.getMessage(CDIResource.java:40)
at org.jboss.as.test.integration.weld.builtin.CDIResource$Proxy$_$$_WeldClientProxy.getMessage(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
... 57 more
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
at org.jboss.security.identity.plugins.IdentityFactory.loadClass(IdentityFactory.java:91)
at org.jboss.security.identity.plugins.IdentityFactory.createPrincipal(IdentityFactory.java:49)
at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:80)
... 80 more
{code}
I don't know whether the spec has anything to say regarding any permissions that should be required in order to inject a Principal. If it says they shouldn't be required or is silent on the topic and we think they should not be necessary, then we are missing a privileged block. Otherwise I doubt what's being thrown here is what we'd want. If some permission is needed, checking for something more related to the use case (probably something new) would be better, and if that permission check passes then make the call in a privileged block.
> org.jboss.as.weld has optional dependency on org.jboss.as.security which causes regression
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11587
> URL: https://issues.jboss.org/browse/WFLY-11587
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Security
> Affects Versions: 15.0.1.Final
> Reporter: Matej Novotny
> Assignee: Matej Novotny
> Priority: Major
> Fix For: 16.0.0.Beta1
>
>
> This is originally reported on forums, see [this|https://developer.jboss.org/thread/279444] link.
> The post contains a nice reproducer (which should be turned into automated test) along with steps to reproduce.
> The original cause is WFLY-11125 where Weld's dependency on {{org.jboss.as.security}} changed from mandatory to optional. This causes failures when using {{@Inject Principal}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11609) ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11609?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11609:
-----------------------------------------
A more immediate task is to deprecate the "default-entity-bean-instance-pool" and "default-entity-bean-optimistic-locking" management attributes and to confirm that the runtime handling related to them done in EJB3SubsystemAdd.performBoottime is cruft and can be removed.
> ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-11609
> URL: https://issues.jboss.org/browse/WFLY-11609
> Project: WildFly
> Issue Type: Task
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Priority: Trivial
>
> There is the following configuration element
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <entity-bean>
> <optimistic-locking enabled="false"/>
> <bean-instance-pool pool-name="aPool"/>
> </entity-bean>
> for the ejb3 subsystem, this seems related to EJB2 EntityBeans which are removed from the container.
> This settings does not have any affect for the current JPA (EJB3) implementation and the EJB2 implementation is removed completely.
> It looks like that only the handler to read, write and manipulate the configuration are still there.
> So the element should be removed from the schema and code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months