September 2009 - jboss-user - Jboss List Archives

by Bounced mail

This message was undeliverable due to the following reason(s): Your message was not delivered because the destination server was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message could not be delivered within 1 days: Mail server 167.42.235.218 is not responding. The following recipients did not receive this message: <jboss-user(a)lists.jboss.org> Please reply to postmaster(a)lists.jboss.org if you feel this message to be in error.

16 years, 7 months

1
0
0 / 0

[JBoss Portal Users] - Re: Removing Dashboard Feature

by junanax

Thanks, Peter! I tried it and the dashboard is still there. I tried deleting the whole document and nothing changed.:-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257159#4257159 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257159

16 years, 7 months

1
0
0 / 0

[JBoss Web Services Users] - Re: Authenticating SOAP Requests with WSSE UsernameToken doe

by sthatcher

I did a bit more investigation on this and found the crux of the issue but I'm not sure how to solve it. In the login configuration for the realm you are supposed to use a UsernameTokenCallback object to update the digest based on the existence of a nonce or created. However, on debugging, these values are always null. And the init function sends a map with both keys (nonce and created) set to null. So the question is what other configuration do I need to tell JBoss to pull out these header nodes and send to the callback handler. The specific login config is as follows: | <application-policy name="MyRealm"> | <authentication> | <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" | flag="required"> |  | <module-option name = "dsJndiName">java:/WSExampleDS</module-option> | <module-option name = "principalsQuery">SELECT password FROM users WHERE username=?</module-option> | <module-option name = "rolesQuery">SELECT r.role, 'Roles' FROM roles r join users u on u.id = r.userid WHERE u.username=?</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="unauthenticatedIdentity">anonymous</module-option> | <module-option name="storeDigestCallback">org.jboss.ws.extensions.security.auth.callback.UsernameTokenCallback</module-option> | | </login-module> | </authentication> | </application-policy> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257157#4257157 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257157

16 years, 7 months

1
0
0 / 0

[jBPM Users] - Re: jbpm 4.1 - Task assignment

by sebastian.s

If Joram is right changing to a newer version of the console won't help alone. Read the comments again where he wrote about the change to the runtime source code. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257156#4257156 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257156

16 years, 7 months

1
0
0 / 0

[Persistence] - Re: JBoss does not reconnect after mysql-server restart

by henk53

I found this other thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4158716 It seems that if you have valid connection checker, then basically the redeployment of the datasource would not really be needed. Sure, it might still be better to redeploy instead of waiting for every connection to have thrown an exception, but eventually the pool *should* recover automatically. Only. clearly it doesn't (or it doesn't always). The topic starter has a valid connection checker configured, so if I understand correctly those connections should have been closed and re-opened, shouldn't they? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257153#4257153 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257153

16 years, 7 months

1
0
0 / 0

[Persistence] - Re: JBoss does not reconnect after mysql-server restart

by henk53

"PeterJ" wrote : Try "touching" the *-ds.xml file. That will update the last modified timestamp which will cause the app server to redeploy the datasource. Peter, is there any more automatic recovery available? I just encountered a similar problem. We have many Jboss AS instances connecting to a central DB. Because of a full disk the DB (Postgres) stopped working and after resolving the problem the DB had to be restarted. The problem was that none of the Jboss instances were able to connect anymore after this restart and they all had to be restarted manually. This is rather tedious to say the least. Touching the *-ds.xml file reliefs this pain only a little. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257152#4257152 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257152

16 years, 7 months

1
0
0 / 0

[JMX] - Exception when deploying a XMBean

by rsobchak

I have a standard MBean that deploys fine on JBossesb-server-4.6 (JDK 1.5). I used twiddle to create the XMBean XML from the MBean. I then changed the jboss-service.xml to | <?xml version='1.0' encoding='UTF-8' ?> | <!DOCTYPE server PUBLIC | "-//JBoss//DTD MBean Service 3.2//EN" | "http://www.jboss.org/j2ee/dtd/jboss-service_3_2.dtd"> | <server> | |  | <classpath codebase="." archives="*" /> | |  | <mbean code="com.mail.MailService" | name="com.mail:service=MailService" | xmbean-dd="mailservice-xmbean.xml"> | </mbean> | </server> | The mailservice-xmbean.xml looks like | <?xml version="1.0" encoding="UTF-8"?> | <!DOCTYPE mbean PUBLIC | "-//JBoss//DTD JBOSS XMBEAN 1.2//EN" | "http://www.jboss.org/j2ee/dtd/jboss_xmbean_1_2.dtd"> |  | <mbean> | <description>Management Bean.</description> | <class>com.mail.MailService</class> | | <constructor> | <description>MBean Constructor.</description> | <name>com.mail.MailService</name> | </constructor> | | &defaultAttributes; | | <attribute access='read-write' getMethod='getMailFromName' setMethod='setMailFromName'> | <description>MBean Attribute.</description> | <name>MailFromName</name> | <type>java.lang.String</type> | </attribute> | <attribute access='read-write' getMethod='getMailFrom' setMethod='setMailFrom'> | <description>MBean Attribute.</description> | <name>MailFrom</name> | <type>java.lang.String</type> | </attribute> | <attribute access='read-only' getMethod='getStateString'> | <description>MBean Attribute.</description> | <name>StateString</name> | <type>java.lang.String</type> | </attribute> | <attribute access='read-only' getMethod='getState'> | <description>MBean Attribute.</description> | <name>State</name> | <type>int</type> | </attribute> | <attribute access='read-write' getMethod='isEnabled' setMethod='setEnabled'> | <description>MBean Attribute.</description> | <name>Enabled</name> | <type>boolean</type> | </attribute> | <attribute access='read-only' getMethod='getName'> | <description>MBean Attribute.</description> | <name>Name</name> | <type>java.lang.String</type> | </attribute> | <attribute access='read-write' getMethod='getMailURL' setMethod='setMailURL'> | <description>MBean Attribute.</description> | <name>MailURL</name> | <type>java.lang.String</type> | </attribute> | | <operation> | <description>MBean Operation.</description> | <name>start</name> | <return-type>void</return-type> | </operation> | <operation> | <description>MBean Operation.</description> | <name>jbossInternalLifecycle</name> | <parameter> | <description></description> | <name>p1</name> | <type>java.lang.String</type> | </parameter> | <return-type>void</return-type> | </operation> | <operation> | <description>MBean Operation.</description> | <name>destroy</name> | <return-type>void</return-type> | </operation> | <operation> | <description>MBean Operation.</description> | <name>create</name> | <return-type>void</return-type> | </operation> | <operation> | <description>MBean Operation.</description> | <name>sendTestMessage</name> | <return-type>void</return-type> | </operation> | <operation> | <description>MBean Operation.</description> | <name>stop</name> | <return-type>void</return-type> | </operation> | <operation> | <description>MBean Operation.</description> | <name>sendTestMessage</name> | <parameter> | <description></description> | <name>p1</name> | <type>java.lang.String</type> | </parameter> | <return-type>void</return-type> | </operation> | | &defaultOperations; | | </mbean> | During deployment the following exception is thrown | org.jboss.deployment.DeploymentException: Class does not expose a management interface: java.lang.Object; - nested throwable: (javax.management.NotCompliantMBeanException: Class does not expose a management interface: java.lang.Object) | at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:196) | at org.jboss.system.ServiceController.install(ServiceController.java:226) | at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) | at $Proxy4.install(Unknown Source) | at org.jboss.deployment.SARDeployer.create(SARDeployer.java:251) | at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969) | at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) | at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) | at $Proxy9.deploy(Unknown Source) | at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) | at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634) | at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) | at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336) | at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) | at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) | at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) | at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) | at $Proxy0.start(Unknown Source) | at org.jboss.system.ServiceController.start(ServiceController.java:417) | at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) | at $Proxy4.start(Unknown Source) | at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304) | at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) | 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:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) | at $Proxy5.deploy(Unknown Source) | at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) | at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) | at org.jboss.Main.boot(Main.java:200) | at org.jboss.Main$1.run(Main.java:508) | at java.lang.Thread.run(Thread.java:595) | Caused by: javax.management.NotCompliantMBeanException: Class does not expose a management interface: java.lang.Object | at org.jboss.mx.metadata.MBeanCapability.of(MBeanCapability.java:102) | at org.jboss.mx.metadata.MBeanCapability.of(MBeanCapability.java:100) | at org.jboss.mx.metadata.MBeanCapability.of(MBeanCapability.java:100) | at org.jboss.mx.metadata.MBeanCapability.of(MBeanCapability.java:100) | at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:182) | at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) | at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422) | at java.security.AccessController.doPrivileged(Native Method) | at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417) | at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350) | at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345) | at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181) | at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:451) | at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171) | ... 80 more | I don't understand why the exception is getting thrown. There is a MailServiceMBean interface that the MailService implements. What am I missing? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257147#4257147 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257147

16 years, 7 months

1
0
0 / 0

[JBoss Web Services Users] - Exception with X509 certificates on jbossws-native-3.1.1.GA

by jorgerst

Hi! I'm having trouble to use WS-Security with X509 certificates. I've followed the instructions of the wiki ( http://www.jboss.org/community/wiki/JBossWS-NativeUserGuide#WSSecurity ). But when I invoke my service (using SoapUI, correctly configured with a X509 signed and encrypted SOAP request) I am getting the following exception: ERROR [WSSecurityDispatcher] Internal error occured handling inbound message: | org.jboss.ws.extensions.security.exception.WSSecurityException: Currently only SubjectKeyIdentifiers are supported, was passed: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profil... Plus, my jboss-wsse-server.xml is like this: | <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 jboss-wsse-server.xsd"> | | <key-store-file>WEB-INF/wsse.keystore</key-store-file> | <key-store-password>jbossws</key-store-password> | <trust-store-file>WEB-INF/wsse.truststore</trust-store-file> | <trust-store-password>jbossws</trust-store-password> | | <config> | <encrypt type="x509v3" alias="wsse" /> | <sign type="x509v3" alias="wsse" /> | <requires> | <encryption /> | <signature /> | </requires> | <timestamp ttl="300" /> | </config> | </jboss-ws-security> I'm using Sun JDK 1.5.0.15, JBoss AS 4.2.3 and jbossws-native-3.1.1.GA. I'm not very familiar with the security stuff, so please, if anybody could help it will be great! Thanks in advance! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257143#4257143 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257143

16 years, 7 months

1
0
0 / 0

[JBoss Cache Users] - Re: how to lock a node for update?

by alllle

Thanks for the reply, I just realized that you answered the questions before my last post :) I am still not clear with two of the answers and wonder if you can help: "manik.surtani(a)jboss.com" wrote : | "alllle" wrote : | | - With "REPEATABLE_READ" isolation, is the "write skew" still a problem? - I think it's not but I'd like to get a confirmation from you. | | | Write skews are *only* a problem with R_R. See the discussion in the user guide for details. | So if I have isolation set to R_R in the config file, when I call the cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true); | Is the isolation for the current invocation context still the R_R, or is it changed to some thing else? In other words, do I still need to worry about write skew? "manik.surtani(a)jboss.com" wrote : "alllle" wrote : | | - What is the scope of the current "InvocationContext"? Is it within the current transaction, or current thread, or something else? | | | Invocation contexts last for, well, an invocation! :-) | Could you explain more on what an "invocation" is then? This answer, I have to say, doesn't really help :) What I'd like to know is the impact of the call. Should I remove the option override after the transaction? Does other thread who is accessing the same cache affected by this call? etc. Thanks, View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257142#4257142 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257142

16 years, 7 months

1
0
0 / 0

[JBoss Messaging Users] - Stateless Session Bean and JMS best practice

by ab2003

Based on this forum post http://www.jboss.org/index.html?module=bb&op=viewtopic&t=127090 the create/close a connection and session per JMS message is considered an anti-pattern. For reference, we are using JBoss EAP 4.3.0 and JBoss Messaging 1.4.0.SP3 What is the best practice for a Stateless Session Bean that sends JMS messages in response to some (high throughput) external stimulus? Should there be one Session and Connection per Bean instance, potentially creating hundreds of these references depending on the size of the EJB pool? Or are the Session and Connection objects thread-safe, and assuming that the application is not calling close() on them, can one Session/Connection per JMS destination be used safely? We currently use the connection/session-per-bean-instance model, but are wondering if we are creating unnecessary overhead by doing so. Profiling the heap shows thousands of JBossSession and JBossConnection objects because the EJB pools have expanded to handle heavy load. Thanks for any pointers on best-practice. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257140#4257140 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257140

16 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-user September 2009