September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBJCA-429) Create a common-impl-papaki artifact

by Jesper Pedersen (JIRA)

Create a common-impl-papaki artifact ------------------------------------ Key: JBJCA-429 URL: https://jira.jboss.org/browse/JBJCA-429 Project: IronJacamar Issue Type: Task Components: Common Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Beta3 Create a common-impl-papaki artifact such that Papaki isn't a required artifact for the distribution -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8386) Remove saaj-api.jar from distribution

by Alessio Soldano (JIRA)

Remove saaj-api.jar from distribution ------------------------------------- Key: JBAS-8386 URL: https://jira.jboss.org/browse/JBAS-8386 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Build System, Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 6.0.0.CR1 See JBWS-3117, basically saaj-api.jar have been included as a replacement for the old jbossws-native-saaj.jar time ago. Currently, leveraging the saaj api coming with JDK6 is OK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-8380) Deploy the timerservice-mk2 jar only when there's a EJB3.x deployment in the server

by jaikiran pai (JIRA)

Deploy the timerservice-mk2 jar only when there's a EJB3.x deployment in the server ----------------------------------------------------------------------------------- Key: JBAS-8380 URL: https://jira.jboss.org/browse/JBAS-8380 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: EJB3 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: 6.0.0.CR1 The EJB3 timerservice-mk2.jar is only applicable for EJB3.x beans. So if there are no EJB3.x deployments in the server, then there's no point in deploying that timerservice-mk2.jar. Deploying that jar on-demand (i.e. when the first EJB3.x deployment becomes available) is also going to improve the AS boot time. The referenced forum thread has more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-8393) Switch to the new EJB resolvers SPI

by Marius Bogoevici (JIRA)

Switch to the new EJB resolvers SPI ----------------------------------- Key: JBAS-8393 URL: https://jira.jboss.org/browse/JBAS-8393 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Marius Bogoevici -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-8392) org.jboss.as.javaee.SimpleJavaEEModuleInformer#getModulePath returns incorrect module name for toplevel non-ear deployments

by jaikiran pai (JIRA)

org.jboss.as.javaee.SimpleJavaEEModuleInformer#getModulePath returns incorrect module name for toplevel non-ear deployments --------------------------------------------------------------------------------------------------------------------------- Key: JBAS-8392 URL: https://jira.jboss.org/browse/JBAS-8392 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: 6.0.0.M4 Reporter: jaikiran pai Assignee: jaikiran pai The JavaEEModuleInformer specifies this requirement for getModulePath(): /** * Obtain the relative path of the deployment unit within the JavaEE application * or base deployment directory. * The deployment unit is either a JavaEE module or a component of the JavaEE module. * If the JavaEE module is part of a JavaEE application return the relative * path within the JavaEE application otherwise it is considered a stand alone deployment * and return the relative path within the base deployment directory. * Note that the relative path includes the module name, for example 'lib/bar.jar'. * * @param deployment the deployment unit of the module or a component * @return the relative path of the JavaEE module */ String getModulePath(DeploymentUnit deploymentUnit); However the current implementation in SimpleJavaEEModuleInformer has this: public String getModulePath(DeploymentUnit unit) { return unit.getRelativePath(); } This incorrectly returns an empty string for a toplevel non-ear deployment (for ex: a standalone .war deployment). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-8397) org.jboss.test.deployers.weld.test.WeldTranslatorExampleUnitTestCase

by Shelly McGowan (JIRA)

org.jboss.test.deployers.weld.test.WeldTranslatorExampleUnitTestCase -------------------------------------------------------------------- Key: JBAS-8397 URL: https://jira.jboss.org/browse/JBAS-8397 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Shelly McGowan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-7212) Web app context not being processed in JBoss 5.1 for Cactus test case

by Brendan Farragher (JIRA)

Web app context not being processed in JBoss 5.1 for Cactus test case --------------------------------------------------------------------- Key: JBAS-7212 URL: https://jira.jboss.org/jira/browse/JBAS-7212 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.GA Environment: JBoss 5.1.0GA, Cactus 1.8.1, Red Hat Developer Studio 2.0.0GA, Ubuntu Linux 9.04 Reporter: Brendan Farragher Configuring context-root in application.xml for Cactus test case works on JBoss 4.2.3 AS but not on JBoss 5.1 AS. Please deploy the attached .ear file to both JBoss 4.2.3 and JBoss 5.1 servers, and run Cactus test case from IDE. Cactus test app runs fine in JBoss 4.2.3, but not JBoss 5.1. Tried multiple configurations, including adding a context.xml file with the context path name to META-INF folder, and then to WEB-INF/lib (in separate tests). Both tests failed in JBoss 5.1. I have attached the .ear file that I tested with on my machine, and the Eclipse projects to build the web app. The code is from the samples/ejb3 folder of the Cactus 1.8.1 distribution. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
6
0 / 0

[JBoss JIRA] Commented: (JBAS-8297) Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped

by Stephen Coy (JIRA)

[ https://jira.jboss.org/browse/JBAS-8297?page=com.atlassian.jira.plugin.sy... ] Stephen Coy commented on JBAS-8297: ----------------------------------- The same problem appears to exist for error pages. Consider the following from a web.xml: <error-page> <error-code>404</error-code> <location>/404.xhtml</location> </error-page> Attempts to access request scoped variables from this page generate an exception with the above message. 17:09:15,322 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/wax].[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:679) [:1.0.1.SP4] at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:138) [:1.0.1.SP4] at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:100) [:1.0.1.SP4] at org.jboss.weld.util.CleanableMethodHandler.invoke(CleanableMethodHandler.java:43) [:1.0.1.SP4] at org.jboss.weld.servlet.HttpSessionManager_$$_javassist_135.setSession(HttpSessionManager_$$_javassist_135.java) at org.jboss.weld.jsf.WeldPhaseListener.initiateSessionAndConversation(WeldPhaseListener.java:168) [:1.0.1.SP4] at org.jboss.weld.jsf.WeldPhaseListener.beforeRestoreView(WeldPhaseListener.java:118) [:1.0.1.SP4] at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:87) [:1.0.1.SP4] at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) [:2.0.2-FCS] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) [:2.0.2-FCS] at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110) [:2.0.2-FCS] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [:2.0.2-FCS] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312) [:2.0.2-FCS] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:734) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:543) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:479) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:407) [:6.0.0.20100721-M4] at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:431) [:6.0.0.20100721-M4] at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:357) [:6.0.0.20100721-M4] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [:6.0.0.20100721-M4] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.20100721-M4] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.20100721-M4] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.20100721-M4] at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.20100721-M4] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.20100721-M4] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.20100721-M4] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [:6.0.0.20100721-M4] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.20100721-M4] at java.lang.Thread.run(Thread.java:637) [:1.6.0_20] 17:09:15,331 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] Exception Processing ErrorPage[errorCode=404, location=/404.xhtml]: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped at javax.faces.webapp.FacesServlet.service(FacesServlet.java:325) [:2.0.2-FCS] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:734) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:543) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:479) [:6.0.0.20100721-M4] at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:407) [:6.0.0.20100721-M4] at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:431) [:6.0.0.20100721-M4] at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:357) [:6.0.0.20100721-M4] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [:6.0.0.20100721-M4] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.20100721-M4] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.20100721-M4] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.20100721-M4] at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.20100721-M4] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.20100721-M4] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.20100721-M4] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [:6.0.0.20100721-M4] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.20100721-M4] at java.lang.Thread.run(Thread.java:637) [:1.6.0_20] Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:679) [:1.0.1.SP4] at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:138) [:1.0.1.SP4] at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:100) [:1.0.1.SP4] at org.jboss.weld.util.CleanableMethodHandler.invoke(CleanableMethodHandler.java:43) [:1.0.1.SP4] at org.jboss.weld.servlet.HttpSessionManager_$$_javassist_135.setSession(HttpSessionManager_$$_javassist_135.java) [:1.0.1.SP4] at org.jboss.weld.jsf.WeldPhaseListener.initiateSessionAndConversation(WeldPhaseListener.java:168) [:1.0.1.SP4] at org.jboss.weld.jsf.WeldPhaseListener.beforeRestoreView(WeldPhaseListener.java:118) [:1.0.1.SP4] at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:87) [:1.0.1.SP4] at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) [:2.0.2-FCS] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) [:2.0.2-FCS] at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110) [:2.0.2-FCS] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [:2.0.2-FCS] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312) [:2.0.2-FCS] ... 18 more > Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped > ------------------------------------------------------------------------------------------ > > Key: JBAS-8297 > URL: https://jira.jboss.org/browse/JBAS-8297 > Project: JBoss Application Server > Issue Type: Bug > Components: Weld/CDI > Environment: JBoss 6.0.0.M2, Windows XP SP3 > Reporter: Marcos Antonio > Attachments: solicitacoes.zip > > > 2010-04-22 09:55:36,484 WARN [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-1239) Spurious warning "unblocking after xxx ms" from FLUSH.blockMessageDuringFlush()

by Eric Sirianni (JIRA)

Spurious warning "unblocking after xxx ms" from FLUSH.blockMessageDuringFlush() ------------------------------------------------------------------------------- Key: JGRP-1239 URL: https://jira.jboss.org/browse/JGRP-1239 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Environment: All Reporter: Eric Sirianni Assignee: Bela Ban Priority: Minor JavaDoc from java.util.concurrent.locks.Condition.await(...) indicates that FALSE is returned if a timeout occurred. {code} /** * ... * @return {@code false} if the waiting time detectably elapsed * before return from the method, else {@code true} */ boolean await(long time, TimeUnit unit) throws InterruptedException; {code} However, the JGroups code below is acting as if TRUE is returned if a timeout occurred. {code} private void blockMessageDuringFlush() { boolean shouldSuspendByItself = false; blockMutex.lock(); try { while (isBlockingFlushDown) { if (log.isDebugEnabled()) log.debug(localAddress + ": blocking for " + (timeout <= 0 ? "ever" : timeout + "ms")); shouldSuspendByItself = notBlockedDown.await(timeout, TimeUnit.MILLISECONDS); } if (shouldSuspendByItself) { isBlockingFlushDown = false; log.warn(localAddress + ": unblocking after " + timeout + "ms"); flush_promise.setResult(Boolean.TRUE); notBlockedDown.signalAll(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { blockMutex.unlock(); } } {code} This causes spurious WARNING level messages to be logged by JGroups when in fact no timeout occurred. The fix is simple: {noformat} < shouldSuspendByItself = notBlockedDown.await(timeout, TimeUnit.MILLISECONDS); -- > shouldSuspendByItself = !notBlockedDown.await(timeout, TimeUnit.MILLISECONDS); {noformat} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8466) Clean up InterfaceElement

by Brian Stansberry (JIRA)

Clean up InterfaceElement ------------------------- Key: JBAS-8466 URL: https://jira.jboss.org/browse/JBAS-8466 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Make current InterfaceElement impl an abstract superclass with subclasses for ServerInterfaceElement and InterfaceElement, which differ in whether they require criteria. Make the inet-address child element equivalent to any other criteria; it can be mixed with other criteria. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2010