[JBoss JIRA] (WFLY-2785) master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.... ]
Aleksandar Kostadinov reassigned WFLY-2785:
-------------------------------------------
Assignee: Emanuel Muckenhuber (was: Jason Greene)
Emanuel, could you please take a look at this change?
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2785
> URL: https://issues.jboss.org/browse/WFLY-2785
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.CR1
> Environment: windows
> Reporter: Aleksandar Kostadinov
> Assignee: Emanuel Muckenhuber
> Labels: addressing, domain, socket
> Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>
> import java.io.IOException;
> import java.io.OutputStream;
> -import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.util.Collections;
> import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
> public boolean execute(ManagedServer server) throws Exception {
> assert Thread.holdsLock(ManagedServer.this); // Call under lock
> // Reconnect
> - final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> + final String hostName = managementSocket.getHostString();
> final int port = managementSocket.getPort();
> processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
> return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a05...] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2785) master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.... ]
Aleksandar Kostadinov updated WFLY-2785:
----------------------------------------
Comment: was deleted
(was: want to run a few tests before I file a PR)
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2785
> URL: https://issues.jboss.org/browse/WFLY-2785
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.CR1
> Environment: windows
> Reporter: Aleksandar Kostadinov
> Assignee: Jason Greene
> Labels: addressing, domain, socket
> Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>
> import java.io.IOException;
> import java.io.OutputStream;
> -import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.util.Collections;
> import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
> public boolean execute(ManagedServer server) throws Exception {
> assert Thread.holdsLock(ManagedServer.this); // Call under lock
> // Reconnect
> - final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> + final String hostName = managementSocket.getHostString();
> final int port = managementSocket.getPort();
> processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
> return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a05...] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2785) master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.... ]
Aleksandar Kostadinov updated WFLY-2785:
----------------------------------------
Assignee: Jason Greene (was: Aleksandar Kostadinov)
Git Pull Request: https://github.com/wildfly/wildfly/pull/5813
I'm adding a pull request. As far as I could test, the change fixes the problem on reload when IP and reverse DNS entry do not match.
There was also another problem to this that affected the test suite. Remoting also did a reverse lookup but it is a separate issue and I filed a PR for it as well (REM3-180). Hopefully wildfly will pick it from remoting 4.1.0. So in summary to get a good test run on windows with IPs without reverse DNS entries, one needs to use patched remoting in addition. There is no problem to run the TS on IPs with valid records with either change.
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2785
> URL: https://issues.jboss.org/browse/WFLY-2785
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.CR1
> Environment: windows
> Reporter: Aleksandar Kostadinov
> Assignee: Jason Greene
> Labels: addressing, domain, socket
> Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>
> import java.io.IOException;
> import java.io.OutputStream;
> -import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.util.Collections;
> import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
> public boolean execute(ManagedServer server) throws Exception {
> assert Thread.holdsLock(ManagedServer.this); // Call under lock
> // Reconnect
> - final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> + final String hostName = managementSocket.getHostString();
> final int port = managementSocket.getPort();
> processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
> return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a05...] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2785) master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.... ]
Aleksandar Kostadinov updated WFLY-2785:
----------------------------------------
Comment: was deleted
(was: This change seems to break test suite for wildfly, it was good for EAP. I'll have to find out the cause of this.)
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2785
> URL: https://issues.jboss.org/browse/WFLY-2785
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.CR1
> Environment: windows
> Reporter: Aleksandar Kostadinov
> Assignee: Jason Greene
> Labels: addressing, domain, socket
> Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>
> import java.io.IOException;
> import java.io.OutputStream;
> -import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.util.Collections;
> import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
> public boolean execute(ManagedServer server) throws Exception {
> assert Thread.holdsLock(ManagedServer.this); // Call under lock
> // Reconnect
> - final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> + final String hostName = managementSocket.getHostString();
> final int port = managementSocket.getPort();
> processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
> return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a05...] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2198) Remote Naming throws the same exception for different causes
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.... ]
Brad Maxwell commented on WFLY-2198:
------------------------------------
Resolved in jboss-remote-naming 2.0.0.Final and 1.0.8.Final
> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
> Key: WFLY-2198
> URL: https://issues.jboss.org/browse/WFLY-2198
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception.
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
--
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
12 years, 3 months
[JBoss JIRA] (HIBERNATE-18) Problem when path containing the project is too long
by mary pablate (JIRA)
[ https://issues.jboss.org/browse/HIBERNATE-18?page=com.atlassian.jira.plug... ]
mary pablate commented on HIBERNATE-18:
---------------------------------------
Well, you can use Long Path Tool for such issues, it works good.
> Problem when path containing the project is too long
> ----------------------------------------------------
>
> Key: HIBERNATE-18
> URL: https://issues.jboss.org/browse/HIBERNATE-18
> Project: Hibernate Integration
> Issue Type: Bug
> Environment: Eclipse 3.1
> Embeddable EJB 3.0
> Example: microcontainer-deployment
> Reporter: Doink06 Doink06
> Assignee: Gavin King
>
> Hello,
> I have the following configuration:
> - an eclipse workspace, which contains all the examples extrated from "Embeddable EJB 3.0"
> - Each example is transformed into a java project
> - a special project named Jboss is containing Embeddable EJB 3.0 with subdirectories lib/ and conf/
> Case #1
> The workspace is located on my disk at the following place : "D:/EJB3Examples"
> The example microcontainer-deployment is working perfectly
> Case #2
> I moved the workspace to the following place : "D:/Projects/Java/Eclipse3/EJB3Examples"
> The example microcontainer-deployment is crashing.
> WARN 30-08 01:02:38,906 (JBossEntityResolver.java:getLocalEntityName:201) -Entity is not registered, publicId=null systemId=file:/D:/Projects/Java/Eclipse3/EJB3Examples/jboss/conf/bean-deployer_1_0.xsd
> WARN 30-08 01:02:38,953 (SaxJBossXBParser.java:warning:226) -schema_reference.4: Failed to read schema document 'bean-deployer_1_0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>. @ file:/D:/Projects/Java/Eclipse3/EJB3Examples/jboss/conf/embedded-jboss-beans.xml[5,45]
> WARN 30-08 01:02:41,062 (JBossEntityResolver.java:getLocalEntityName:201) -Entity is not registered, publicId=null systemId=file:/D:/Projects/Java/Eclipse3/EJB3Examples/microcontainer-deployment/conf/bean-deployer_1_0.xsd
> WARN 30-08 01:02:41,062 (SaxJBossXBParser.java:warning:226) -schema_reference.4: Failed to read schema document 'bean-deployer_1_0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>. @ file:/D:/Projects/Java/Eclipse3/EJB3Examples/microcontainer-deployment/conf/ejb3-deployment.xml[5,45]
> ERROR 30-08 01:02:45,609 (EjbTimerUtil.java:getTimerService:43) -Unable to initialize timer service
> ----------------------------------------------------------
> Exception in thread "main" javax.ejb.EJBException: null; CausedByException is:
> Unknown entity: org.jboss.tutorial.mcdeploy.Customer
> at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:46)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:70)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:134)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:152)
> at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:60)
> at $Proxy11.createCustomer(Unknown Source)
> at org.jboss.tutorial.mcdeploy.Main.main(Main.java:32)
> java.lang.IllegalArgumentException: Unknown entity: org.jboss.tutorial.mcdeploy.Customer
> at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:133)
> at org.jboss.ejb3.entity.InjectedEntityManager.persist(InjectedEntityManager.java:97)
> at org.jboss.tutorial.mcdeploy.CustomerDAOBean.createCustomer(CustomerDAOBean.java:28)
> 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.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:32)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:66)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:134)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:152)
> at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:60)
> at $Proxy11.createCustomer(Unknown Source)
> at org.jboss.tutorial.mcdeploy.Main.main(Main.java:32)
> Case #3
> I have copied the workspace to the following directory "D:\Projects\EJB3Examples"
> It works fine
> Case #4
> I have copied the workspace to the following directory "D:\Projects\Java\EJB3Examples"
> It works fine
> Case #5
> I have copied the workspace to the following directory "D:\Projects\Java\Eclips3\EJB3Examples"
> Without the "e" for eclips3. It works fine
> Case #5
> As soon as I rename the directory Eclips3 into Eclipse3, it crashes ... ?!?
--
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
12 years, 3 months