[JBoss JIRA] (AS7-6246) Naming context read-only during legacy SAR deployment
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-6246?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins updated AS7-6246:
---------------------------------
Component/s: Naming
> Naming context read-only during legacy SAR deployment
> -----------------------------------------------------
>
> Key: AS7-6246
> URL: https://issues.jboss.org/browse/AS7-6246
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX, Naming
> Affects Versions: 7.2.0.Alpha1
> Reporter: Philippe Marschall
> Assignee: Eduardo Martins
> Labels: jmx, jndi, naming, sar
>
> When the {{#startService()}} and {{#stopService()}} methods of a sublass of {{ServiceMBeanSupport}} are invoked the JNDI context is read only.
> Consider the following MBean:
> {code}
> public class LegacySample extends ServiceMBeanSupport implements LegacySampleMBean {
> private static final String NAME = "java:global/env/foo/legacy";
> private static final String VALUE = "BAR";
> private static final Logger LOG = Logger.getLogger("sar-legacy");
> public LegacySample() {
> super();
> }
> @Override
> protected void startService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.rebind(NAME, VALUE);
> LOG.info("started");
> }
> @Override
> protected void stopService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.unbind(NAME);
> LOG.info("stopped");
> }
> @Override
> public String getMessage() {
> return "legacy";
> }
> }
> {code}
> This will fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-5781) Filesystem deployment scanner for a managed domain
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5781?page=com.atlassian.jira.plugin.s... ]
SBS JIRA Integration updated AS7-5781:
--------------------------------------
Forum Reference: https://community.jboss.org/message/783928#783928
> Filesystem deployment scanner for a managed domain
> --------------------------------------------------
>
> Key: AS7-5781
> URL: https://issues.jboss.org/browse/AS7-5781
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 7.1.0.Final
> Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final
> Reporter: hitesh yadav
> Original Estimate: 1 day, 4 hours
> Remaining Estimate: 1 day, 4 hours
>
> Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node.
> For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group .....
> Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group .............
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6248) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Michael Van Geertruy (JIRA)
[ https://issues.jboss.org/browse/AS7-6248?page=com.atlassian.jira.plugin.s... ]
Michael Van Geertruy edited comment on AS7-6248 at 12/23/12 4:44 AM:
---------------------------------------------------------------------
This file is created by the spec-api module, which is built much later in the build process. The way I see it, there are two possible solutions:
1) Move the arquillian modules to after the spec-api module (destructive), or
2) Create a module specifically for arquillian-testng at a peer level to spec-api in the source-tree and move the contents of arquillian-testng to the new module. In the project's parent pom.xml, create an entry for arquillian-testng immediately after spec-api in the modules section.
The only other module that has a dependency on jboss-as-arquillian-testng-integration is test-suite which runs after spec-api. Also, all of the other Arquillian modules build fine, and there are numerous dependencies on the other arquillian modules in the build process. With this in mind, I think option 2 is probably best.
I can implement whichever solution you folks would like and submit a patch after a decision is made.
The only reason I found this was because I started the build with a blank .m2/repository. If Jenkins isn't clearing out the .m2/repository prior to the build that then this would have only shown up the first time a build was done. After that, the file produced by spec-api would be installed into the repository and the problem would have gone away.
was (Author: mikevan):
This file is created by the spec-api module, which is built much later in the build process. The way I see it, there are two possible solutions:
1) Move the arquillian modules to after the spec-api module.
2) Create a module specifically for arquillian-testng at a peer level to spec-api in the source-tree and move the contents of arquillian-testng to the new module. In the project's parent pom.xml, create an entry for arquillian-testng immediately after spec-api in the modules section.
The only other module that has a dependency on jboss-as-arquillian-testng-integration is test-suite which runs after spec-api. Also, all of the other Arquillian modules build fine, and there are numerous dependencies on the other arquillian modules in the build process. With this in mind, I think option 2 is probably best.
I can implement whichever solution you folks would like and submit a patch after a decision is made.
The only reason I found this was because I started the build with a blank .m2/repository. If Jenkins isn't clearing out the .m2/repository prior to the build that then this would have only shown up the first time a build was done. After that, the file produced by spec-api would be installed into the repository and the problem would have gone away.
> Missing file from Nexus preventing build of Arquillian TestNG Integration
> -------------------------------------------------------------------------
>
> Key: AS7-6248
> URL: https://issues.jboss.org/browse/AS7-6248
> Project: Application Server 7
> Issue Type: Bug
> Components: Build System
> Affects Versions: 7.2.0.Alpha1
> Environment: CentOS 6.3, Intel X86-64
> Reporter: Michael Van Geertruy
> Assignee: Paul Gier
> Labels: Arquillian
>
> After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> [WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
> [INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
> [INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
> [INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
> [INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
> [INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
> [INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
> [INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
> [INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
> [INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
> [INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1:08.150s
> [INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
> [INFO] Final Memory: 51M/317M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
> Indeed after looking at the jboss nexus repository I came across this link:
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
> There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6248) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Michael Van Geertruy (JIRA)
[ https://issues.jboss.org/browse/AS7-6248?page=com.atlassian.jira.plugin.s... ]
Michael Van Geertruy commented on AS7-6248:
-------------------------------------------
This file is created by the spec-api module, which is built much later in the build process. The way I see it, there are two possible solutions:
1) Move the arquillian modules to after the spec-api module.
2) Create a module specifically for arquillian-testng at a peer level to spec-api in the source-tree and move the contents of arquillian-testng to the new module. In the project's parent pom.xml, create an entry for arquillian-testng immediately after spec-api in the modules section.
The only other module that has a dependency on jboss-as-arquillian-testng-integration is test-suite which runs after spec-api. Also, all of the other Arquillian modules build fine, and there are numerous dependencies on the other arquillian modules in the build process. With this in mind, I think option 2 is probably best.
I can implement whichever solution you folks would like and submit a patch after a decision is made.
The only reason I found this was because I started the build with a blank .m2/repository. If Jenkins isn't clearing out the .m2/repository prior to the build that then this would have only shown up the first time a build was done. After that, the file produced by spec-api would be installed into the repository and the problem would have gone away.
> Missing file from Nexus preventing build of Arquillian TestNG Integration
> -------------------------------------------------------------------------
>
> Key: AS7-6248
> URL: https://issues.jboss.org/browse/AS7-6248
> Project: Application Server 7
> Issue Type: Bug
> Components: Build System
> Affects Versions: 7.2.0.Alpha1
> Environment: CentOS 6.3, Intel X86-64
> Reporter: Michael Van Geertruy
> Assignee: Paul Gier
> Labels: Arquillian
>
> After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> [WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
> [INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
> [INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
> [INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
> [INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
> [INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
> [INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
> [INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
> [INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
> [INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
> [INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1:08.150s
> [INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
> [INFO] Final Memory: 51M/317M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
> Indeed after looking at the jboss nexus repository I came across this link:
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
> There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6248) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Michael Van Geertruy (JIRA)
Michael Van Geertruy created AS7-6248:
-----------------------------------------
Summary: Missing file from Nexus preventing build of Arquillian TestNG Integration
Key: AS7-6248
URL: https://issues.jboss.org/browse/AS7-6248
Project: Application Server 7
Issue Type: Bug
Components: Build System
Affects Versions: 7.2.0.Alpha1
Environment: CentOS 6.3, Intel X86-64
Reporter: Michael Van Geertruy
Assignee: Paul Gier
After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
[INFO] ------------------------------------------------------------------------
[INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
[WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
[INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
[INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
[INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
[INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
[INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
[INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
[INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
[INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
[INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
[INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:08.150s
[INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
[INFO] Final Memory: 51M/317M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
Indeed after looking at the jboss nexus repository I came across this link:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-5871) The default redirect port for the 8080 connector is current 8433. Should be 8443 instead.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5871?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5871:
----------------------------------
Fix Version/s: 7.2.0.Alpha1
> The default redirect port for the 8080 connector is current 8433. Should be 8443 instead.
> ------------------------------------------------------------------------------------------
>
> Key: AS7-5871
> URL: https://issues.jboss.org/browse/AS7-5871
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Fix For: 7.2.0.Alpha1
>
>
> The default redirect port for the 8080 connector is 8433. Seems that this is wrong as socket-bindings use 8443 (and former releases also)
> [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource
> {
> "outcome" => "success",
> "result" => {
> ...,
> "name" => "http",
> "protocol" => "HTTP/1.1",
> "redirect-port" => 8433,
> "scheme" => "http",
> "secure" => false,
> "socket-binding" => "http",
> "ssl" => undefined,
> "virtual-server" => undefined
> }
> }
> The pre-configured "https" socket binding conversely is 8443:
> [standalone@localhost:9999 socket-binding=https] /socket-binding-group=standard-sockets/socket-binding=https:read-resource
> {
> "outcome" => "success",
> "result" => {
> "client-mappings" => undefined,
> "fixed-port" => false,
> "interface" => undefined,
> "multicast-address" => undefined,
> "multicast-port" => undefined,
> "name" => "https",
> "port" => 8443
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JGRP-1558) Discovery: don't suppress response when merging for non-merge triggered discovery requests
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1558?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1558:
--------------------------------
Another change we could make is to return only the physical address (and logical name) of X when a GET_PHYSICAL_ADDR event is received in Discovery. Currently, this results in a multicast GET_MBRS_REQ to which every node responds with a GET_MBRS_RSP including its own physical address. This should be changed to have only members who actually have the physical address for X respond to the original sender.
Perhaps a new header request type ?
> Discovery: don't suppress response when merging for non-merge triggered discovery requests
> ------------------------------------------------------------------------------------------
>
> Key: JGRP-1558
> URL: https://issues.jboss.org/browse/JGRP-1558
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> In Discovery, when receiving a discovery request, we discard it if a merge is running (isMergeRunning()). The condition should be moved into the if-clause above (hdr.view_id != null), as it only applies to merge-triggered discoveries. When handling a regular discovery, e.g. at startup or when a physical address is looked up, a discovery response should be sent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JGRP-1558) Discovery: don't suppress response when merging for non-merge triggered discovery requests
by Bela Ban (JIRA)
Bela Ban created JGRP-1558:
------------------------------
Summary: Discovery: don't suppress response when merging for non-merge triggered discovery requests
Key: JGRP-1558
URL: https://issues.jboss.org/browse/JGRP-1558
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
In Discovery, when receiving a discovery request, we discard it if a merge is running (isMergeRunning()). The condition should be moved into the if-clause above (hdr.view_id != null), as it only applies to merge-triggered discoveries. When handling a regular discovery, e.g. at startup or when a physical address is looked up, a discovery response should be sent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JASSIST-189) Bridge methods are proxied instead of desired methods
by Donnchadh Ó Donnabháin (JIRA)
[ https://issues.jboss.org/browse/JASSIST-189?page=com.atlassian.jira.plugi... ]
Donnchadh Ó Donnabháin commented on JASSIST-189:
------------------------------------------------
The following patch seems to fix the problem for us:
{noformat}
Index: src/main/javassist/util/proxy/ProxyFactory.java
===================================================================
--- src/main/javassist/util/proxy/ProxyFactory.java (revision 698)
+++ src/main/javassist/util/proxy/ProxyFactory.java (working copy)
@@ -1123,6 +1123,9 @@
// we tried to overwrite a public definition with a non-public definition,
// use the old definition instead.
hash.put(key, oldMethod);
+ } else if (null != oldMethod && !oldMethod.isBridge() && methods[i].isBridge()
+ && oldMethod.getDeclaringClass() == methods[i].getDeclaringClass()) {
+ hash.put(key, oldMethod);
}
}
}
{noformat}
> Bridge methods are proxied instead of desired methods
> -----------------------------------------------------
>
> Key: JASSIST-189
> URL: https://issues.jboss.org/browse/JASSIST-189
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: OS X, Java 1.7.0_09
> Reporter: Donnchadh Ó Donnabháin
> Assignee: Shigeru Chiba
>
> The following test intermittently fails:
> {code}
> package org.javassist.test.covariantproxy;
> import java.lang.reflect.Method;
> import javassist.util.proxy.MethodHandler;
> import javassist.util.proxy.ProxyFactory;
> import javassist.util.proxy.ProxyObject;
> import junit.framework.TestCase;
> public class CovariantProxyTest extends TestCase {
>
> public interface TestProxy {
>
> }
>
> public static class TestMethodHandler implements MethodHandler {
>
> boolean invoked = false;
> public Object invoke(Object self, Method thisMethod, Method proceed, Object[] args) throws Throwable {
> invoked = true;
> return proceed.invoke(self, args);
> }
>
> public boolean wasInvoked() {
> return invoked;
> }
> public void reset() {
> invoked = false;
> }
> }
> public static class Issue {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
> }
>
> public static class PublishedIssue extends Issue {
>
> }
> public static abstract class Article {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
>
> public abstract Issue getIssue();
> }
> public static class PublishedArticle extends Article {
>
> private PublishedIssue issue;
>
> @Override
> public PublishedIssue getIssue() {
> return issue;
> }
>
> public void setIssue(PublishedIssue issue) {
> this.issue = issue;
> }
>
> }
>
> public void testThatCallingAMethodWithCovariantReturnTypeCallsProxy() throws Exception {
> Class persistentClass = PublishedArticle.class;
> ProxyFactory factory = new ProxyFactory();
> factory.setUseCache(false);
> factory.setSuperclass(persistentClass);
> factory.setInterfaces(new Class[] {TestProxy.class});
> Class cl = factory.createClass();
> TestProxy proxy = ( TestProxy ) cl.newInstance();
> TestMethodHandler methodHandler = new TestMethodHandler();
> ( ( ProxyObject ) proxy ).setHandler( methodHandler );
>
> ((Article)proxy).getIssue();
> assertTrue(methodHandler.wasInvoked());
>
> methodHandler.reset();
>
> PublishedArticle article = (PublishedArticle) proxy;
>
> article.getIssue();
>
> assertTrue(methodHandler.wasInvoked());
>
> }
>
> }
> {code}
> Were there tests added for JASSIST-24 ? I don't see any associated source.
> This bug causes a problem in hibernate, described in https://hibernate.onjira.com/browse/HHH-7884 .
> This may be related to JASSIST-162 but the circumstances are slightly different.
> The problem occurs intermittently so it appears to depend on the order in which the methods are processed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6246) Naming context read-only during legacy SAR deployment
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-6246?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins reassigned AS7-6246:
------------------------------------
Assignee: Eduardo Martins (was: Stuart Douglas)
> Naming context read-only during legacy SAR deployment
> -----------------------------------------------------
>
> Key: AS7-6246
> URL: https://issues.jboss.org/browse/AS7-6246
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.2.0.Alpha1
> Reporter: Philippe Marschall
> Assignee: Eduardo Martins
> Labels: jmx, jndi, naming, sar
>
> When the {{#startService()}} and {{#stopService()}} methods of a sublass of {{ServiceMBeanSupport}} are invoked the JNDI context is read only.
> Consider the following MBean:
> {code}
> public class LegacySample extends ServiceMBeanSupport implements LegacySampleMBean {
> private static final String NAME = "java:global/env/foo/legacy";
> private static final String VALUE = "BAR";
> private static final Logger LOG = Logger.getLogger("sar-legacy");
> public LegacySample() {
> super();
> }
> @Override
> protected void startService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.rebind(NAME, VALUE);
> LOG.info("started");
> }
> @Override
> protected void stopService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.unbind(NAME);
> LOG.info("stopped");
> }
> @Override
> public String getMessage() {
> return "legacy";
> }
> }
> {code}
> This will fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months