[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1229) Remoting exception with JMS subscription
by Alex Mateescu (JIRA)
Remoting exception with JMS subscription
----------------------------------------
Key: JBSEAM-1229
URL: http://jira.jboss.com/jira/browse/JBSEAM-1229
Project: JBoss Seam
Issue Type: Bug
Components: Remoting
Affects Versions: 1.2.1.GA
Environment: JEMS Installer 1.2 ejb3 profile, JBoss Portal 2.6.0ALPHA1, JBoss Seam 1.2.1GA running on Fedora Core 6, Firefox 1.5
Reporter: Alex Mateescu
Assigned To: Shane Bryzak
Priority: Minor
I am deploying an EAR with multiple (the number is probably irrelevant) JARs and WARs that use Seam Remoting and subscribe to a JMS topic.
The subscribe calls work fine, they send the correct topic name and receive a token. On the first poll, though, there is an exception:
2007-04-23 14:08:29,602 ERROR [org.jboss.seam.remoting.Remoting] Error
java.lang.IllegalArgumentException: Invalid token argument - token not found in Session Context. [undefined]
at org.jboss.seam.remoting.messaging.SubscriptionRegistry.getSubscription(SubscriptionRegistry.java:179)
at org.jboss.seam.remoting.messaging.PollRequest.poll(PollRequest.java:45)
at org.jboss.seam.remoting.PollHandler.handle(PollHandler.java:83)
at org.jboss.seam.remoting.Remoting.getResource(Remoting.java:110)
at org.jboss.seam.servlet.ResourceServlet.doGet(ResourceServlet.java:68)
at org.jboss.seam.servlet.ResourceServlet.doPost(ResourceServlet.java:77)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
Upon closer inspection, the polling request looks like this:
<envelope><body><poll token="c312b1bb-d996-46e4-a8d7-6f35caa99d73" timeout="10"/><poll token="undefined" timeout="10"/></body></envelope>
which is the cause of the exception.
Subsequent calls look fine:
<envelope><body><poll token="c312b1bb-d996-46e4-a8d7-6f35caa99d73" timeout="10"/><poll token="3922899d-1e6b-4bc1-96ab-3713f4460446" timeout="10"/></body></envelope>
I think the error was there before, when using Seam 1.1.0GA, but it was random. I may be wrong, but now it is always there.
Of course, remoting works fine after the initial call.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3942) LdapIdentityStore should crypt password
by Raimund Hölle (JIRA)
LdapIdentityStore should crypt password
---------------------------------------
Key: JBSEAM-3942
URL: https://jira.jboss.org/jira/browse/JBSEAM-3942
Project: Seam
Issue Type: Feature Request
Components: Security
Affects Versions: 2.1.1.GA, 2.1.1.CR2, 2.1.1.CR1, 2.1.0.SP1
Reporter: Raimund Hölle
Priority: Minor
LdapIdentityStore.changePassword() stores the new password always as plain text in the LDAP database.
To allow crypted passwords, i suggest the following modifications:
New bean properties (along with getter / setter):
private String passwordCryptAlgorithm = "SHA"; // Or "" for plain text, "MD5", ...
private String passwordEncoding = "UTF-8";
Extend changePassword() by one additional line:
public boolean changePassword(String name, String password)
{
InitialLdapContext ctx = null;
try
{
ctx = initialiseContext();
// crypt password if not already done
password = cryptPwIfNeeded(password);
BasicAttribute passwordAttrib = new BasicAttribute(getUserPasswordAttribute(), password);
New Helpers method:
private Pattern cryptedPwRegexp = Pattern.compile("^[{].+[}].+");
private String cryptPwIfNeeded(String password) {
// only crypt if requested by algorithm and not already done!
if (getPasswordCryptAlgorithm() != null
&& ! getPasswordCryptAlgorithm().equals("")
&& ! cryptedPwRegexp.matcher(password).matches()) {
try {
MessageDigest md;
md = MessageDigest.getInstance(getPasswordCryptAlgorithm());
md.reset();
md.update(password.getBytes(getPasswordEncoding()));
byte[] result = md.digest();
password = "{" + getPasswordCryptAlgorithm() + "}" + (new BASE64Encoder()).encode(result);
} catch ( NoSuchAlgorithmException e ) {
throw new IdentityManagementException(
"Configuration problem - can not crypt password with algorithm " + getPasswordCryptAlgorithm(), e);
} catch ( UnsupportedEncodingException e ) {
throw new IdentityManagementException(
"Configuration problem - can not encode password with " + getPasswordEncoding(), e);
}
}
return password;
}
Many regards, Raimund
--
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, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1250) Socket write error with Seam JMS Remoting
by Scott McNab (JIRA)
Socket write error with Seam JMS Remoting
-----------------------------------------
Key: JBSEAM-1250
URL: http://jira.jboss.com/jira/browse/JBSEAM-1250
Project: JBoss Seam
Issue Type: Bug
Components: Remoting
Affects Versions: 1.2.1.GA, 1.2.0.GA
Environment: WindowsXP, JBossAS 4.2.0.CR1
Reporter: Scott McNab
Assigned To: Shane Bryzak
Full details are given in the corresponding forum topic, however a summary is:
* Client-side javascript subscribes to a JMS topic by calling Seam.Remoting.subscribe().
* The client then navigates to a new page.
* Approximately 30 seconds later, a SocketException (socket write error) occurs on the server within Seam Remoting (presumably because my Seam poll-timeout is set to 30 seconds).
This occurs consistently with JBoss running under Windows, but does not seem to occur when the server is run on Linux. It is also not affected by browser type (i.e. it happens when using Firefox or IE). This bug did not occur previously when the same code was running with Seam 1.0.1.GA.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2911) GWT-RPC fails with java.lang.SecurityException
by Rainer Schuster (JIRA)
GWT-RPC fails with java.lang.SecurityException
----------------------------------------------
Key: JBSEAM-2911
URL: http://jira.jboss.com/jira/browse/JBSEAM-2911
Project: Seam
Issue Type: Bug
Components: GWT, Remoting
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA, 2.0.1.CR2, 2.0.1.CR1, 2.0.0.GA, 2.0.0.CR3, 2.0.0.CR2, 2.0.0.CR1, 2.0.0.BETA1
Environment: WinXP Pro SP 2, Maven 2.0.9, GWT 1.5 Milestone 2, Seam 2.1 Revision 7916
Reporter: Rainer Schuster
After http://jira.jboss.org/jira/browse/JBSEAM-2880 was fixed a new problem appeared:
2008-04-13 16:19:14,839 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/ASDF]] Exception while dispatching incoming RPC call
java.lang.SecurityException: Unable to access a service method called [myservice] on class [com.myproject.asdf.server.MyServiceX] without the @WebRemote attribute. This may be a hack attempt, or someone simply neglected to use the @WebRemote attribute to indicate a method as remotely accessible.
at org.jboss.seam.remoting.gwt.GWTToSeamAdapter.getMethod(GWTToSeamAdapter.java:128)
at org.jboss.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:98)
at org.jboss.seam.remoting.gwt.GWTService.processCall(GWTService.java:246)
at org.jboss.seam.remoting.gwt.GWTService$1.process(GWTService.java:146)
at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53)
at org.jboss.seam.remoting.gwt.GWTService.getResource(GWTService.java:130)
at org.jboss.seam.servlet.SeamResourceServlet.doGet(SeamResourceServlet.java:75)
at org.jboss.seam.servlet.SeamResourceServlet.doPost(SeamResourceServlet.java:92)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
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.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:73)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
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:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
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:595)
This error seams to occur independent of the content-type problem (http://jira.jboss.org/jira/browse/JBSEAM-2880), because it also occurs with older versions of GWT.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months