[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4050) Improve handling of bad exception handling config
by Matthew Lieder (JIRA)
Improve handling of bad exception handling config
-------------------------------------------------
Key: JBSEAM-4050
URL: https://jira.jboss.org/jira/browse/JBSEAM-4050
Project: Seam
Issue Type: Task
Components: Core
Affects Versions: 2.1.1.GA
Reporter: Matthew Lieder
If you have the following in pages.xml and throw that exception, Seam throws an NPE at org.jboss.seam.exception.Exceptions.parse(Exceptions.java:195):
<exception class="com.example.helloworld.BadParameterException" log="false">
</exception>
The cause is that while Exceptions.createHandler(...) can return null, Exceptions.parse(...) assumes that it can't. It appears that having an <exception> element without a <redirect> or <http-error> child is invalid (which definitely makes sense, since otherwise Seam would have no idea what to do when the exception happens), but given that it isn't enforced in the XSD and that I could definitely see others making this same mistake I definitely believe that this NPE should be avoided and a more informative error message should be shown (or even an exception upon Seam startup, while parsing pages.xml).
In a Seam vs. Spring Web Flow comparison one of the big knocks against Seam was its cryptic error messages; by filing tickets like this I'm trying to do my part to remedy that :)
--
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
16 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3743) Renderer gets confuesed when sending of email throws exception
by Alexander Sparkowsky (JIRA)
Renderer gets confuesed when sending of email throws exception
--------------------------------------------------------------
Key: JBSEAM-3743
URL: https://jira.jboss.org/jira/browse/JBSEAM-3743
Project: Seam
Issue Type: Bug
Components: Mail
Affects Versions: 2.1.0.SP1, 2.1.0.GA
Environment: Mac OS X 10.5.5, Java 5, JBoss 4.0.5 modified for seam 2.x
Reporter: Alexander Sparkowsky
Assignee: Pete Muir
Attachments: emailtest.xhtml
When sending of an email fails and an exception is thrown (i.e. mail server not available) the renderer seems to get into a wrong state.
<s:link> present on the page get the application context "project". So "/myseamapp/foo/bar" becomes "/project/foo/bar".
If the action that is trying to send the mail is called by <s:link> this link gets the path of the email view itself (including the "project" application context).
I've attached a Bean sending the email, the email template (/test.xhtml) and a simple view.
This is the mail session configuration from components.xml
<mail:mail-session host="localhost" port="2525" username="test" password="test" />
--
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
16 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3915) RESTEasy GET request: java.lang.RuntimeException: Bad arguments passed to public java.lang.String method
by Viggo Navarsete (JIRA)
RESTEasy GET request: java.lang.RuntimeException: Bad arguments passed to public java.lang.String method
---------------------------------------------------------------------------------------------------------
Key: JBSEAM-3915
URL: https://jira.jboss.org/jira/browse/JBSEAM-3915
Project: Seam
Issue Type: Bug
Environment: JDK 1.6
Jboss 5.0.0.GA for JDK 1.6
Seam 2.1.1.GA
Reporter: Viggo Navarsete
Deploying the attached project and going to the following url: http://localhost:8080/app-cci-seam/seam/resource/rest/gqiResource/getShel...
results in the following stacktrace:
09:00:03,046 ERROR [STDERR] java.lang.RuntimeException: Bad arguments passed to public java.lang.String com.tracetracker.cci.session.GqiResourceBean.getShelfLife(java.lang.String,java.lang.String) ( arg1, arg2
09:00:03,047 ERROR [STDERR] at org.resteasy.MethodInjectorImpl.invoke(MethodInjectorImpl.java:133)
09:00:03,047 ERROR [STDERR] at org.resteasy.ResourceMethod.invoke(ResourceMethod.java:162)
09:00:03,047 ERROR [STDERR] at org.resteasy.ResourceMethod.invoke(ResourceMethod.java:134)
09:00:03,047 ERROR [STDERR] at org.resteasy.Dispatcher.invoke(Dispatcher.java:161)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.resteasy.ResteasyResourceAdapter$1.process(ResteasyResourceAdapter.java:127)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.resteasy.ResteasyResourceAdapter.getResource(ResteasyResourceAdapter.java:71)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.servlet.SeamResourceServlet.service(SeamResourceServlet.java:80)
09:00:03,047 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
09:00:03,047 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
09:00:03,047 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
09:00:03,047 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
09:00:03,047 ERROR [STDERR] at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177)
09:00:03,048 ERROR [STDERR] at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267)
09:00:03,048 ERROR [STDERR] at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380)
09:00:03,048 ERROR [STDERR] at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507)
09:00:03,048 ERROR [STDERR] at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
09:00:03,048 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
09:00:03,048 ERROR [STDERR] at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
09:00:03,048 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
09:00:03,048 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
09:00:03,048 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
09:00:03,048 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
09:00:03,048 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
09:00:03,048 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
09:00:03,048 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
09:00:03,048 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
09:00:03,048 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
09:00:03,048 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
09:00:03,048 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
09:00:03,048 ERROR [STDERR] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
09:00:03,048 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
09:00:03,048 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
09:00:03,048 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
09:00:03,048 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
09:00:03,048 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
09:00:03,049 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
09:00:03,049 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
09:00:03,049 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
09:00:03,049 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
09:00:03,049 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
09:00:03,049 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
09:00:03,049 ERROR [STDERR] at java.lang.Thread.run(Thread.java:619)
09:00:03,049 ERROR [STDERR] Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
09:00:03,049 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
09:00:03,049 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
09:00:03,049 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
09:00:03,049 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
09:00:03,049 ERROR [STDERR] at org.resteasy.MethodInjectorImpl.invoke(MethodInjectorImpl.java:72)
09:00:03,049 ERROR [STDERR] ... 50 more
The interface for the RESTEasy webservice is com.tracetracker.cci.GqiResource
The implementation is com.tracetracker.cci.GqiResourceBean
I have tried to change the parameter types resulting in the same error. It looks the argumentss are not handlet corectly for GET requests.
--
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
16 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4053) Can't resolve EL Function which serialized to ViewState
by Hiroyuki Wada (JIRA)
Can't resolve EL Function which serialized to ViewState
-------------------------------------------------------
Key: JBSEAM-4053
URL: https://jira.jboss.org/jira/browse/JBSEAM-4053
Project: Seam
Issue Type: Bug
Components: EL
Affects Versions: 2.1.1.GA, 2.0.2.SP1
Reporter: Hiroyuki Wada
Attachments: FunctionMapperImpl.java.patch
It seems that EL Function which serialized to ViewState can't be resolved when the object is deserialize. Because the jboss-el directly use "Class#forName(String)". The code is as follows,
{code:title=org.jboss.el.lang.FunctionMapperImpl.java|borderStyle=solid}
public Method getMethod() {
if (this.m == null) {
try {
Class t = Class.forName(this.owner);
Class[] p = ReflectionUtil.toTypeArray(this.types);
this.m = t.getMethod(this.name, p);
} catch (Exception e) {
{code}
I think the above code cause ClassLoader Scope Problem. "Thread.currentThread().getContextClassLoader()" should be used.
I found the jboss-el already had utility method for "Class.forName". It's "ReflectionUtil#forName(String)" method. Please use this method.
--
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
16 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4021) ArrayIndexOutOfBoundsException in SessionContext.getNames() when concurrent access from same user
by Takayoshi Kimura (JIRA)
ArrayIndexOutOfBoundsException in SessionContext.getNames() when concurrent access from same user
-------------------------------------------------------------------------------------------------
Key: JBSEAM-4021
URL: https://jira.jboss.org/jira/browse/JBSEAM-4021
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Reporter: Takayoshi Kimura
ArrayIndexOutOfBoundsException in SessionContext.getNames() when concurrent access from same user
The SessionContext.getNames() calls super.getNames() and the BasicContext.getNames() does the following:
public String[] getNames()
{
//yes, I know about the toArray() method,
//but there is a bug in the RI!
Set<String> keySet = map.keySet();
String[] array = new String[ keySet.size() ];
int i=0;
for (String key: keySet)
{
array[i++] = key;
}
return array;
}
An ArrayIndexOutOfBoundsException (and possibly a ConcurrentModificationException) could be thrown when an entry is added to the session map during iteration, after the keySet.size() call.
The FacesLifecycle uses the ExternalContext.getSessionMap() for SessionContext internal data. This map is directly tied with HttpSession and it reflects changes on the HttpSession from other threads immediately.
This problem doesn't happen with ServletLifecycle because it uses ServletRequestMap class for internal data and this class always creates new instance per keySet() call. The keySet from this map won't be changed during iteration.
This problem happends regardless of debug mode.
--
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
16 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3947) Seam PersistentPermissionResolver do not recognizes roles created by RunAsOperation when checking 'hasPermission' method
by douglas carvalho (JIRA)
Seam PersistentPermissionResolver do not recognizes roles created by RunAsOperation when checking 'hasPermission' method
------------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-3947
URL: https://jira.jboss.org/jira/browse/JBSEAM-3947
Project: Seam
Issue Type: Bug
Components: Security
Affects Versions: 2.1.1.GA
Environment: Any
Reporter: douglas carvalho
When trying to register a new user by using persistent permission utilities of seam, we use RunAsOperation:
new RunAsOperation() {
public void execute() {
identityManager.createUser(user.getUsername(), user.getPassword());
identityManager.grantRole(user.getUsername(), "user");
}
}.addRole("admin").run();
RunAsOperation class adds the role "admin" to a SimpleGroup and put it in subject property. Then it calls run(), wich one calls runAs() in current session identity object. This one, by itself, get the Principal object from the RunAsOperation object passed as parameter. Since the RunAsOperation was just constructed, it 'principal's name is NULL. Execute() method we created calls createUser, wich one calls, before anything, the hasPermission() method from PersistentPermissionResolver.
In hasPermission() method of PersistentPermissionResolver, it gets the name of the current principal:
" String username = identity.getPrincipal().getName(); "
Since we are in the context execution of the RunAsOperation, as I sayd the getPrincipal().getName() returns NULL.
Now username is NULL.
A bit more forward, we have an iterator, passing by each of the permissions got from the database with the specified target and action.
The problem comes at exacly here:
It only checks the permission for the user got from the Principal. And since the real role asked to be the owner of the security checking is in 'subject' property of the identity, inside of a SimpleGroup, as a member of this one, and not in the 'principal' property, the seam code do the check over a NULL recipient, resulting in a NullPointerException.
if (permission.getRecipient() instanceof SimplePrincipal && username.equals(permission.getRecipient().getName())){
iter.remove();
break;
}
I modified some code to fix that:
for (Permission permission : permissions) {
try {
for (Principal grupo : identity.getSubject().getPrincipals()) {
if (grupo instanceof SimpleGroup) {
SimpleGroup grupoSimples = (SimpleGroup) grupo;
if (grupoSimples.isMember(new SimplePrincipal(permission.getRecipient().getName()))) {
return true;
}
}
}
if (permission.getRecipient() instanceof SimplePrincipal && username.equals(permission.getRecipient().getName())) {
return true;
}
if (permission.getRecipient() instanceof Role) {
Role role = (Role) permission.getRecipient();
if (role.isConditional()) {
RuleBasedPermissionResolver resolver = RuleBasedPermissionResolver.instance();
if (resolver.checkConditionalRole(role.getName(), target, action))
return true;
} else if (identity.hasRole(role.getName())) {
return true;
}
}
} catch (NullPointerException e) {
// Log or do something
}
}
--
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
16 years, 11 months