[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4127) rich:editor generating incorrect javascript
by Christopher Logan (JIRA)
rich:editor generating incorrect javascript
-------------------------------------------
Key: JBSEAM-4127
URL: https://jira.jboss.org/jira/browse/JBSEAM-4127
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.2.CR1
Environment: winxp
jdk1.5.0_16
seam2.1.2.cr1
Reporter: Christopher Logan
I can't tell if this is a RichFaces issue or Seam issue.
I have a seam project using the bundled RichFaces (3.3.0.GA) library. On my Ui I used the rich:tabPanel. on one of the panels
i included the rich:editor. I basically copied the example from the RichFaces demo site and it worked. but eventually
the editor itself didn't show up, and looking at it in Firefox I got the javascript syntax error
(on line 8 of skinning.js at the first if statement):
1 var tinyMceParams =
2 {theme:"simple"} ;
3 tinyMceParams.auto_resize = false;
4 tinyMceParams.readonly = false;
5 tinyMceParams.width = 400;
6 tinyMceParams.height = 300;
7 tinyMceParams.onchange_callback = function (event, inst) {
8 if (! ) return false;;A4J.AJAX.Submit('_viewRoot','property_form',event,{'parameters':{'ajaxSingle':'property_form:editor','property_form:j_id16':'property_form:j_id16'} ,'actionUrl':'/EnterpriseSeamApplication-war/acct/index.seam','similarityGroupingId':'property_form:j_id16','control':this,'implicitEventsQueue':'property_form:j_id16','requestDelay':1000} )
9 };
10 tinyMceParams.dialog_type = 'modal';
11 if(!tinyMceParams.skin){
12 tinyMceParams.skin = 'richfaces';
13 }
14if(tinyMceParams.strict_loading_mode == null){
15 tinyMceParams.strict_loading_mode = true;
16}
17var richParams = {extScriptSuffix : '', extCssSuffix : '/DATB/eAELXT5DOhSIAQ!sA18_', useSeamText : false};
18
19 new RichEditor('property_form:editor', richParams, tinyMceParams);
--
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
15 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4120) pages-2.1.xsd doesn't allow parameterized from-action
by Bob Shanahan (JIRA)
pages-2.1.xsd doesn't allow parameterized from-action
-----------------------------------------------------
Key: JBSEAM-4120
URL: https://jira.jboss.org/jira/browse/JBSEAM-4120
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Environment: OSX 10.5, Java 1.5, JBoss 4.2.3, Eclipse 3.4
Reporter: Bob Shanahan
Prior to upgrading from Seam 2.0.x to 2.1.x, it was possible to define (without schema validation error) a page navigation from-action using page parameter variables. In fact, it was the only way get parameterized page from-actions to work.
Given the following xhtml:
<ui:include src="exportsTitleBar.xhtml">
<ui:param name="title" value="#{messages.acctSummaryTitle}" />
<ui:param name="exportActionBean" value="#{acctManager}" />
<ui:param name="action" value="exportAcctSummary" />
</ui:include>
page navigation in pages.xml is defined as follows:
<page view-id="/view/acctSummary.xhtml">
<navigation from-action="#{exportActionBean[action]}">
<rule if-outcome="pdf">
<redirect view-id="/view/pdf/acctSummary.xhtml"/>
</rule>
<rule if-outcome="xls">
<redirect view-id="/view/xls/acctSummary.xhtml"/>
</rule>
</navigation>
</page>
Using the actual bean and action, as in <navigation from-action="#{acctManager.exportAcctSummary]}">, does not work.
While <navigation from-action="#{exportActionBean[action]}"> functions correctly with Seam 2.1.x, the pages-2.1.xsd produces a schema validation error due to restrictions of the from-action-expression... and ultimately the pages:method-expression, which is defined as follows:
<xs:simpleType name="method-expression">
<xs:restriction base="xs:token">
<xs:pattern value="#\{.+\..+\}"/>
</xs:restriction>
</xs:simpleType>
Either the page navigation from-action should be expressible via the actual bean and action or the method-expression should allow specification of a parameterized bean and action.
--
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
15 years, 8 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
15 years, 8 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
15 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3652) Major reentrancy problem with "Page Scope" components and injection/disinjection
by Denis Forveille (JIRA)
Major reentrancy problem with "Page Scope" components and injection/disinjection
--------------------------------------------------------------------------------
Key: JBSEAM-3652
URL: https://jira.jboss.org/jira/browse/JBSEAM-3652
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.0.GA, 2.0.3.CR1, 2.0.2.SP1
Environment: WebSphere v6.1.0.17 in POJO Mode
Reporter: Denis Forveille
Priority: Blocker
This bug is very similar to the JBSEAM-3295 bug, but for "Page Scope" components this time
Under stress, we have random NPE, "conversation expired" and other strange eroors from time to time in production
This is due to a flaw in the "BijectionInterceptor" class and it is quite easy to reproduce
On a facelets page, we have a datatable with a list of h:commadLink, teh first page of a classic "list entities/showDetail" scheme. The controleur that manages the list is in "Page Scope"
When the user clics on one of the link, then quickly clic on another link, another one etc... without waiting for the detail view to show up, we have two concurrent request addressed to the same Page Scope component (Verified by putting traces in the BijectionInterceptor class)
In BijectionInterceptor, in that case, counter == 2 after line 77 meaning there is two concurrent thread running: the current thread + another one currently "using" the component
The counter will be decrease for the first time on line 82, then a second time on line 129 and so, disinjection will occur on line 134. This occurs while there is another thread "using" the component, causing random NPE and other errors!!!!
In fact this will happen each time counter >1, ie there is more than one "concurrent" request on the same component
This alleviate some questions:-
- is this normal that 2 (or more) concurrent request from the same user/conversation/page acces the same page scope component concurrently (I thought seam was taking care of this and was serializing such requests...
- is this normal that on line 88, components are outjected, only when the last concurrent "user" of the component exits the interceptor and not when each request "eixts" the interceptor?
--
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
15 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3845) NullPointerException in org.jboss.seam.exception.Exceptions.parse
by Ond?ej Žižka (JIRA)
NullPointerException in org.jboss.seam.exception.Exceptions.parse
-----------------------------------------------------------------
Key: JBSEAM-3845
URL: https://jira.jboss.org/jira/browse/JBSEAM-3845
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.0.SP1
Environment: JBoss EAP 4.3.0 default, JSFUnit, run using Cactus ServletTestRunner
Reporter: Ond?ej Žižka
Seam throws a NPE when I run a JSFUnit test case. The test may be fault, but at least the NPE should be handled.
Full stack trace:
-------------------------------------------------------
15:11:11,933 ERROR [BaseXMLFilter] Exception in the filter chain
javax.servlet.ServletException: org.jboss.seam.InstantiationException: Could not instantiate Seam component: org.jboss.seam.exception.exceptions
at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:126)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70)
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:177)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507)
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:173)
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:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
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:241)
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:447)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.seam.InstantiationException: Could not instantiate Seam component: org.jboss.seam.exception.exceptions
at org.jboss.seam.Component.newInstance(Component.java:2096)
at org.jboss.seam.Component.getInstance(Component.java:1978)
at org.jboss.seam.Component.getInstance(Component.java:1957)
at org.jboss.seam.Component.getInstance(Component.java:1951)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.exception.Exceptions.instance(Exceptions.java:256)
at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:114)
... 31 more
Caused by: java.lang.NullPointerException
at org.jboss.seam.exception.Exceptions.parse(Exceptions.java:195)
at org.jboss.seam.exception.Exceptions.initialize(Exceptions.java:119)
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.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
at org.jboss.seam.Component.callComponentMethod(Component.java:2201)
at org.jboss.seam.Component.callCreateMethod(Component.java:2124)
at org.jboss.seam.Component.newInstance(Component.java:2084)
... 38 more
--
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
15 years, 8 months