[JBoss JIRA] Created: (JBAS-8495) Eliminate DeploymentUnitElement "allowed" field
by Brian Stansberry (JIRA)
Eliminate DeploymentUnitElement "allowed" field
-----------------------------------------------
Key: JBAS-8495
URL: https://jira.jboss.org/browse/JBAS-8495
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.0.0.M1
[10:19am] bstansberry: right now DeploymentUnitElement has this "allowed" property
[10:20am] bstansberry: which if false is supposed to mean that deployment is ineligible to be mapped to a ServerGroup
[10:20am] bstansberry: I'm inclined to trash that
[10:20am] bstansberry: any opinions?
[10:21am] bstansberry: having it means having a separate class ServerGroupDeploymentElement, plus we'd need to have update operations to toggle "allowed"
[10:21am] dmlloyd: it's basically a domain-wide disable of the deployment, right?
[10:21am] bstansberry: yeah
[10:22am] dmlloyd: doesn't ServerGroupDeploymentElement also have an "allowed" field?
[10:22am] bstansberry: no, it has "start"
[10:22am] bstansberry: which is whether it's actually deployed
[10:22am] bstansberry: (could use a rename, but that's another issue)
[10:22am] dmlloyd: hmm
[10:22am] dmlloyd: well I envision those two as being the same thing
[10:23am] dmlloyd: the global "allowed" flag would restrict deployment, not mapping
[10:23am] bstansberry: I don't think "allowed" as a kind of shortcut to undeploy things is worth it
[10:23am] bstansberry: if users want something undeployed, update the server group
[10:24am] dmlloyd: the use case would be, someone discovers a security issue in a deployment which is mapped to 45 server groups
[10:24am] bstansberry: create a deployment plan and fix it
[10:24am] dmlloyd: I guess they could just remove the deployment globally
[10:24am] bstansberry: "allowed" is just a shortcut for a deployment plan
[10:24am] bstansberry: with vague semantics unless we write some really nice documentation
[10:25am] dmlloyd: I guess I'm willing to trust deployment plans
--
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
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8425) UrlIntegrationDeployer.undeploy() doesn't remove from classpath
by Stan Silvert (JIRA)
UrlIntegrationDeployer.undeploy() doesn't remove from classpath
---------------------------------------------------------------
Key: JBAS-8425
URL: https://jira.jboss.org/browse/JBAS-8425
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployers
Affects Versions: 6.0.0.M4
Reporter: Stan Silvert
Assignee: Ales Justin
When a deployment has more than one instance of UrlIntegrationDeployer, undeploy() will not behave properly. The problem is that INTEGRATION_FLAG_KEY is static:
public static final String IS_INTEGRATION_FLAG_KEY = UrlIntegrationDeployer.class.getSimpleName() + "::isIntegrationDeployment";
During undeploy(), the first UrlIntegrationDeployer instance will remove the attachment from the deployment unit. Then when undeploy() is called on other instances of UrlIntegrationDeployer, it will not find the flag and thus skip removeFromClassPath().
It looks like IS_INTEGRATION_FLAG_KEY should be an instance variable instead of static. Perhaps something like this would be an acceptable fix?
public final String IS_INTEGRATION_FLAG_KEY = UrlIntegrationDeployer.class.getSimpleName() + "::isIntegrationDeployment" + "::" + hashCode();
--
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
13 years, 6 months