[JBoss JIRA] (WFLY-1183) Configure EJB3/MDB with an individual thread pool for each EJB.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1183?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1183.
----------------------------------
Resolution: Rejected
Rejecting as per David comments.
> Configure EJB3/MDB with an individual thread pool for each EJB.
> ---------------------------------------------------------------
>
> Key: WFLY-1183
> URL: https://issues.jboss.org/browse/WFLY-1183
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Jeremy Whiting
> Assignee: Stuart Douglas
>
> For performance of an application to be scalable I need to configure sometimes a thread pool to an EJB. The pool is not shared with other EJB in the deployed application.
> For example
> PoolA - EJB Dog
> PoolB - EJB Cat
> To configure this the ability no define the thread pool name for an EJB. Rather than an EJB to the shared thread pool as it currently works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2011) jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2011?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2011:
--------------------------------------
I have pushed a fix for this into the metadata repository, this will be resolved by the next metadata release.
> jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
> -------------------------------------------------------------------------------------
>
> Key: WFLY-2011
> URL: https://issues.jboss.org/browse/WFLY-2011
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: Stuart Douglas
> Labels: ejb-jar.xml
>
> If beans of an application are marked as clustered by using the jboss-ejb3.xml DD the behaviour is not consistent.
> From the XSD the <ejb-name> element can not be added multiple times.
> And the following configuration will be not valid:
> <assembly-descriptor>
> <c:clustering>
> <ejb-name>Bean1</ejb-name>
> <ejb-name>Bean2</ejb-name>
> <c:clustered>true</c:clustered>
> </c:clustering>
> </assembly-descriptor>
> The parser should throw an Exception and the application should not be deployed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-1766) The @Local annotation on a session bean "overrides" information about @Local interfaces implemented through keyword "implements"
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1766?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1766.
----------------------------------
Resolution: Rejected
I think the current behaviour is correct, even though the spec is not super clear in this case I am pretty sure the intention is that @Local on the bean class overrides @Local specified on an interface.
This gives developers more flexibility, as otherwise there is no way to exclude an annotated interface from being considered a business interface.
If the spec is ever clarified in such a way that it makes it clear that this is not the desired behaviour then we will revisit.
> The @Local annotation on a session bean "overrides" information about @Local interfaces implemented through keyword "implements"
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1766
> URL: https://issues.jboss.org/browse/WFLY-1766
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Alpha3
> Reporter: Matus Abaffy
> Assignee: Stuart Douglas
>
> I have the following interfaces
> {code}
> public interface Bar { }
> {code}
> {code}
> @Local
> public interface Foo { }
> {code}
> and a session bean
> {code}
> @Local(Bar.class)
> @Stateful
> public class SessionBean implements Foo { }
> {code}
> EJB 3.2 specification (4.9.7 Session Bean’s Business Interface) states:
> "any interface of the bean class is explicitly designated as a business interface of the bean by either of the following means:
> • using the Local or Remote annotation with a non-empty value on the bean class
> • using the Local or Remote annotation on the interface
> • in the deployment descriptor"
> Therefore, I assume SessionBean should expose both Bar and Foo as local business interfaces. However, only Bar is exposed:
> {noformat}
> ...
> INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-7) JNDI bindings for session bean named SessionBean in deployment unit deployment "pckg.war" are as follows:
> java:global/pckg/SessionBean!org.jboss. ... .Bar
> java:app/pckg/SessionBean!org.jboss. ... .Bar
> java:module/SessionBean!org.jboss. ... .Bar
> java:global/pckg/SessionBean
> java:app/pckg/SessionBean
> java:module/SessionBean
> {noformat}
> It seems that the @Local annotation on a session bean class "overrides" all information about @Local interfaces implemented using the keyword "implements". (It does not ignore @Remote interfaces implemented using the keyword "implements".)
> The @Remote annotation on a session bean class works analogically - it causes @Remote interfaces implemented using the keyword "implements" not to be contained in the set of remote business interfaces.
> I haven't tried yet what happens if I declare another interface(s) for certain session beans as local/remote in the deployment descriptor - whether those defined in the java classes become "overriden". But I'd like to know what SHOULD happen. If it is not clear from the EJB spec., the exact behaviour in such case should be stated specifically for Wildfly - I'd be grateful for any links to such information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-1445) Jawr servlet with name JavascriptServlet failed to initialize properly.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1445?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1445.
----------------------------------
Resolution: Out of Date
OSGi support has been removed from WF.
> Jawr servlet with name JavascriptServlet failed to initialize properly.
> ------------------------------------------------------------------------
>
> Key: WFLY-1445
> URL: https://issues.jboss.org/browse/WFLY-1445
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Igor Shulika
> Assignee: Stuart Douglas
>
> I'm deploying a OSGi WAB file on the latest WildFly 8.0.0.Alpha2-SNAPSHOT server. Can not initialize the JavascriptServlet from JAWR Bundle. Note: When I used the <extension module="org.jboss.as.web"/> insted of <extension module="org.wildfly.extension.undertow"/> it works.
> Please see error trace below.
> 16:39:44,476 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-3) Jawr servlet with name JavascriptServlet failed to initialize properly.
> 16:39:44,476 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-3) Cause:
> 16:39:44,476 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-3) null: java.lang.reflect.UndeclaredThrowableException
> at com.sun.proxy.$Proxy22.getResource(Unknown Source)
> at net.jawr.web.resource.handler.reader.ServletContextResourceReaderHandler.getResource(ServletContextResourceReaderHandler.java:192) [ServletContextResourceReaderHandler.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostprocessBundle(ResourceBundlesHandlerImpl.java:892) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostProcessBundle(ResourceBundlesHandlerImpl.java:835) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndStoreBundle(ResourceBundlesHandlerImpl.java:766) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.initAllBundles(ResourceBundlesHandlerImpl.java:542) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.CachedResourceBundlesHandler.initAllBundles(CachedResourceBundlesHandler.java:126) [CachedResourceBundlesHandler.class:]
> at net.jawr.web.resource.bundle.factory.BundlesHandlerFactory.buildResourceBundlesHandler(BundlesHandlerFactory.java:233) [BundlesHandlerFactory.class:]
> at net.jawr.web.resource.bundle.factory.PropertiesBasedBundlesHandlerFactory.buildResourceBundlesHandler(PropertiesBasedBundlesHandlerFactory.java:204) [PropertiesBasedBundlesHandlerFactory.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initializeJawrConfig(JawrRequestHandler.java:349) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initRequestHandler(JawrRequestHandler.java:262) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.<init>(JawrRequestHandler.java:184) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrServlet.init(JawrServlet.java:56) [JawrServlet.class:]
> at javax.servlet.GenericServlet.init(GenericServlet.java:244) [jboss-servlet-api_3.1_spec-1.0.0.Alpha1.jar:1.0.0.Alpha1]
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:145) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.ManagedServlet.start(ManagedServlet.java:62) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:599) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:77)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_21]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_21]
> at net.jawr.web.resource.bundle.generator.ResourceGeneratorReaderProxyFactory$ResourceGeneratorReaderWrapperInvocationHandler.invoke(ResourceGeneratorReaderProxyFactory.java:167) [ResourceGeneratorReaderProxyFactory$ResourceGeneratorReaderWrapperInvocationHandler.class:]
> ... 23 more
> Caused by: java.lang.IllegalArgumentException: The DWR bean named 'TransactionService' was not found in any DWR configuration instance.
> at net.jawr.web.resource.bundle.generator.dwr.DWRBeanGenerator.getInterfaceScript(DWRBeanGenerator.java:265) [DWRBeanGenerator.class:]
> at net.jawr.web.resource.bundle.generator.dwr.DWRBeanGenerator.createResource(DWRBeanGenerator.java:134) [DWRBeanGenerator.class:]
> at net.jawr.web.resource.bundle.generator.ResourceGeneratorReaderWrapper.getResource(ResourceGeneratorReaderWrapper.java:135) [ResourceGeneratorReaderWrapper.class:]
> ... 28 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-1314) Add a management operation to let remote EJB clients know that a particular server is no longer capable of handling a EJB request
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1314?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-1314:
------------------------------------
Assignee: David Lloyd (was: Stuart Douglas)
> Add a management operation to let remote EJB clients know that a particular server is no longer capable of handling a EJB request
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1314
> URL: https://issues.jboss.org/browse/WFLY-1314
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: jaikiran pai
> Assignee: David Lloyd
>
> While looking into another issue WFLY-1313 we realized that it might be a good idea to allow admins to have some kind of management operation where they could say that a particular server will no longer accept EJB invocations (for all deployments or maybe just a specific deployment). This would then allow the admins to issue such a operation and the remote EJB clients (via the EJB client library) would then realize that, they should no longer send out requests to that server node. This way the admins can then even undeploy the deployment or shutdown the server without having to worry about EJB invocations coming in and failing in-flight due to deployment being currently undeployed.
> From a EJB client library point of view, this essentially is a explicit "module unavailable" notification that the server will trigger to its connected clients.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-1716) NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1716?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1716.
----------------------------------
Resolution: Out of Date
> NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-1716
> URL: https://issues.jboss.org/browse/WFLY-1716
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.0.0.Alpha3
> Environment: Win 7, JEE 6, JDK 7
> Reporter: Oliver Pfau
> Assignee: Stuart Douglas
> Labels: Deploy, classnotfound, war
>
> I tried to deploy my ear which works in JBoss 7 in wildfly and got the following error on deploy:
> 09:59:55,060 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "mywar.war" of deployment "my.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
> at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> ... 5 more
> 09:59:55,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "my.ear")]) - failure description: {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"mywar.war\" of deployment \"my.ear\"
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.ValidatorFactory is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.InstanceName is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.Validator is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>
> <all other services>
> ]
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months