[JBoss JIRA] Created: (AS7-1429) jboss-javaee6-webapp and webservices
by Manuel Bogner (JIRA)
jboss-javaee6-webapp and webservices
------------------------------------
Key: AS7-1429
URL: https://issues.jboss.org/browse/AS7-1429
Project: Application Server 7
Issue Type: Bug
Components: CDI / Weld, Web Services
Affects Versions: 7.0.0.Final
Environment: ubuntu
Reporter: Manuel Bogner
Assignee: Stuart Douglas
Fix For: No Release
hi,
i installed a plain maven jboss-javaee6-webapp webapp to have a look at the new as7. deploying the application works fine and i can access http://localhost:8080/as7/index.jsf
then i tried to add a simple soap-webservice by adding to my standalone.xml:
...
<extensions>
...
<extension module="org.jboss.as.webservices"/>
...
</extensions>
...
<subsystem xmlns="urn:jboss:domain:webservices:1.0" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xmlns:jaxwsconfig="urn:jboss:jbossws-jaxws-config:4.0">
<wsdl-host>
localhost
</wsdl-host>
<modify-wsdl-address>
true
</modify-wsdl-address>
</subsystem>
...
copy pasted from the standalone-preview.xml
the webservice looks like the following and works as expected:
import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
/**
* @author manuel
*
*/
@WebService
@Stateless
public class TestService {
@WebMethod
public String echo(@WebParam final String toEcho) {
return toEcho;
}
}
but if i try to access the web content i only get the following error:
17:03:00,453 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/as7].[FacesServlet]] (http--127.0.0.1-8080-3) Servlet.service() for servlet FacesServlet threw exception: java.lang.IllegalStateException: Must call associate() before calling activate()
at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:277) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:114) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:88) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.Final.jar:7.0.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBAS-7218) ENC EM injection erroneously happens only once for web modules
by henk de boer (JIRA)
ENC EM injection erroneously happens only once for web modules
--------------------------------------------------------------
Key: JBAS-7218
URL: https://jira.jboss.org/jira/browse/JBAS-7218
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.1.0.GA
Environment: Observed problem on Mac OS X 10.5.7 and Debian Lenny 64 bits using JDK 6
Reporter: henk de boer
Using a persistence-context-ref element in the web.xml of a web module, it appears that this causes an EntityManager instance to be injected only once into the ENC of this component.
However, the EJB 3.0 spec states in section 16.2.1:
"In general, lookups of objects in the JNDI java: namespace are required to return a new instance of the requested object every time."
So the observed behavior seems to violate the spec. In addition, this is particularly troublesome since an EntityManager is explicitly not thread-safe. Using the same EM instance for simultaneous requests therefor doesn't work.
Of course there are several other methods to obtain an EM reference, for instance binding an EM factory directly to JNDI and using that to obtain the reference.
--
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
13 years, 5 months
[JBoss JIRA] Created: (JBAS-8800) Can't parse TLD for Trinidad demo application
by Stan Silvert (JIRA)
Can't parse TLD for Trinidad demo application
---------------------------------------------
Key: JBAS-8800
URL: https://issues.jboss.org/browse/JBAS-8800
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: 6.0.0.Final
Reporter: Stan Silvert
Assignee: Remy Maucherat
You can get the demo app here:
https://repository.apache.org/content/repositories/orgapachemyfaces-013/o...
You will see the error below on AS6 Final. This works on AS5.1 and it reportedly also works on Tomcat 7.
There is a similar issue here: https://issues.apache.org/jira/browse/TOMAHAWK-1560. I assume that one can be worked around by setting in war-deployers-jboss-beans.xml:
<bean name="TldParsingDeployer" class="org.jboss.deployment.TldParsingDeployer">
<property name="relativeOrder">2002</property>
<property name="useSchemaValidation">false</property>
<property name="useValidation">false</property>
</bean>
But even with no validation, you still get this error for the trinidad demo:
10:27:01,762 WARN [JBossEntityResolver] Trying to resolve systemId as a non-fil
e URL: http://java.sun.com/xml/ns/javaee
10:28:02,379 ERROR [AbstractKernelController] Error installing to Parse: name=vf
s:///C:/jboss-6.0.0.Final/server/default/deploy/trinidad-demo-1.2.14.war state=P
reParse mode=Manual requiredState=Parse: org.jboss.deployers.spi.DeploymentExcep
tion: Error creating managed object for vfs:///C:/jboss-6.0.0.Final/server/defau
lt/deploy/trinidad-demo-1.2.14.war
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentExcept
ion(DeploymentException.java:49) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithO
utput.createMetaData(AbstractParsingDeployerWithOutput.java:383) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithO
utput.createMetaData(AbstractParsingDeployerWithOutput.java:343) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithO
utput.createMetaData(AbstractParsingDeployerWithOutput.java:315) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithO
utput.deploy(AbstractParsingDeployerWithOutput.java:255) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(Deployer
Wrapper.java:179) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(Deployer
sImpl.java:1832) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFi
rst(DeployersImpl.java:1550) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(Deployers
Impl.java:1491) [:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(Abstra
ctControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractContr
oller.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(Abstra
ctController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementSta
teDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(Abstr
actController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(Abstr
actController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractContro
ller.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractContro
ller.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersI
mpl.java:1983) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(Deployers
Impl.java:1076) [:2.2.0.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeploye
rImpl.java:679) [:2.2.0.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.p
rocess(MainDeployerPlugin.java:106) [:6.0.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$Delegate
Deployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(Profil
eDeployAction.java:151) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.installAction
Internal(ProfileDeployAction.java:94) [:0.2.2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction
(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction
(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.sim
pleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.
2.0.GA]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.ins
tall(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install
(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(Abstra
ctControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractContr
oller.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(Abstra
ctController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementSta
teDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(Abstr
actController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(Abstr
actController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractContro
ller.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractContro
ller.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicPro
fileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(Pr
ofileActivationWrapper.java:87) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activate
Profile(ProfileActivationService.java:215) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activate
(ProfileActivationService.java:159) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.ac
tivate(AbstractProfileServiceBootstrap.java:112) [:0.2.2]
at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolve
rFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.st
art(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceB
ootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.0.0.Final]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceB
ootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.0.0.Final]
at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(A
bstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.r
un(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_18]
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: vfs://
/C:/jboss-6.0.0.Final/server/default/deploy/trinidad-demo-1.2.14.war/WEB-INF/lib
/trinidad-impl-1.2.14.jar/META-INF/tr.tld@1,238
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBPars
er.java:224) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java
:178) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:257) [jbossx
b.jar:2.0.3.GA]
at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:231) [jbossx
b.jar:2.0.3.GA]
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(Sch
emaResolverDeployer.java:137) [:2.2.0.GA]
at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java
:64) [:6.0.0.Final]
at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java
:38) [:6.0.0.Final]
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(Sch
emaResolverDeployer.java:121) [:2.2.0.GA]
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.handl
eMultipleFiles(AbstractVFSParsingDeployer.java:446) [:2.2.0.GA]
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse
(AbstractVFSParsingDeployer.java:319) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithO
utput.createMetaData(AbstractParsingDeployerWithOutput.java:376) [:2.2.0.GA]
... 47 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to parse schema
for nsURI=http://java.sun.com/xml/ns/javaee, localName=taglib, schemaLocation=nu
ll
at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(A
bstractMutableSchemaResolver.java:350) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startE
lement(SundayContentHandler.java:176) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.startElement(SaxJBos
sXBParser.java:401) [jbossxb.jar:2.0.3.GA]
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Sour
ce) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Sou
rce) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Sourc
e) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unkn
own Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.s
canRootElementHook(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
Dispatcher.dispatch(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
known Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [x
ercesImpl.jar:6.0.0.Final]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [x
ercesImpl.jar:6.0.0.Final]
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) [xercesImpl
.jar:6.0.0.Final]
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) [xe
rcesImpl.jar:6.0.0.Final]
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Sour
ce) [xercesImpl.jar:6.0.0.Final]
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBPars
er.java:209) [jbossxb.jar:2.0.3.GA]
... 57 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 -1:-1 schema_refe
rence.4: Failed to read schema document 'null', because 1) could not find the do
cument; 2) the document could not be read; 3) the root element of the document i
s not <xsd:schema>.
at org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHa
ndler.handleError(XsdBinderTerminatingErrorHandler.java:40) [jbossxb.jar:2.0.3.G
A]
at org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown
Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source) [xercesIm
pl.jar:6.0.0.Final]
at org.jboss.xb.binding.Util.loadSchema(Util.java:394) [jbossxb.jar:2.0.
3.GA]
at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.ja
va:178) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.ja
va:149) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(A
bstractMutableSchemaResolver.java:342) [jbossxb.jar:2.0.3.GA]
... 72 more
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBAS-9318) BridgeLogger doesn't support addAppender, getAppender and other methods available to a log4j Logger
by Richard Robinson (JIRA)
BridgeLogger doesn't support addAppender, getAppender and other methods available to a log4j Logger
---------------------------------------------------------------------------------------------------
Key: JBAS-9318
URL: https://issues.jboss.org/browse/JBAS-9318
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 6.0.0.Final
Reporter: Richard Robinson
Assignee: David Lloyd
The JBoss 6 BridgeLogger is missing some functionality of the log4j Logger class that our app needs to dynamically reconfigure the logger. We need this primarily because we want to send error logging to only an error appender if tracing if off and, if tracing is on, we want to send error logging to both an error appender and also to the trace appender. The idea is that the error log always only shows errors and that the trace log will show both tracing and errors.
To make this work programmatically we use the Logger getAllAppenders, getAppender, setAppender, removeAppender and setLevel calls. Unfortunately, only the setLevel call seems to work in the current BridgeLogger implementation and the other methods apparently do nothing.
Although we are using the log4j API, it might be helpful to illustrate the configuration in jboss-logging.xml terms. We want to be able to set up a configuration that is effectively like this if tracing is off:
<logger category="errors">
<handlers>
<handler-ref name="CONSOLE"/>
<handler-ref name="ERROR"/>
</handlers>
</logger>
<logger category="tracing">
<level name="OFF"/>
<handlers>
<handler-ref name="TRACING"/>
</handlers>
</logger>
So if tracing is turned off, the error logger goes to the error appender/handler and the console.
However, if tracing is turned on. We want to dynamically set to something like this (again this is in effective jboss-logging.xml terms... we actually do make the changes using the log4j API):
<logger category="errors">
<handlers>
<handler-ref name="CONSOLE"/>
<handler-ref name="ERROR"/>
<handler-ref name="TRACING"/>
</handlers>
</logger>
<logger category="tracing">
<level name="DEBUG"/>
<handlers>
<handler-ref name="TRACING"/>
</handlers>
</logger>
The difference is that now the error logger now has a new appender/handler for TRACING which wasn't there for the tracing off case. Also the tracing logger is now set to level DEBUG.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBAS-8818) CDI injection not working in WebListeners
by Nicklas Karlsson (JIRA)
CDI injection not working in WebListeners
-----------------------------------------
Key: JBAS-8818
URL: https://issues.jboss.org/browse/JBAS-8818
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Weld/CDI
Affects Versions: 6.0.0.Final
Reporter: Nicklas Karlsson
Assignee: Marius Bogoevici
CDI injection is not performed for WebListeners, e.g.
@WebListener
public class BugListener implements HttpSessionListener
{
@Inject
BeanManager beanManager;
...
}
Will have beanManager==null when the methods are hit
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBAS-8939) Expose BeanManager in JNDI even for non Java EE module deployments
by Marius Bogoevici (JIRA)
Expose BeanManager in JNDI even for non Java EE module deployments
------------------------------------------------------------------
Key: JBAS-8939
URL: https://issues.jboss.org/browse/JBAS-8939
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Reporter: Marius Bogoevici
Assignee: Marius Bogoevici
Fix For: 6.1.0
Currently the Weld deployer registers the BeanManager in JNDI in the global namespace if the deployment is a WAR or EJB-JAR.
Expose the Weld deployer in the global namespace even if the deployment is not a WAR or EJB-JAR. This is necessary for non-Java EE deployments (e.g. an ESB jar).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBAS-8792) No request scope during an EJB timeout method
by Adam Warski (JIRA)
No request scope during an EJB timeout method
---------------------------------------------
Key: JBAS-8792
URL: https://issues.jboss.org/browse/JBAS-8792
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Weld/CDI
Affects Versions: 6.0.0.Final, 6.0.0.CR1
Reporter: Adam Warski
Assignee: Marius Bogoevici
Since AS6 CR1, during an EJB timeout method, when trying to use request-scoped beans, I am getting an exception: "No active contexts for scope type javax.enterprise.context.RequestScoped". According to specs, this should work.
As a temporary workaround, I am registering a request context by hand:
@Inject
BoundRequestContext requestContext;
Map<String, Object> context = new HashMap<String, Object>();
try {
requestContext.associate(context);
requestContext.activate();
// Do the timeout stuff
} finally {
requestContext.invalidate();
requestContext.deactivate();
requestContext.dissociate(context);
}
Btw. I tried doing this with an interceptor, but it seems that neither EJB interceptors or CDI interceptors work with timers ...
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months