[JBoss Web Services] - CDI @Inject in a JAX-WS service impl?
by Paul Robinson
Paul Robinson [https://community.jboss.org/people/paul.robinson] created the discussion
"CDI @Inject in a JAX-WS service impl?"
To view the discussion, visit: https://community.jboss.org/message/716601#716601
--------------------------------------------------------------
Hello,
I have a JAX-WS service implementation class, that tries to @Inject a bean. The bean does not seem to be injected. If I change the Web service impl to be a stateless session bean, the @Inject is done.
Here's my code, in which the inject is not done:
@WebService(serviceName = "EchoServiceService", portName = "EchoServicePort",
name = "EchoServiceImpl", targetNamespace = "http://my.org/simple")
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class EchoServiceImpl implements IEchoService
{
@Inject
HelloBean hello;
@WebMethod
public String sayHello(String msg) throws MyException
{
//throws a NPE:
return hello.sayHello(msg);
}
}
Is this a known limitation of JBossWS, or am I missing something?
Thanks,
Paul.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/716601#716601]
Start a new discussion in JBoss Web Services at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
14 years, 1 month
[jBPM] - Is jBPM Guvnor meant to be used for production runtime deployment or is it mainly for development sync?
by rohit_r
rohit_r [https://community.jboss.org/people/rohit_r] created the discussion
"Is jBPM Guvnor meant to be used for production runtime deployment or is it mainly for development sync?"
To view the discussion, visit: https://community.jboss.org/message/718415#718415
--------------------------------------------------------------
Hello All,
we want to use jBPM for our application. The requirement is that processes are developed by our developers then released to a secured production environment used for runtime.
The runtime is expected to
1) Load the right process template based on user context
a) Load the default version of process template if no template version info is provided.
b) Load the user specific version of the process template if a user specific version exists.
2) New process templates should be allowed to be added without bringing down the runtime environment.
The question we have is whether all these versioned templates should be maintained in Guvnor for access by the runtime engine? Or is Guvnor meant to be more for development artifact maintenance for syncing between developers etc.
The examples we have seen so far seem to use it more as a development tool rather than something which should be queried by the runtime engine frequently.
Should our application runtime use Guvnor connection and load processes from Guvnor at runtime on every request to start a process instance? Will this be a performance bottleneck for the runtime?
Thanks
Rohit
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/718415#718415]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
14 years, 1 month
[Beginner's Corner] - Re: Integrating LDAP server (ApacheDS) with JBoss AS
by Zakir Syed
Zakir Syed [https://community.jboss.org/people/zakhussain] created the discussion
"Re: Integrating LDAP server (ApacheDS) with JBoss AS"
To view the discussion, visit: https://community.jboss.org/message/718408#718408
--------------------------------------------------------------
I get the following trace log
2012-02-21 10:11:48,955 DEBUG [org.jboss.security.integration.JNDIBasedSecurityManagement] (http-127.0.0.1-8080-2) Creating SDC for domain=xxx
2012-02-21 10:11:48,955 DEBUG [org.jboss.security.plugins.auth.JaasSecurityManagerBase.xxx] (http-127.0.0.1-8080-2) CallbackHandler: mailto:org.jboss.security.auth.callback.JBossCallbackHandler@13290aa org.jboss.security.auth.callback.JBossCallbackHandler@13290aa
2012-02-21 10:11:48,955 DEBUG [org.jboss.security.plugins.auth.JaasSecurityManagerBase.xxx] (http-127.0.0.1-8080-2) CachePolicy set to: https://community.jboss.org/mailto:org.jboss.util.TimedCachePolicy@b7b28b org.jboss.util.TimedCachePolicy@b7b28b
2012-02-21 10:11:48,955 DEBUG [org.jboss.security.integration.JNDIBasedSecurityManagement] (http-127.0.0.1-8080-2) setCachePolicy, https://community.jboss.org/mailto:c=org.jboss.util.TimedCachePolicy@b7b28b c=org.jboss.util.TimedCachePolicy@b7b28b
2012-02-21 10:11:48,956 DEBUG [org.apache.catalina.authenticator.AuthenticatorBase] (http-127.0.0.1-8080-2) Calling authenticate()
2012-02-21 10:11:48,956 DEBUG [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-2) Save request in session '50B9CCC74E611ED1EC66BB1537F04416'
2012-02-21 10:11:48,958 DEBUG [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/AAJboss].[default]] (http-127.0.0.1-8080-2) Disabling the response for futher output
2012-02-21 10:11:48,958 DEBUG [org.apache.catalina.authenticator.AuthenticatorBase] (http-127.0.0.1-8080-2) Failed authenticate() test
2012-02-21 10:11:53,684 DEBUG [org.apache.catalina.connector.CoyoteAdapter] (http-127.0.0.1-8080-2) Requested cookie session id is 50B9CCC74E611ED1EC66BB1537F04416
2012-02-21 10:11:53,684 DEBUG [org.apache.catalina.authenticator.AuthenticatorBase] (http-127.0.0.1-8080-2) Security checking request POST /AAJboss/secured/j_security_check
2012-02-21 10:11:53,684 DEBUG [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-2) Authenticating username 'hnelson'
2012-02-21 10:11:53,685 DEBUG [org.jboss.security.auth.spi.LdapExtLoginModule] (http-127.0.0.1-8080-2) Bad password for username=hnelson
javax.naming.NoInitialContextException: Cannot instantiate class: [Root exception is java.lang.ClassNotFoundException: ]
at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.ldap.InitialLdapContext.<init>(Unknown Source)
at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:573)
at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:380)
at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:276)
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:210)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.defaultLogin(JaasSecurityManagerBase.java:552)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.authenticate(JaasSecurityManagerBase.java:486)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.isValid(JaasSecurityManagerBase.java:365)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:160)
at org.jboss.web.tomcat.security.JBossWebRealm.authenticate(JBossWebRealm.java:384)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:258)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:417)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException:
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.sun.naming.internal.VersionHelper12.loadClass(Unknown Source)
... 37 more
2012-02-21 10:11:53,685 DEBUG [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/AAJboss].[default]] (http-127.0.0.1-8080-2) Disabling the response for futher output
2012-02-21 10:11:53,685 DEBUG [org.apache.catalina.authenticator.AuthenticatorBase] (http-127.0.0.1-8080-2) Failed authenticate() test ??/AAJboss/secured/j_security_check
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/718408#718408]
Start a new discussion in Beginner's Corner at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
14 years, 1 month
[JBoss Messaging] - Re: no success increasing number of redelivery attempts
by stupormundi
stupormundi [https://community.jboss.org/people/stupormundi] created the discussion
"Re: no success increasing number of redelivery attempts"
To view the discussion, visit: https://community.jboss.org/message/646730#646730
--------------------------------------------------------------
Sorry for the late reponse, other tasks kept me from getting back to this piece of code :(
I've now set useDLQ=false on the MDB, and indeed, now redelivery attempts aren't limited to 5. I get the impression that redelivery attempts now go on forever. In this particular case, that may be preferable to 'only 5 times', maybe. However, generally, infinite message redelivery attempts aren't always acceptable.
What I would really want is that the config in messaging-service.xml , attribute "DefaultMaxDeliveryAttempts" , is respected (or some more fine-grained config, per queue or per MDB).
I saw some reports which maybe indicate this is a known problem in AS 5. Can anyone confirm this?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/646730#646730]
Start a new discussion in JBoss Messaging at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
14 years, 1 month