[JBoss JIRA] (WFLY-972) EJB calendar timer Sunday calculation problem in certain locales
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-972?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas reassigned WFLY-972:
-----------------------------------
Assignee: Cheng Fang (was: Stuart Douglas)
> EJB calendar timer Sunday calculation problem in certain locales
> ----------------------------------------------------------------
>
> Key: WFLY-972
> URL: https://issues.jboss.org/browse/WFLY-972
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Environment: JDK 6 & 7
> Reporter: Cheng Fang
> Assignee: Cheng Fang
>
> My ejb class contains this timeout method:
> {code:java}
> @Schedule(dayOfWeek="Sun", persistent=false)
> private void sunday(Timer t) {
> }
> {code}
> When calling this timer.getNextTimeout(), it returned the Sunday after next Sunday (expecting next Sunday) when running on certain locales (it_IT, es_PE, etc). It works as expected on other locales like en_US.
> I added -Duser.language=it -Duser.country=IT to JAVA_OPTS when starting standalone server to use that locale.
> Seems to be a JDK bug. There could be some differences how dates are calculated in different locales, but shouldn't be that big like skip one Sunday. Today is Wed.
> One workaround is "to use locale.English when instantiating GregorianCalendar in the following classes." I tried it on 7.2 with it_IT, and got the expected Sunday.
> {noformat}
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/CalendarBasedTimeout.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/util/CalendarUtil.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/CalendarTimerTask.java
> {noformat}
--
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
11 years, 12 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas reassigned WFLY-959:
-----------------------------------
Assignee: David Lloyd (was: Stuart Douglas)
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-959
> URL: https://issues.jboss.org/browse/WFLY-959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Derek Horton
> Assignee: David Lloyd
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients. For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain. In both of those situations, it seems that the
> EJBs are limited to a single authentication point. The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules. I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this: the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain. Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.
--
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
11 years, 12 months
[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
11 years, 12 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
11 years, 12 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
11 years, 12 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
11 years, 12 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
11 years, 12 months