[JBoss JIRA] Created: (JBAS-8871) AS7 undeployment doesn't work properly for identically named deployments (with different content)
by Richard Opalka (JIRA)
AS7 undeployment doesn't work properly for identically named deployments (with different content)
-------------------------------------------------------------------------------------------------
Key: JBAS-8871
URL: https://issues.jboss.org/browse/JBAS-8871
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: 7.0.0.Alpha2
Currently DeploymentUndeployHandler.undeploy() calls
controller.setMode(ServiceController.Mode.NEVER)
to "undeploy DU". This causes the following issue:
There's TestA that deploys & undeploys example.war
There's TestB that deploys & undeploys example.war too (but with different content).
The problem is TestB will see TestA example.war content :(
This is because there's still controller (for example.war DU) registered with MSC registry,
and it's started again during the deploy phase. The code that will start it again is
---
final ServiceController<?> controller = serviceRegistry.getService(deploymentUnitServiceName);
if(controller != null) {
controller.setMode(ServiceController.Mode.ACTIVE);
} else {
---
located in DeploymentHandlerUtil.deploy().
The solution to this problem is to call
controller.setMode(ServiceController.Mode.REMOVE) to undeploy DU properly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (LOGTOOL-10) MessageFormat.format is instance method
by Jonathan Halliday (JIRA)
MessageFormat.format is instance method
---------------------------------------
Key: LOGTOOL-10
URL: https://issues.jboss.org/browse/LOGTOOL-10
Project: Log Tool
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.0.0.Beta3
Reporter: Jonathan Halliday
Assignee: David Lloyd
for methods of the form
@Message(id = 1, value = "foo", format = MESSAGE_FORMAT)
public String foobar();
then generated code of the form
String result = MessageFormat.format(((projectCode +"-1:")+ foo$str()));
won't compile as format is an instance method.
MessageLoggerImplementor.createBundleMethod needs patch to differentiate MESSAGE_FORMAT and PRINTF cases?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (JBMETA-330) @Startup annotation and init-on-startup element in ejb-jar.xml aren't merged into metadata correctly
by jaikiran pai (JIRA)
@Startup annotation and init-on-startup element in ejb-jar.xml aren't merged into metadata correctly
----------------------------------------------------------------------------------------------------
Key: JBMETA-330
URL: https://issues.jboss.org/browse/JBMETA-330
Project: JBoss Metadata
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ejb
Affects Versions: jboss-metadata-ejb-2.0.0-alpha-28
Environment: JBoss AS 6.0.0.Final
Reporter: jaikiran pai
Assignee: jaikiran pai
Consider the following bean:
{code}
@Singleton
@Startup
public class StartupBean
{
...
}
{code}
and the corresponding ejb-jar.xml:
{code:xml}
...
<session>
<ejb-name>StartupBean</ejb-name>
<session-type>Singleton</session-type>
<ejb-local-ref>
...
</ejb-local-ref>
</session>
{code}
Notice that the ejb-jar.xml is used to configure some other aspects of the EJB, but it *doesn't* set/override the init-on-startup attribute of the bean. Effectively, the StartupBean should still be considered as a init-on-startup bean.
However, this isn't the case currently. During merging of this annotation and xml metadata, the merged metadata turns up the StartupBean as a normal non init-on-startup bean. See the referenced forum thread for the complete details.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months