[JBoss JIRA] Commented: (JBPM-567) create reusable JSF UI components in webapp
by Ronald van Kuijk (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-567?page=comments#action_12357117 ]
Ronald van Kuijk commented on JBPM-567:
---------------------------------------
Although I think components can help when designing pages, there are some downsides to this. We have to have components that can be rendered in tools like exadel (RHDS) and Dreamweaver (JSFTools plugin). To many custom components make these pages impossible to design without deploying them in a server and do a lot of roundtrip design/deploy/redesign/redeploy/..... steps. Thoughts?
> create reusable JSF UI components in webapp
> -------------------------------------------
>
> Key: JBPM-567
> URL: http://jira.jboss.com/jira/browse/JBPM-567
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Web Interface
> Reporter: Tom Baeyens
> Assigned To: David Lloyd
> Fix For: jBPM 3.3
>
>
> We plan to package the building blocks of the webapplication as reusable JSF UI components. Candidates are : the task list, the list of process definitions you can start, the task form, ... One of the main objectives of creating these components is that this will be the reuse done between the plain webapplication and using jBPM in a portal.
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBAS-4075) JBossCacheManager.findLocalSessions concurrency issue
by Hany Mesha (JIRA)
JBossCacheManager.findLocalSessions concurrency issue
-----------------------------------------------------
Key: JBAS-4075
URL: http://jira.jboss.com/jira/browse/JBAS-4075
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.0.5.GA
Environment: SLES 9, SP3.
JBOSS 4.0.5.GA
Reporter: Hany Mesha
Assigned To: Brian Stansberry
When running a load test on a JBoss Cluster I see the following exception
2007‑02‑06 14:23:58,231 ERROR
[org.jboss.web.tomcat.tc5.session.JBossCacheManager:processExpires]
processExpires: failed with exception: java.util.NoSuchElementException
java.util.NoSuchElementException
at
EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$HashIterator.next(ConcurrentHashMap.java:1131)
at java.util.AbstractCollection.toArray(AbstractCollection.java:176)
at
org.jboss.web.tomcat.tc5.session.JBossCacheManager.findLocalSessions(JBossCacheManager.java:851)
at
org.jboss.web.tomcat.tc5.session.JBossCacheManager.processExpires(JBossCacheManager.java:1188)
at
org.jboss.web.tomcat.tc5.session.JBossManager.backgroundProcess(JBossManager.java:817)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1284)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1569)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1578)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1578)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1558)
at java.lang.Thread.run(Thread.java:595)
Upon further investigation and looking at the source code of JBossCacheManager in 4.0 branch, the method findLocalSessions() suffers from concurrency issue when calling java.util.AbstractCollection.toArray(Object[] array) which is not thread safe.
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBCLUSTER-183) Session ID lost over "secure" connector
by Sergey Zhukov (JIRA)
Session ID lost over "secure" connector
---------------------------------------
Key: JBCLUSTER-183
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-183
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Tier
Affects Versions: Q4Y6
Reporter: Sergey Zhukov
Assigned To: Brian Stansberry
I'm using AJP or HTTP connector with secure="true" attribute in JBoss cluster environment.
On every browser's request, my JSP code got new session id (session.getId()).
Also it affects load balancing with sticky sessions, because every new request goes to another node.
Try it, by simple index.jsp:
<%= session.getId() %>
Deploy it as farm application, open in browser and click refresh several times.
You'll see new id every time.
I've tried this with JBoss 4.0.5 with configuration: 'all'.
--
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
19 years, 3 months
[JBoss JIRA] Created: (EJBTHREE-923) Avoid unnecessary passivation/activation callbacks for beans cached on remote nodes
by Brian Stansberry (JIRA)
Avoid unnecessary passivation/activation callbacks for beans cached on remote nodes
-----------------------------------------------------------------------------------
Key: EJBTHREE-923
URL: http://jira.jboss.com/jira/browse/EJBTHREE-923
Project: EJB 3.0
Issue Type: Task
Components: Clustering
Affects Versions: AS 4.2.0 CR1
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: AS 4.2.0 CR2
Talking here about backup copy of an SFSB context on a remote node; i.e. not the instance on the node where the client is actively using it. Such a context's bean instance, interceptors and XPCs are still marshalled from replication, as they don't need to be unmarshalled unless used
Two issues:
1) If the context has been passivated to disk, and another replication of the context occurs, the old copy of the context will be read from disk before the new copy overwrites it. That's standard JBC behavior. Currently we are invoking @PostActivate on this old copy, and then immediately replacing it in the cache with the new copy. This @PostActivate call is unnecessary and forces an unneeded unmarshalling of the old context.
2) If the replicated context is in memory, and the local eviction thread decides to passivate it, we are calling @PrePassivate on the bean. This is unnecessary when the bean is fully marshalled; a fully marshalled bean can't be holding any state that needs cleanup.
--
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
19 years, 3 months