[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1048) Documentation enhancement for injecting TaskInstance and ProcessInstance (add full package name)
by Arjan van Bentem (JIRA)
Documentation enhancement for injecting TaskInstance and ProcessInstance (add full package name)
------------------------------------------------------------------------------------------------
Key: JBSEAM-1048
URL: http://jira.jboss.com/jira/browse/JBSEAM-1048
Project: JBoss Seam
Issue Type: Feature Request
Components: Documentation
Affects Versions: 1.2.0.GA
Environment: All
Reporter: Arjan van Bentem
Priority: Optional
This may be too obvious for some, but maybe, just maybe, the following needs some enhancements:
http://fisheye.jboss.com/browse/JBoss/jboss-seam/doc/reference/en/modules... reads:
@StartTask
[...]
The jBPM TaskInstance will be available in a request context variable
named taskInstance. The jPBM ProcessInstance will be available in a
request context variable named processInstance. (Of course, these
objects are available for injection via @In.)
Built-in Seam components TaskInstance and ProcessInstance exist, but in fact are not used here. Due to the @Unwrap in org.jboss.seam.core.TaskInstance and ProcessInstance one actually gets an org.jbpm.taskmgmt.exe.TaskInstance and an org.jbpm.graph.exe.ProcessInstance injected.
The exception when the Java code expects a Seam component is in fact clear:
java.lang.IllegalArgumentException: Could not set field value by reflection:
TodoList.processInstance on: org.jboss.seam.example.todo.TodoList with
value: class org.jbpm.graph.exe.ProcessInstance
However, this error might be embedded in a long list of other exceptions. For example, when adding the injection to the TodoList example it will be the 5th embedded exception in a message that starts with "javax.servlet.ServletException: Cannot get value for expression '#{todoList.description}'".
Fix:
Maybe the text above could be changed to include the full package name (hoping that it will not change in the near future):
The jBPM org.jbpm.taskmgmt.exe.TaskInstance will be available in a request context variable
named taskInstance. The jBPM org.jbpm.graph.exe.ProcessInstance will be available in a
request context variable named processInstance. (Of course, these
objects are available for injection via @In.)
The very same text applies to @BeginTask.
When not changing the documentation then, as of now, at least JIRA will show a hit when searching for "injection AND ProcessInstance" ;-)
--
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
18 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1324) javascript error in IE6 when remote call does not render anything to response.
by Keith Naas (JIRA)
javascript error in IE6 when remote call does not render anything to response.
------------------------------------------------------------------------------
Key: JBSEAM-1324
URL: http://jira.jboss.com/jira/browse/JBSEAM-1324
Project: JBoss Seam
Issue Type: Bug
Components: Remoting
Reporter: Keith Naas
Assigned To: Shane Bryzak
If an exception occurs in the remote call, it is caught by the ExecutionHandler, logged, and the request is ended. Since nothing is written to the response, the document is empty. In IE6 this causes a javascript error.
Something like this should get rid of the problem.
### Eclipse Workspace Patch 1.0
#P jboss-seam
Index: src/remoting/org/jboss/seam/remoting/remote.js
===================================================================
RCS file: /cvsroot/jboss/jboss-seam/src/remoting/org/jboss/seam/remoting/remote.js,v
retrieving revision 1.3
diff -u -r1.3 remote.js
--- src/remoting/org/jboss/seam/remoting/remote.js 1 May 2007 00:08:12 -0000 1.3
+++ src/remoting/org/jboss/seam/remoting/remote.js 15 May 2007 14:39:58 -0000
@@ -624,13 +624,16 @@
var bodyNode;
var context = new Seam.Remoting.__Context;
- for (var i = 0; i < doc.documentElement.childNodes.length; i++)
+ if (doc.documentElement)
{
- var node = doc.documentElement.childNodes.item(i);
- if (node.tagName == "header")
- headerNode = node;
- else if (node.tagName == "body")
- bodyNode = node;
+ for (var i = 0; i < doc.documentElement.childNodes.length; i++)
+ {
+ var node = doc.documentElement.childNodes.item(i);
+ if (node.tagName == "header")
+ headerNode = node;
+ else if (node.tagName == "body")
+ bodyNode = node;
+ }
}
if (headerNode)
--
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
18 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1333) Methods annotated with @Restrict("#{s:hasPermission cause uncaught Auth Exception
by Damian Harvey (JIRA)
Methods annotated with @Restrict("#{s:hasPermission cause uncaught Auth Exception
---------------------------------------------------------------------------------
Key: JBSEAM-1333
URL: http://jira.jboss.com/jira/browse/JBSEAM-1333
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 1.2.1.GA
Environment: JBoss 4.0.5GA
Seam 1.2.1GA
Reporter: Damian Harvey
If I have a method annotated with a permission eg: @Restrict("#{s:hasPermission('vesselHome','persist',vesselHome.instance)}") and an unauthorised User tries to access this method then the resulting org.jboss.seam.security.AuthorizationException is not intercepted as per the entry in pages.xml and is propagated to the browser.
pages.xml:
<exception class="org.jboss.seam.security.AuthorizationException">
<redirect view-id="/secure/home.xhtml">
<message>#{messages['org.jboss.seam.security.AuthorizationException']}</message>
</redirect>
</exception>
method:
@Name("myObjectHome")
public class MyObjectHome extends EntityHome<Vessel> {
@Override
@Transactional
@Restrict("#{s:hasPermission('vesselHome','persist',vesselHome.instance)}")
public String persist() {
String status = super.persist();
return status;
}
}
--
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
18 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-906) Support redirect component for navigation out of conversational scope
by Christian Bauer (JIRA)
Support redirect component for navigation out of conversational scope
---------------------------------------------------------------------
Key: JBSEAM-906
URL: http://jira.jboss.com/jira/browse/JBSEAM-906
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Reporter: Christian Bauer
Priority: Minor
It's about my favorite subject, the "history" or "cancel" button.
Assume the following (RC == Root Conversation, NC == Nested Conversation):
RC(1) -> NC(2) -> NC(3)
I can render a Cancel button on each page in NC 2 and 3 with the action=#{conversation.endAndRedirect()} to get back to any parent NC or RC.
I can not render a Cancel button on each page in RC, because there is no "parent view-id" we could redirect to. So my Cancel button on these pages has to call some logic I've written on my RC backing component.
I propose to extend the Conversation.endAndRedirect() method with the following logic:
- If called in a NC, do what it currently does.
- If called in a RC, check if the 'redirect' component is present in RC, if yes, call 'redirect.execute()'
If this would be available, I could completely control conversation navigation and the navigation history through nesting conversations (with s:link or pages.xml) and by ensuring that a RC has a prepared 'redirect' component when it is started. All Cancel buttons would be able to use action="#{conversation.endAndRedirect()}" and would either get the user "one up" in the conversation stack or "out" of conversational scope.
--
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
18 years, 10 months