May 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCL-158) Expose current visiting root in VFSResourceVisitor

by Ales Justin (JIRA)

Expose current visiting root in VFSResourceVisitor -------------------------------------------------- Key: JBCL-158 URL: https://jira.jboss.org/jira/browse/JBCL-158 Project: JBoss ClassLoader Issue Type: Feature Request Components: VFS Affects Versions: JBossCL.2.2.0.Beta1 Reporter: Ales Justin Assignee: Ales Justin Most of the scanning api requires underlying classpath root to be indexed. Getting this from resource itself is either performance penalty or needs to load the class. The simplest way to expose this, while still not being too much of a hack or api ugliness, is to use thread local. -- 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

14 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2519) Support integration with external editor for BPMN 2.0 edition

by Antoine Toulme (JIRA)

Support integration with external editor for BPMN 2.0 edition ------------------------------------------------------------- Key: JBRULES-2519 URL: https://jira.jboss.org/browse/JBRULES-2519 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.1.0.M1 Reporter: Antoine Toulme Assignee: Mark Proctor And before you ask, the editor is Oryx. So here is how it goes. We use a GWT object to create an editor. The editor loads Oryx as an iframe, taking control over it by making sure domains match. When we click on Save, the GWT object talks with the editor to get the current model (in JSON). It saves the JSON. Load is a bit trickier. We load the model from the repository, (note that since Oryx use JSON to load its internal model, I am being very forgiving of what is being loaded, which is bad). I used a separate servlet for this as I didn't know Seam well. When loading the iframe, I add a parameter to the URL of the iframe, "uuid". The parameter is used to call the servlet, which returns the model as JSON. It works like a charm on Safari but needs to be QA'ed on different browsers. Of course, hacking Guvnor is only half the battle. Most of the changes went to Oryx. We maintain a branch of Oryx with those changes here: http://github.com/intalio/process-designer/ I will also open bugs for those changes to be brought back to the stock Oryx repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7547) Sync up ClusteredDeploymentRepository's addDeploymentContent with BasicDeploymentRepository

by Brian Stansberry (JIRA)

Sync up ClusteredDeploymentRepository's addDeploymentContent with BasicDeploymentRepository ------------------------------------------------------------------------------------------- Key: JBAS-7547 URL: https://jira.jboss.org/jira/browse/JBAS-7547 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, ProfileService Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.CR1 BasicDeploymentRepository.addDeploymentContent includes some logic to handle deployment options, e.g. exploding an archive deployment. Clustered version should do the same. Also, investigate how to get both classes using the same code. -- 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

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7264) DefaultRepositoryClusteringHandler needs better handling of SuspectException

by Brian Stansberry (JIRA)

DefaultRepositoryClusteringHandler needs better handling of SuspectException ---------------------------------------------------------------------------- Key: JBAS-7264 URL: https://jira.jboss.org/jira/browse/JBAS-7264 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.GA Reporter: Brian Stansberry Carlo reports this in a server startup during a testsuite run: 2009-09-14 23:24:49,703 ERROR [org.jboss.system.server.profileservice.repository.ScopedProfileServiceController] (Thread-1) Error installing to Create: name=ProfileKey@435c41b[domain=default, server=default, name=farm] state=Configured mode=On Demand requiredState=Installed java.lang.reflect.InvocationTargetException 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.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97) at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77) at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.install(AbstractProfileLifeCycleAction.java:49) at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540) at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:258) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:97) at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:851) at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.RuntimeException: SuspectedException at org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.rethrowAsUnchecked(DefaultRepositoryClusteringHandler.java:951) at org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.getModificationsFromCluster(DefaultRepositoryClusteringHandler.java:542) at org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.synchronizeContent(DefaultRepositoryClusteringHandler.java:309) at org.jboss.system.server.profileservice.repository.clustered.ClusteredDeploymentRepository.load(ClusteredDeploymentRepository.java:255) at org.jboss.system.server.profile.repository.AbstractProfile.create(AbstractProfile.java:158) ... 22 more Caused by: SuspectedException at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:603) at org.jgroups.blocks.RpcDispatcher.callRemoteMethod(RpcDispatcher.java:323) at org.jgroups.blocks.RpcDispatcher.callRemoteMethod(RpcDispatcher.java:304) at org.jboss.ha.framework.server.ClusterPartition.callMethodOnNode(ClusterPartition.java:1201) at org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.getModificationsFromCluster(DefaultRepositoryClusteringHandler.java:506) ... 25 more 2009-09-14 23:24:49,706 INFO [org.jboss.system.server.profileservice.ProfileServiceBootstrap] (Thread-1) Loading profile: ProfileKey@56de24c5[domain=default, server=default, name=cluster-udp-BR-1] 2009-09-14 23:24:49,706 DEBUG [org.jboss.system.server.profileservice.repository.AbstractProfileService] (Thread-1) Activating profile: NoopProfile@208e2fb5{key = ProfileKey@56de24c5[domain=default, server=default, name=cluster-udp-BR-1]} 2009-09-14 23:24:49,707 DEBUG [org.jboss.bootstrap.impl.base.server.AbstractServer] (Thread-1) Encountered exception while starting, caching it to be thrown later: java.lang.IllegalStateException: Incompletely deployed: SuspectException means one of the targets of a group RPC was excluded from the group before responding. Depending on when a SuspectException is thrown, it may be harmless; we need to recognized those points and deal with them rather than propagating the exception. -- 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

14 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7658) Support configuration of virtual host in jboss-app.xml

by Brian Stansberry (JIRA)

Support configuration of virtual host in jboss-app.xml ------------------------------------------------------ Key: JBAS-7658 URL: https://jira.jboss.org/jira/browse/JBAS-7658 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployers, Web (Tomcat) service Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.CR1 User has requested the following: When a WAR is being deployed as part of an EAR, along configuration of the virtual-host to which the web application is published within the EAR's deployment descriptor. Very much like they can control the context-root for the WAR from the EAR. For example: jboss-app.xml: <jboss-app> <module> <web> <web-uri>example-1.0.0.war</web-uri> <context-root>/example</context-root> <virtual-host>us</virtual-host> <virtual-host>canada</virtual-host> </web> </module> </jboss-app> This would allow the context root and virtual host list to be controlled from the EAR's deployment descriptor instead of having to extract the WAR from the EAR, modify the WAR's deployment descriptor and then repackage the EAR. As the EAR currently supports the functionality of overriding the WAR's deployment information it would make sense that this would be something that could be overridden. -- 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

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7720) Make on demand webapps hot-deployable

by Brian Stansberry (JIRA)

Make on demand webapps hot-deployable ------------------------------------- Key: JBAS-7720 URL: https://jira.jboss.org/jira/browse/JBAS-7720 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M3 The console's in M2's $JBOSS_HOME/common/deploy are not hot-deployable. See discussion beginning at http://community.jboss.org/message/521935#521935 for why not. We need to fix this for M3. As a workaround the war's can be made hot deployable by moving them back to the regular server/xxx/deploy dir and deleting the related xxx-activator-jboss-beans.xml file. -- 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

14 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7692) Clean up log.debug() usage

by Brian Stansberry (JIRA)

Clean up log.debug() usage -------------------------- Key: JBAS-7692 URL: https://jira.jboss.org/jira/browse/JBAS-7692 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M3 See the forum thread for discussion of the heavy debug logging that goes on during AS startup. This is a parent JIRA for a general cleanup; the real action items will be sub-tasks. I'll create a subtask for some general profiling work, and we can add subtasks for cleaning up specific areas (external projects or chunks of code in the AS codebase itself.) Cleanup consists of: 1) Convert overly spammy DEBUG logging to TRACE. When you convert it, preferably make it a log.debugf statement; otherwise add a guard unless the message is static. 2) Try and identify remaining debug log messages where the cost of constructing the message is high. 3) For such messages, either convert to log.debugf or add a log.isDebugEnabled() guard. -- 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

14 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7186) SuspectExceptions during data gravitation lead to DataGravitationCleanup command not executing

by Brian Stansberry (JIRA)

SuspectExceptions during data gravitation lead to DataGravitationCleanup command not executing ---------------------------------------------------------------------------------------------- Key: JBAS-7186 URL: https://jira.jboss.org/jira/browse/JBAS-7186 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.1.0.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 JBC is different from JBC 1.4 in how it handles suspected nodes during data gravitation. JBC would ignore them; w/ JBC 3 they propagate. These can happen easily with a cluster under load and a node failing. LB detects failure before view changes, node that has failing node as it backup starts gravitating, replication of the gravitated data to the (failed) backup throws a SuspectException. The clustering integration needs to handle this better. Right now gravitation attempts are wrapped in txs, so the SuspectException fails the tx commit. That's pretty non-recoverable unless we catch the commit failure and retry. A possibility is to not wrap the gravitation in a tx (not really needed except for FIELD) and use JBossCacheWrapper's get() retry logic to redo the gravitation. We already catch the exception and allow the request to continue if the data was actually retrieved. Actually, that only works because we wrap w/ the tx; JBC wouldn't return from the gravitation read without the tx causing the replication write to wait for tx commit. Hmm... Problem this causes now is 1) gravitated data doesn't replicate to buddy until a request changes it and causes a normal write 2) DataGravitationCleanupCommand is not issued, so stale data is left in the cache. Some of the changes made for JBCACHE-1530 reduce the likelihood of that stale data being used; it's only used if a request fails over to the node where it's stored, leading to gravitation from (stale) local backup tree. -- 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

14 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7296) Fix clustering related findbugs issues

by Brian Stansberry (JIRA)

Fix clustering related findbugs issues -------------------------------------- Key: JBAS-7296 URL: https://jira.jboss.org/jira/browse/JBAS-7296 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Review findbugs reports (see parent task), deal with issues in: 1) AS cluster module 2) JBCLUSTER project libraries 3) JBC 4) JGroups (notify JGroups team) 5) Cluster stuff in tomcat module 6) Cluster stuff in profile service 7) ServiceBindingManager A quick scan didn't show a whole lot, so this shouldn't be too bad. -- 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

14 years, 1 month

2
8
0 / 0

[JBoss JIRA] Created: (JBAS-7583) Move ServiceBindingManager to deploy

by Brian Stansberry (JIRA)

Move ServiceBindingManager to deploy ------------------------------------ Key: JBAS-7583 URL: https://jira.jboss.org/jira/browse/JBAS-7583 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M2 Once JBAS-7580 is completed, all services that open sockets will be in deploy, so ServiceBindingManager can go there as well. Services like JBM that count on SBM setting system properties will need to have a dependency added since it's now possible SBM would start after they do. -- 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

14 years, 1 month

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2010