[JBoss JIRA] (WFLY-4269) InitialRedeliveryDelay ResourceAdapter Config is not respected when defined in more than one config.
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4269?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma commented on WFLY-4269:
-------------------------------------------
If we comment the MDB's following activation configuration properties then the <config-property> defined in resource-adapter section for maximumRedeliveries and initialRedeliveryDelay are respected properly.
{code}
// @ActivationConfigProperty(propertyName = "maximumRedeliveries", propertyValue = "4"),
// @ActivationConfigProperty(propertyName = "initialRedeliveryDelay", propertyValue = "7000"),
{code}
Example Output with above commented properties:
{code}
12:35:49,552 INFO [stdout] (default-threads - 15) => Tue Jan 20 12:35:49 IST 2015 TestMDB Received Message > Message - Hello One !!!Tue Jan 20 12:35:49 IST 2015
12:35:49,552 INFO [stdout] (default-threads - 15) before mdc.setRollbackOnly()
12:35:49,552 INFO [stdout] (default-threads - 15) after mdc.setRollbackOnly()
12:35:53,557 INFO [stdout] (default-threads - 16)
12:35:53,558 INFO [stdout] (default-threads - 16) => Tue Jan 20 12:35:53 IST 2015 TestMDB Received Message > Message - Hello One !!!Tue Jan 20 12:35:49 IST 2015
12:35:53,558 INFO [stdout] (default-threads - 16) before mdc.setRollbackOnly()
12:35:53,559 INFO [stdout] (default-threads - 16) after mdc.setRollbackOnly()
12:36:01,563 INFO [stdout] (default-threads - 17)
12:36:01,563 INFO [stdout] (default-threads - 17) => Tue Jan 20 12:36:01 IST 2015 TestMDB Received Message > Message - Hello One !!!Tue Jan 20 12:35:49 IST 2015
12:36:01,564 INFO [stdout] (default-threads - 17) before mdc.setRollbackOnly()
12:36:01,564 INFO [stdout] (default-threads - 17) after mdc.setRollbackOnly()
12:36:17,566 INFO [stdout] (default-threads - 18)
12:36:17,567 INFO [stdout] (default-threads - 18) => Tue Jan 20 12:36:17 IST 2015 TestMDB Received Message > Message - Hello One !!!Tue Jan 20 12:35:49 IST 2015
12:36:17,567 INFO [stdout] (default-threads - 18) before mdc.setRollbackOnly()
12:36:17,567 INFO [stdout] (default-threads - 18) after mdc.setRollbackOnly()
{code}
> InitialRedeliveryDelay ResourceAdapter Config is not respected when defined in more than one config.
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-4269
> URL: https://issues.jboss.org/browse/WFLY-4269
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 9.0.0.Alpha1
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Jesper Pedersen
>
> - If the MDB defines the "initialRedeliveryDelay" ActivationConfigProperty via annotation OR using "ejb-jar.xml" file, As well as if the "initialRedeliveryDelay" "config-property" is defined inside the <resource-adapter> section of standalone.xml then *both* are ignored, and it starts taking the default value of initialRedeliveryDelay for Activemq resource adapter as 1 Second see [1]
> [1] http://activemq.apache.org/redelivery-policy.html
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4205:
--------------------------------------
Where are you placing the WebApplicationInitializer instance? It would need to be in the war file (rather than the top level ear) for this to work. @HandlesTypes would be picked up if there is a META-INF/services entry for the SCI in the war, however type discovery is only performed for applications in the war.
> Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
> --------------------------------------------------------------------------------
>
> Key: WFLY-4205
> URL: https://issues.jboss.org/browse/WFLY-4205
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04
> Reporter: Nick .
> Assignee: Stuart Douglas
> Labels: EAR, servlet3.0, spring-mvc
>
> Hi,
> I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All my spring mvc related jar's are in my EAR/lib, i'm using SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as follows
> {code}
> @HandlesTypes(WebApplicationInitializer.class)
> public class SpringServletContainerInitializer implements ServletContainerInitializer {
> @Override
> public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
> throws ServletException {
> List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
> if (webAppInitializerClasses != null) {
> for (Class<?> waiClass : webAppInitializerClasses) {
> // Be defensive: Some servlet containers provide us with invalid classes,
> // no matter what @HandlesTypes says...
> if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) &&
> WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
> try {
> initializers.add((WebApplicationInitializer) waiClass.newInstance());
> }
> catch (Throwable ex) {
> throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex);
> }
> }
> }
> }
> if (initializers.isEmpty()) {
> servletContext.log("No Spring WebApplicationInitializer types detected on classpath");
> return;
> }
> AnnotationAwareOrderComparator.sort(initializers);
> servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers);
> for (WebApplicationInitializer initializer : initializers) {
> initializer.onStartup(servletContext);
> }
> }
> }
> {code}
> But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the EAR/lib
> Even i have tried adding the extracted the SPI from spring-web jar and added inside my war's WEB-INF/lib as a jar
> WEB-INF/lib/web-init-spi.jar which contains
> META-INF/services/javax.servlet.ServletContainerIntializer file with org.springframework.web.SpringServletContainerInitializer as an entry. This time its detecting SpringServletContainerInitializer but not detecting what defined in @HandlesTypes
> Its only working If i package all those spring mvc jars inside WEB-INF/lib then everything started working.
> I have no idea this is how the servlet specification works or its a wildfly issue but i see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR deployment structure.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3594) Wildfly showing the war file status as Failed after restart the server
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3594?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski edited comment on WFLY-3594 at 1/20/15 1:40 AM:
-------------------------------------------------------------------
Dialing back priority since this seems to have no impact on app availability.
was (Author: baranowb):
Dialing back priority since this seems to have no impact on app availability.
Also, please provide reproducer and step by step instruction how to trigger this. Otherwise this issue cant be subject of investigation.
> Wildfly showing the war file status as Failed after restart the server
> ----------------------------------------------------------------------
>
> Key: WFLY-3594
> URL: https://issues.jboss.org/browse/WFLY-3594
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Final
> Environment: windows server 2003 32 bit O.S,Java 7,flex, Apache axis web services
> Reporter: shaik masthan
> Assignee: Bartosz Baranowski
> Priority: Minor
> Labels: restarting
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> after successful deployment , war file status is deployed. When i restart the server , war files status is showing as failed. there were no errors in the logs and i am able to access the the application without any problems.
> After some time happen , again i restart the server this time war file status is deployed.
> intermittently i am viewing this weird behavior with war files w.r. t restarting the server.
> let me know any workaround or fix for this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin.... ]
Stuart Douglas edited comment on WFLY-4205 at 1/20/15 1:41 AM:
---------------------------------------------------------------
Where are you placing the WebApplicationInitializer instance? It would need to be in the war file (rather than the top level ear) for this to work. @HandlesTypes would be picked up if there is a META-INF/services entry for the SCI in the war, however type discovery is only performed for classes in the war.
was (Author: swd847):
Where are you placing the WebApplicationInitializer instance? It would need to be in the war file (rather than the top level ear) for this to work. @HandlesTypes would be picked up if there is a META-INF/services entry for the SCI in the war, however type discovery is only performed for applications in the war.
> Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
> --------------------------------------------------------------------------------
>
> Key: WFLY-4205
> URL: https://issues.jboss.org/browse/WFLY-4205
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04
> Reporter: Nick .
> Assignee: Stuart Douglas
> Labels: EAR, servlet3.0, spring-mvc
>
> Hi,
> I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All my spring mvc related jar's are in my EAR/lib, i'm using SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as follows
> {code}
> @HandlesTypes(WebApplicationInitializer.class)
> public class SpringServletContainerInitializer implements ServletContainerInitializer {
> @Override
> public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
> throws ServletException {
> List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
> if (webAppInitializerClasses != null) {
> for (Class<?> waiClass : webAppInitializerClasses) {
> // Be defensive: Some servlet containers provide us with invalid classes,
> // no matter what @HandlesTypes says...
> if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) &&
> WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
> try {
> initializers.add((WebApplicationInitializer) waiClass.newInstance());
> }
> catch (Throwable ex) {
> throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex);
> }
> }
> }
> }
> if (initializers.isEmpty()) {
> servletContext.log("No Spring WebApplicationInitializer types detected on classpath");
> return;
> }
> AnnotationAwareOrderComparator.sort(initializers);
> servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers);
> for (WebApplicationInitializer initializer : initializers) {
> initializer.onStartup(servletContext);
> }
> }
> }
> {code}
> But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the EAR/lib
> Even i have tried adding the extracted the SPI from spring-web jar and added inside my war's WEB-INF/lib as a jar
> WEB-INF/lib/web-init-spi.jar which contains
> META-INF/services/javax.servlet.ServletContainerIntializer file with org.springframework.web.SpringServletContainerInitializer as an entry. This time its detecting SpringServletContainerInitializer but not detecting what defined in @HandlesTypes
> Its only working If i package all those spring mvc jars inside WEB-INF/lib then everything started working.
> I have no idea this is how the servlet specification works or its a wildfly issue but i see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR deployment structure.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3384) Problem with ServiceBasedNamingStore and JNDIView.
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3384?page=com.atlassian.jira.plugin.... ]
Eduardo Martins edited comment on WFLY-3384 at 1/19/15 8:07 PM:
----------------------------------------------------------------
Adding PR that moves group cache entries from jboss/clustering/group to jboss/clustering/group-cache, to avoid invalid jndi tree. May not be final solution, [~pferraro] needs to review and approve it first.
was (Author: emmartins):
Moving group cache entries from jboss/clustering/group to jboss/clustering/group-cache, to avoid invalid jndi tree
> Problem with ServiceBasedNamingStore and JNDIView.
> --------------------------------------------------
>
> Key: WFLY-3384
> URL: https://issues.jboss.org/browse/WFLY-3384
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Environment: WildFly8.0.0, JDK8
> Reporter: Sławomir Wojtasiak
> Assignee: Eduardo Martins
>
> Some of the registered services are bound to the JNDI using the BinderService and the dependency mechanism to run the binder as soon as the main service runs. At this point everything works like a harm; services are registered and started successfully. But there is a little inconsistency, at least from the JNDI point of view which leads to a specific problem.
> Let's take a look at the following services:
> {quote}
> jboss.clustering.group.ejb.dist@a59ab61 State: UP (Uses: BinderService => JNDI: jboss.naming.context.java.jboss.clustering.group.ejb.dist)
> jboss.clustering.group.ejb@60e172ee State: DOWN (Uses: BinderService => JNDI: jboss.naming.context.java.jboss.clustering.group.ejb)
> {quote}
> As you can see they share the same path in the naming context (*jboss.naming.context.java.jboss.clustering.group.ejb*.dist). The second service _jboss.naming.context.java.jboss.clustering.group.ejb_ is a parent naming context to the first one: _jboss.naming.context.java.jboss.clustering.group.ejb.dist_. To make matters worse they do not depend on themselves, so when _jboss.clustering.group.ejb.dist_ is requested to be started (for instance by _jboss.clustering.providers.ejb.dist_ service) it starts immediately but _jboss.clustering.group.ejb_ is left in the WAITING state (It's ON_DEMAND service.). It leads to a situation where only the _jboss.clustering.group.ejb.dist_ service is registered in the naming context, but both services exist in the service registry.
> Such naming conflict can be a problem when for example we have to traverse through the naming context using ServiceBasedNamingStore as a naming provider. (JNDIView is a good example here, but I also managed to reproduce the problem when I messed up something with the remoting configuration. I don't remember details now.)
> JNDIView uses Context.list("") method in order to get the first level from the naming context. So in case of the _jboss.clustering.group.ejb.dist_ service the traverse path would be as follows:
> context.list("") -> returns "clustering"
> context.lookup( "clustering" ) returns NamingContext("clustering") because there is no service "jboss.clustering".
> NamingContext("clustering").list("") -> returns "group"
> NamingContext("clustering").lookup( "group" ) returns NamingContext("clustering/group") because there is no service "jboss.clustering.group".
> NamingContext("clustering/group").list("") -> returns "ejb"
> NamingContext("clustering/group").lookup("ejb") -> Fails!
> It fails with an _NameNotFoundException_ simply because the first thing the ServiceBasedNamingStore component does is to check if there is the _jboss.naming.context.java.jboss.clustering.group.ejb_ service in the service registry. It is available in the registry so ServiceBasedNamingStore decides to get the destination service instance the BinderService (_jboss.naming.context.java.jboss.clustering.group.ejb_) should point to. Service _jboss.clustering.group.ejb_ hasn't been started yet so its dependant the BinderService (_jboss.naming.context.java.jboss.clustering.group.ejb.dist_) couldn't resolve the injections and as so the BinderService does not point to the destination _jboss.clustering.group.ejb_ service instance. In the result, it ends with the exception because ServiceBasedNamingStore is not able to return the reference to the service the JNDI name _jboss.naming.context.java.jboss.clustering.group.ejb_ should point to. Notice that everything would be OK if there weren't running _jboss.naming.context.java.jboss.clustering.group.ejb.dist_ service, because Context.list("") ignores the _jboss.naming.context.java.jboss.clustering.group.ejb_ service as an unbound one.
> Anyway even if the service _jboss.naming.context.java.jboss.clustering.group.ejb_ was started properly and the naming context pointed to the _jboss.clustering.group.ejb_ service, it would lead to a different problem. The name _jboss.naming.context.java.jboss.clustering.group.ejb.dist_ wouldn't be found at all, because the _jboss.naming.context.java.jboss.clustering.group.ejb_ name would be treated as the end of the path while traversing using the Context.list("") method.
> It's probably a problem with the service naming convention, but anyway it is not an isolated case. There are a lot of services that follow the same naming rules but fortunately they are not registered in the naming context (yet?). For instance:
> {quote}
> jboss.clustering.group.hibernate.entity
> jboss.clustering.group.hibernate.timestamps
> jboss.clustering.group.hibernate
> {quote}
> Introducing something like a value aware NamingContext would also do the trick, but it's not natural for the JNDI.
> Anyway, it can be fixed in many ways, so for now I decided just to ignore such problematic services in the JNDIViewOperation just to avoid the exception.
> If anyone needs a workaround:
> Class: org.jboss.as.naming.management.JndiViewOperation
> jar: wildflay-naming-8.0.0.Final.jar
> Before (Line: 134):
> {code:title=org.jboss.as.naming.management.JndiViewOperation.java|borderStyle=solid}
> final Object value;
> if(context instanceof NamingContext) {
> value = ((NamingContext)context).lookup(pair.getName(), false);
> } else {
> value = context.lookup(pair.getName());
> }
> {code}
> After:
> {code:title=org.jboss.as.naming.management.JndiViewOperation.java|borderStyle=solid}
> Object value;
> try {
> if(context instanceof NamingContext) {
> value = ((NamingContext)context).lookup(pair.getName(), false);
> } else {
> value = context.lookup(pair.getName());
> }
> } catch( NameNotFoundException exc ) {
> value = null;
> }
> {code}
> It is the original exception:
> {noformat}
> 23:44:29,133 ERROR [stderr] (XNIO-1 task-8) javax.naming.NameNotFoundException: Error looking up clustering/group/ejb, service service jboss.naming.context.java.jboss.clustering.group.ejb is not started
> 23:44:29,133 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:133)
> 23:44:29,133 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:136)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:144)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:144)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.access$0(JndiViewOperation.java:125)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:75)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591)
> 23:44:29,136 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469)
> 23:44:29,136 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273)
> 23:44:29,142 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268)
> 23:44:29,142 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272)
> 23:44:29,143 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146)
> 23:44:29,145 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:169)
> 23:44:29,147 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> 23:44:29,150 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> 23:44:29,151 ERROR [stderr] (XNIO-1 task-8) at java.security.AccessController.doPrivileged(Native Method)
> 23:44:29,151 ERROR [stderr] (XNIO-1 task-8) at javax.security.auth.Subject.doAs(Subject.java:422)
> 23:44:29,151 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94)
> 23:44:29,152 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> 23:44:29,152 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> 23:44:29,153 ERROR [stderr] (XNIO-1 task-8) at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:50)
> 23:44:29,153 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:77)
> 23:44:29,154 ERROR [stderr] (XNIO-1 task-8) at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> 23:44:29,154 ERROR [stderr] (XNIO-1 task-8) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> 23:44:29,156 ERROR [stderr] (XNIO-1 task-8) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> 23:44:29,157 ERROR [stderr] (XNIO-1 task-8) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months