persistence.xml and datasource
by Jari Fredriksson
Hello!
Jboss likes to name jdbc-datasources like java://DefaultDS
I would like to use name like jdbc/MyDatasource in my persistence.xml
That is so the definition would be portable across application servers out there. I'm sure there must a simple way to declare and alias for persistence.xml use, but have not found out it yet.
Any ideas?
17 years, 1 month
[JBossWS] - WS-Security Username Token Password Digest
by bschmoll1
I'm having some dfficulty in converting a web service from a cleartext password to using a password digest. Following the directions from http://jbossws.jboss.org/mediawiki/index.php?title=WS-Security_options I've created a "JBossWSDigest" application policy in the login-config.xml
| <application-policy name="JBossWSDigest">
| <authentication>
| <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
| <module-option name="usersProperties">props/jbossws-users.properties</module-option>
| <module-option name="rolesProperties">props/jbossws-roles.properties</module-option>
| <module-option name="hashAlgorithm">SHA</module-option>
| <module-option name="hashEncoding">BASE64</module-option>
| <module-option name="hashUserPassword">false</module-option>
| <module-option name="hashStorePassword">true</module-option>
| <module-option name="storeDigestCallback">org.jboss.ws.extensions.security.auth.callback.UsernameTokenCallback</module-option>
| <module-option name="unauthenticatedIdentity">anonymous</module-option>
| </login-module>
| </authentication>
| </application-policy>
|
The jboss-wsse-server.xml
| <?xml version="1.0" encoding="UTF-8"?>
| <jboss-ws-security xmlns="http://www.jboss.com/ws-security/config"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://www.jboss.com/ws-security/config
| http://www.jboss.com/ws-security/schema/jboss-ws-security_1_0.xsd">
| <config>
| <requires/>
| <username digestPassword="true" useNonce="true" useCreated="true"/>
| <authenticate>
| <usernameAuth/>
| </authenticate>
| <!-- <timestamp ttl="300"/> -->
| </config>
| </jboss-ws-security>
|
When I call the service via soapUI the following is dumped in the server.log
| 2008-11-28 12:24:04,065 DEBUG [org.jboss.ejb3.security.Ejb3AuthenticationInterceptor] Authentication failure
| javax.security.auth.login.LoginException: storeDigestCallback callback failed
| at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:409)
| at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:209)
| at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:152)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
| at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
| at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
| at java.security.AccessController.doPrivileged(Native Method)
| at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
| at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
| at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:603)
| at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:537)
| at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
| at org.jboss.aspects.security.AuthenticationInterceptor.authenticate(AuthenticationInterceptor.java:123)
| at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:66)
| at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.wsf.container.jboss42.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:103)
| at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:221)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:466)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:284)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:201)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:134)
| at org.jboss.wsf.stack.jbws.EndpointServlet.service(EndpointServlet.java:84)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| 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:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
| at java.lang.Thread.run(Thread.java:619)
| Caused by: javax.security.auth.callback.UnsupportedCallbackException: Unrecognized Callback
| at org.jboss.security.auth.callback.SecurityAssociationHandler.handle(SecurityAssociationHandler.java:128)
| at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:955)
| at java.security.AccessController.doPrivileged(Native Method)
| at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:951)
| at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:399)
| ... 49 more
|
It seems like the exception is due to the "Unrecognized Callback" but I don't see what I'm missing in the configuration.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193274#4193274
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193274
17 years, 1 month
[Microcontainer] - Re: Alternative JAR extensions
by bob.mcwhirter
So, a quick analysis might confirm your suspicions of HDScanner doing the scan() "too soon". I may be confused, of course, but here's my amateur analysis...
While HDScanner itself is a BOOTSTRAP bean, I assume it gets completely start()'d and running before the DEPLOYER phase.
When start()'d, it scan()'s. Conceivably scanning deploy/ for APPLICATION before all deployers have been deployed. Hence getChildren(...) on deploy/ not being enabled to view .rails archives as vfszips. Maybe. :)
Looking at my log timestamps, I see...
| 16:11:20,978 TRACE [HDScanner] Begin deployment scan
|
Then a while later (5 seconds), my log indicates the JEP installation from my deployer in the deployers/ directory.
| 16:11:25,860 INFO [RailsStructure] getJarExtension()...
|
I don't know the implementation of the solution, but seems like some barrier on the start()/scan() of HDScanner to hold it until the DEPLOYER phase is completely completed, perhaps.
For now, I can just use ".jar" as an extension.
Thanks,
-Bob
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193270#4193270
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193270
17 years, 1 month
[Microcontainer] - Re: Alternative JAR extensions
by bob.mcwhirter
anonymous wrote :
| If you mark one of your deployers as JarExtensionProvider
|
My RailsStructure deployer implements JEP. Additionally, I've added setJarExtension( ".rails" ) on one of my parsing deployers (seems like a weird place for it, honestly), since AbstractParsingDeployerWithOutput implements JEP, too. Both result in the same FileHandler'ing of my oddthesis.rails JAR, instead of the DelegatingHandler/JarHandler.
anonymous wrote :
| + you put your deployers into deployers directory (the proper way)
|
Yah, I've been using deployers/ always to deploy the jboss-rails.deployer itself.
anonymous wrote :
| you should be fine, as deployers are booted before deploy is scanned.
| --> different boot phases: BOOTSTRAP, DEPLOYERS, APPLICATIONS
Yah, that's what I figured the code told me, but it still seems that boot-scan doesn't enable the .rails in time for the VFSContextFactory bits, even for deploy/ but subsequent scans do.
I'm going to keep poking, and I'll update here.
Thanks,
-Bob
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193264#4193264
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193264
17 years, 1 month
[JBoss Cache: Core Edition] - Where can I get underlying JBossCache from within JMX
by jorgemoralespou_2
Hi,
I was using JBossCache 1.4, and with default JMX registration I used to get my TreeCache from within TreeCacheMBean, registered under "jboss.cache:service=MyCache".
Now I'm trying to migrate to JBC 3, and registered my cache within an MBean, that when it starts registers all the caches I use, with a JmxRegistrationManager, using same ObjectName.
When my classes try to get the Cache through the registered MBean, it is not registered.
If I list registered MBeans for cache resources, I don't see the one I used to use, but these:
jmx-resource=CacheMgmtInterceptor,service=MyCache
| jmx-resource=DataContainerImpl,service=MyCache
| jmx-resource=MVCCLockManager,service=MyCache
| jmx-resource=RPCManager,service=MyCache
| jmx-resource=RegionManagerImpl,service=MyCache
| jmx-resource=TransactionTable,service=MyCache
| jmx-resource=TxInterceptor,service=MyCache
|
| I`m using JBAS 4.2.3 with a tweaked version of JBC 3.0.1 (refactored like jarjar would have done).
|
| Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193262#4193262
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193262
17 years, 1 month
