[JBoss JIRA] Created: (JBPORTAL-1816) abillity to create profile at registration
by Andrew Oliver (JIRA)
abillity to create profile at registration
-------------------------------------------
Key: JBPORTAL-1816
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1816
Project: JBoss Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.6.3 Final, Identity-1.0.1
Reporter: Andrew Oliver
Presently the user has the ability to register, then after logging in they create a profile. At many places that portal will be used registration and initial profile creation are the same.
The JSF screens should be reworked to allow the profile fields to appear at registration per a setting. The user module/registration pieces would need to allow profile creation by a not yet logged in user when in the registration process.
--
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
17 years, 11 months
[JBoss JIRA] Created: (JGRP-528) NAKACK: spurious retransmission requests
by Bela Ban (JIRA)
NAKACK: spurious retransmission requests
-----------------------------------------
Key: JGRP-528
URL: http://jira.jboss.com/jira/browse/JGRP-528
Project: JGroups
Issue Type: Task
Affects Versions: 2.5
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6
Every now and then, spurious retransmission requests are received:
NAKACK.handleXmitReq(): (requester=192.168.5.2:4397, local_addr=192.168.5.2:4393) message 192.168.5.2:4393::600 not found in retransmission table of 192.168.5.2:4393: [650 : 1050 (1100) (size=x, missing=0, highest stability=650)]
It turns out that message #600 *was* actually retransmitted correctly, but the retransmission timer was cancelled too late, so that we got 1 or 2 spurious retransmit requests for the same message.
This doesn't happen very frequently, and only under heavy load (e.g. 8 nodes, every node sends 5M 5K messages with 500 threads).
Note that this issue DOES NOT LEAD TO INCORRECT BEHAVIOR !
--
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
17 years, 11 months
[JBoss JIRA] Created: (JBAS-4083) Ejb timers fire before the ear completely deploys
by Vadim Kopichenko (JIRA)
Ejb timers fire before the ear completely deploys
-------------------------------------------------
Key: JBAS-4083
URL: http://jira.jboss.com/jira/browse/JBAS-4083
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2, Scheduling/Timers
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Environment: WinNT, Sun JDK 1.5
Reporter: Vadim Kopichenko
Assigned To: Scott M Stark
Consider the following usecase.
The is an ear containing several ejb modules.
One of them has a ejb2.1 timed cmp entity bean.
If the timer associated with the bean fires during application deployment unexpected errors happen, cause other beans could be not already deployed.
This breaks application logic.
The problem happens both while server starts/stops and while hot ear's redeployment.
It would be much better if timers began to fire after the application had completely deployed.
I've also experienced a similar problem with undeployment.
Timer code was executed about a half of second after the undeployment had begun. Several ejb modules had been already undeployed by that moment.
I guess that timer actually fired exactly before the undeployment had begun but the ejbTimeout executed later due to threads syncronization issue.
Please, try also to investigate if this can be avoided.
PS
Some kind of patch or workaround for 4.0.5 (or even a hint about how this can be fixed) would be greatly appreciated.
--
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
17 years, 11 months
[JBoss JIRA] Created: (JBWEB-84) Class Cast Exception - when using CometProcessor - Jboss 4.2.0
by Vali Dumitru (JIRA)
Class Cast Exception - when using CometProcessor - Jboss 4.2.0
--------------------------------------------------------------
Key: JBWEB-84
URL: http://jira.jboss.com/jira/browse/JBWEB-84
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Windows
Reporter: Vali Dumitru
Assigned To: Mladen Turk
I have a servlet that implements CometProcessor interface. Whenever I try to access it I get :
java.lang.ClassCastException: org.jboss.web.tomcat.filters.ReplyHeaderFilter
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilterEvent(ApplicationFilterChain.java:398)
at org.apache.catalina.core.ApplicationFilterChain.doFilterEvent(ApplicationFilterChain.java:363)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:227)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:896)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:701)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2031)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
What is this? Is there a workaround?
--
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
17 years, 11 months