[JBoss JIRA] (JBIDE-13446) Forge pick-up command throws NPE on Mac
by Martin Malina (JIRA)
Martin Malina created JBIDE-13446:
-------------------------------------
Summary: Forge pick-up command throws NPE on Mac
Key: JBIDE-13446
URL: https://issues.jboss.org/browse/JBIDE-13446
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: forge
Affects Versions: 4.0.0.Final, 4.1.0.Alpha1
Environment: OS X Mountain Lion
Apple JDK 1.6 32bit
JBDS 6.0.0.GA / JBT master nightly 4.1.0.Alpha1-v20130129-1449-B6053 on Eclipse Kepler M4
Reporter: Martin Malina
Assignee: Koen Aers
Fix For: 4.0.1.Final, 4.1.x
When playing around w/ Ticket Monster [1] I found out that Show in -> Forge console does not work for me on a project or directory in Project Explorer.
It throws this exception:
{code}
[no project] workspace $ set VERBOSE true
[no project] workspace $ pick-up /Users/rasp/jbossqa/JBDS/nightly-jbt-2013-01-30/workspace/jboss-javaee6-webapp
java.lang.NullPointerException***ERROR*** Exception encountered: (type "set VERBOSE false" to disable stack traces)
[no project] workspace $
at org.apache.maven.RepositoryUtils.getLayout(RepositoryUtils.java:214)
at org.apache.maven.RepositoryUtils.toRepo(RepositoryUtils.java:200)
at org.apache.maven.RepositoryUtils.toRepos(RepositoryUtils.java:190)
at org.apache.maven.project.DefaultProjectBuilder$InternalConfig.<init>(DefaultProjectBuilder.java:662)
at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:102)
at org.jboss.forge.maven.facets.MavenCoreFacetImpl.getPartialProjectBuildingResult(MavenCoreFacetImpl.java:86)
at org.jboss.forge.maven.facets.MavenCoreFacetImpl.resolveProperties(MavenCoreFacetImpl.java:304)
at org.jboss.forge.maven.facets.MavenDependencyFacet.resolveProperties(MavenDependencyFacet.java:393)
at org.jboss.forge.maven.facets.MavenDependencyFacet.hasEffectiveDependency(MavenDependencyFacet.java:171)
at org.jboss.forge.shell.project.DependencyInstallerImpl.isInstalled(DependencyInstallerImpl.java:170)
at org.jboss.forge.git.GitAPIFacet.isInstalled(GitAPIFacet.java:42)
at org.jboss.forge.project.BaseProject.registerFacet(BaseProject.java:153)
at org.jboss.forge.project.services.ProjectFactory.registerSingleFacet(ProjectFactory.java:208)
at org.jboss.forge.project.services.ProjectFactory.registerSingleFacet(ProjectFactory.java:186)
at org.jboss.forge.project.services.ProjectFactory.registerFacets(ProjectFactory.java:178)
at org.jboss.forge.project.services.ProjectFactory.findProjectRecursively(ProjectFactory.java:117)
at org.jboss.forge.shell.project.ProjectInitializer.doInit(ProjectInitializer.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:628)
at org.jboss.weld.event.EventImpl.fire(EventImpl.java:75)
at org.jboss.forge.shell.project.CurrentProject.setCurrentResource(CurrentProject.java:80)
at org.jboss.forge.shell.ShellImpl.setCurrentResource(ShellImpl.java:1239)
at org.jboss.forge.shell.ShellImpl$Proxy$_$$_WeldClientProxy.setCurrentResource(ShellImpl$Proxy$_$$_WeldClientProxy.java)
at org.jboss.forge.shell.plugins.builtin.PickupResourcePlugin.run(PickupResourcePlugin.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.forge.shell.command.Execution.perform(Execution.java:134)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:109)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:47)
at org.jboss.forge.shell.ShellImpl$ExecutorThread.run(ShellImpl.java:818)
at org.jboss.forge.shell.ShellImpl.execute(ShellImpl.java:841)
at org.jboss.forge.shell.ShellImpl.doShell(ShellImpl.java:631)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
at org.jboss.forge.shell.ShellImpl$Proxy$_$$_WeldClientProxy.doShell(ShellImpl$Proxy$_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
at org.jboss.forge.shell.Bootstrap$1.run(Bootstrap.java:172)
at java.lang.Thread.run(Thread.java:722)
{code}
This happens in both JBDS 6 and JBT 4.1 nightly, but not in JBDS 5. It's probably only reproducible on Mac - psrna verified this on Linux today and it worked for him. I tried two different instances of JBDS 6 and one instance of JBT 4.1.0.Alpha1 nightly installed on Eclipse Kepler M4.
Please let me know if I should create a FORGE issue.
The forge runtime versions:
JBDS 6: org.jboss.tools.forge.runtime_1.1.0.Final-v20121205-1934-B69
JBT nightly: org.jboss.tools.forge.runtime_1.2.0.Alpha1-v20130128-1407-B204
[1] http://www.jboss.org/jdf/examples/ticket-monster/tutorial/Introduction/#_...
--
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, 2 months
[JBoss JIRA] (JBIDE-10777) Use Sonar for Code Quality Analysis
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-10777?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-10777:
---------------------------------------------
Any ETA Sonar reports being available from the outside ?
> Use Sonar for Code Quality Analysis
> -----------------------------------
>
> Key: JBIDE-10777
> URL: https://issues.jboss.org/browse/JBIDE-10777
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: Build/Releng
> Affects Versions: 3.1.2
> Environment: any
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Priority: Minor
> Fix For: LATER
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Sonar provides a very powerful tool to get report about tests, code coverage, and static analysis in a project (errors, duplications...). It is easy to use, there is a nice integration with Maven and Hudson/Jenkins. It provides reporting tools for everything existing in the Java world, and more.
> Adding Sonar to Hudson really helps to make code better.
> http://www.sonarsource.org/
--
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, 2 months
[JBoss JIRA] (JBIDE-13438) jboss-packaging-maven-plugin jboss-esb + m2e
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13438?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-13438:
-------------------------------------
Brian, FYI, the jboss-packaging-maven-plugin integration[1] that exists in JBoss Tools Maven currently only covers SAR (jboss-sar) projects [2].
Supporting jboss-esb was something I wanted to add initially, but that requires adding dependencies to the JBoss Tools ESB features (to get the ESB Facet and so on). So eventually the existing org.jboss.tools.maven.jbosspackaging feature would need to be broken down to several pieces or most probably expose an API to handle the org.codehaus.mojo:jboss-packaging-maven-plugin configuration, consumed by an m2e-esb configurator (living under the SOA tooling).
[1] https://github.com/jbosstools/jbosstools-central/tree/master/maven/plugin...
[2] http://docs.jboss.org/tools/whatsnew/maven/maven-news-3.3.0.M3.html
> jboss-packaging-maven-plugin jboss-esb + m2e
> --------------------------------------------
>
> Key: JBIDE-13438
> URL: https://issues.jboss.org/browse/JBIDE-13438
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: esb, maven
> Reporter: Manosh C
> Assignee: Brian Fitzpatrick
> Attachments: testparent.zip
>
>
> Hi,
>
> Does jboss-packaging-maven-plugin m2e connector work for jboss-esb? When I import a maven jboss-esb project into eclipse (m2e installed), it does not covert it into an Eclipse JBoss ESB (facet is not enabled and dependecies are not set) project. I tried almost all versions of eclipse, m2e, jboss tools and jboss soa tools, to make it work, but no use. This is my work around for now
>
> 1. Turn on facet nature and enable JBOSS ESB nature.
> 2. Then it get recognized as a deployable artifact on JBoss server.
> 3. Manually add all dependencies in "Deployment and Assembly section".
>
> What I was expecting was all steps should have been done by m2e jboss esb (jboss-packaging-maven-plugin) connector. I could not find a relevant post or article related to it. Does this feature ever supported?
>
> Thank you in advance.
> Manosh
--
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, 2 months
[JBoss JIRA] (JBIDE-13438) jboss-packaging-maven-plugin jboss-esb + m2e
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13438?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-13438:
--------------------------------
Component/s: maven
> jboss-packaging-maven-plugin jboss-esb + m2e
> --------------------------------------------
>
> Key: JBIDE-13438
> URL: https://issues.jboss.org/browse/JBIDE-13438
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: esb, maven
> Reporter: Manosh C
> Assignee: Brian Fitzpatrick
> Attachments: testparent.zip
>
>
> Hi,
>
> Does jboss-packaging-maven-plugin m2e connector work for jboss-esb? When I import a maven jboss-esb project into eclipse (m2e installed), it does not covert it into an Eclipse JBoss ESB (facet is not enabled and dependecies are not set) project. I tried almost all versions of eclipse, m2e, jboss tools and jboss soa tools, to make it work, but no use. This is my work around for now
>
> 1. Turn on facet nature and enable JBOSS ESB nature.
> 2. Then it get recognized as a deployable artifact on JBoss server.
> 3. Manually add all dependencies in "Deployment and Assembly section".
>
> What I was expecting was all steps should have been done by m2e jboss esb (jboss-packaging-maven-plugin) connector. I could not find a relevant post or article related to it. Does this feature ever supported?
>
> Thank you in advance.
> Manosh
--
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, 2 months
[JBoss JIRA] (JBIDE-13438) jboss-packaging-maven-plugin jboss-esb + m2e
by Nick Tan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13438?page=com.atlassian.jira.plugi... ]
Nick Tan commented on JBIDE-13438:
----------------------------------
+1 for this feature
my current workaround is using maven-eclipse-plugin to generate the eclipse project configuration files.
but maven-eclipse-plugin is not compatible with m2e itself
> jboss-packaging-maven-plugin jboss-esb + m2e
> --------------------------------------------
>
> Key: JBIDE-13438
> URL: https://issues.jboss.org/browse/JBIDE-13438
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: esb
> Reporter: Manosh C
> Assignee: Brian Fitzpatrick
> Attachments: testparent.zip
>
>
> Hi,
>
> Does jboss-packaging-maven-plugin m2e connector work for jboss-esb? When I import a maven jboss-esb project into eclipse (m2e installed), it does not covert it into an Eclipse JBoss ESB (facet is not enabled and dependecies are not set) project. I tried almost all versions of eclipse, m2e, jboss tools and jboss soa tools, to make it work, but no use. This is my work around for now
>
> 1. Turn on facet nature and enable JBOSS ESB nature.
> 2. Then it get recognized as a deployable artifact on JBoss server.
> 3. Manually add all dependencies in "Deployment and Assembly section".
>
> What I was expecting was all steps should have been done by m2e jboss esb (jboss-packaging-maven-plugin) connector. I could not find a relevant post or article related to it. Does this feature ever supported?
>
> Thank you in advance.
> Manosh
--
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, 2 months
[JBoss JIRA] (JBIDE-13445) Enable possibility of deployment scanner additions for remote servers
by Rob Stryker (JIRA)
Rob Stryker created JBIDE-13445:
-----------------------------------
Summary: Enable possibility of deployment scanner additions for remote servers
Key: JBIDE-13445
URL: https://issues.jboss.org/browse/JBIDE-13445
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: JBossAS/Servers
Affects Versions: 4.1.0.Alpha1
Reporter: Rob Stryker
Assignee: Rob Stryker
Fix For: 4.1.0.Alpha1
Currently, additions tot he deployment scanners are limited to locally running servers. This is due to a lack of API allowing accurate discovery of what folders need to be added for remote servers, specifically no way for as.core classes to discover what the remote server home is, what the remote configuration folder is, etc. There is a lack of api here, and that will need to be fixed before this issue can work.
Remember: If a remote server is not running with its management ports exposed, do not attempt to add the scanners, as the management connections 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, 2 months
[JBoss JIRA] (JBIDE-13444) deployment scanner additions should be called from behavior
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13444?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-13444.
---------------------------------
Resolution: Done
This is in master now. One other effect of this is that the startup activators do not need to add these global listeners, which also helps our other goal of moving logic out of our activators and into more reasonable locations.
> deployment scanner additions should be called from behavior
> -----------------------------------------------------------
>
> Key: JBIDE-13444
> URL: https://issues.jboss.org/browse/JBIDE-13444
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: JBossAS/Servers
> Affects Versions: 4.0.0.Final
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.1.0.Alpha1
>
>
> The classes in charge of adding deployment scanners to a running server are currently responding to the wtp framework's alert that the server has started. In this way, they are listeners, listening to every server event, and choosing to only respond to events where a server is set to 'started'.
> This is not the best solution and is a little un-intuitive. It would be more reasonable if the behavior (or its delegate) initiated this activity rather than going through the framework listeners.
> Luckily, almost the API already exists to move these classes solely into as.core. as.core already has an extension point to locate a jmx runner from the as.jmx.integration code and has used it in the past to suspend deployment scanners and resume them during a publish event.
> The class handling as7 via management also exists in as.core (or at least the method to FIND the management does), and so this requires no large changes.
> Tasks:
> 1) Move the JMX deployment scanner additions into as.core
> 2) Modify both jmx and as7's deployment scanner listeners to no longer be listeners, and make them accessible via the ServerExtendedPRoperties internal api.
> 3) Ensure the behaviors or their delegates call this once they set the server to started.
--
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, 2 months
[JBoss JIRA] (JBIDE-13444) deployment scanner additions should be called from behavior
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13444?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-13444:
-------------------------------------
IF QE wishes to test this, simply ensure that deployments to metadata work for as7, as6, etc. Also note that currently, scanner additions to REMOTE servers are disabled. A new issue will be opened to handle that task.
> deployment scanner additions should be called from behavior
> -----------------------------------------------------------
>
> Key: JBIDE-13444
> URL: https://issues.jboss.org/browse/JBIDE-13444
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: JBossAS/Servers
> Affects Versions: 4.0.0.Final
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.1.0.Alpha1
>
>
> The classes in charge of adding deployment scanners to a running server are currently responding to the wtp framework's alert that the server has started. In this way, they are listeners, listening to every server event, and choosing to only respond to events where a server is set to 'started'.
> This is not the best solution and is a little un-intuitive. It would be more reasonable if the behavior (or its delegate) initiated this activity rather than going through the framework listeners.
> Luckily, almost the API already exists to move these classes solely into as.core. as.core already has an extension point to locate a jmx runner from the as.jmx.integration code and has used it in the past to suspend deployment scanners and resume them during a publish event.
> The class handling as7 via management also exists in as.core (or at least the method to FIND the management does), and so this requires no large changes.
> Tasks:
> 1) Move the JMX deployment scanner additions into as.core
> 2) Modify both jmx and as7's deployment scanner listeners to no longer be listeners, and make them accessible via the ServerExtendedPRoperties internal api.
> 3) Ensure the behaviors or their delegates call this once they set the server to started.
--
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, 2 months
[JBoss JIRA] (JBIDE-12913) Startup/Shutdown Pollers fails with EAP511
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12913?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-12913:
-------------------------------------
Jesper:
This dialog only shows up if the poller recognizes something on the 'web port'. The web port is set in your server editor, so if you have some other value other than 8080 there, then that's where its polling.
The three pollers are pretty hard (almost impossible) to trick into believing there's a running server when there isn't. The web poller makes a simple web connection to your server's hostname (set in the server editor's "host" section) at the web port (set int he server editor).
Typically we do not set the host to 0.0.0.0. If you want to bind to all ports, your hostname should remain 'localhost' but you should check the "Listen on all interfaces to allow remote web connections" checkbox. This ensures that your server editor still says your host is localhost, but when launched, jboss will receive the -b 0.0.0.0 flags.
I suppose I haven't tested this in the situation of a server who's HOSTNAME is 0.0.0.0, but this should not be done.
See if this makes a difference for you.
> Startup/Shutdown Pollers fails with EAP511
> ------------------------------------------
>
> Key: JBIDE-12913
> URL: https://issues.jboss.org/browse/JBIDE-12913
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JBossAS/Servers
> Affects Versions: 4.0.0.Alpha2
> Environment: Windows XP
> Reporter: Jesper Skov
> Assignee: Rob Stryker
> Fix For: 4.0.0.Beta2
>
> Attachments: server-startup-poller-problem.png
>
>
> When we use Web Port Startup Poller with EAP511, the server is not started.
> We get an error about the port (8080) already being in use. Which it is not (confirmed with netstat).
> When changing Startup Poller to JMX, the server starts as expected.
> When using the JMX Shutdown Poller, it also fails. This time with failed attempts to access the JMX server after the server has shut down:
> Exception in thread "main" javax.naming.CommunicationException: Could not obtain connection to any of these urls: 0.0.0.0:1099 [Root exception is javax.naming.CommunicationException: Failed to connect to server /0.0.0.0:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server /0.0.0.0:1099 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1763)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:693)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> at javax.naming.InitialContext.lookup(Unknown Source)
> at org.jboss.Shutdown.main(Shutdown.java:219)
> Caused by: javax.naming.CommunicationException: Failed to connect to server /0.0.0.0:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server /0.0.0.0:1099 [Root exception is java.net.ConnectException: Connection refused: connect]]
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:335)
> at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1734)
> ... 4 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server /0.0.0.0:1099 [Root exception is java.net.ConnectException: Connection refused: connect]
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:305)
> ... 5 more
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:97)
> at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:82)
> at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:301)
> ... 5 more
> Using Process Terminated Poller works as expected though.
--
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, 2 months