headers
David Conde | 1 Jul 08:11
Picon
Favicon

RE: Problem after updating timezone Equinox v3.4

We have tried with other systems, and we have changed the date in order to have the same scenary as we had before, and we have not got any error, maybe it was a error in our systems and not a Equinox fault. I have tried with the version 3.5 and it worked fine, so I am going to try again and if I get again the same error I will open a error.

 

Thank you again

 

David

 

De: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org [mailto:equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org] En nombre de Thomas Watson
Enviado el: martes, 30 de junio de 2009 15:31
Para: Equinox development mailing list
Asunto: RE: [equinox-dev] Problem after updating timezone Equinox v3.4

 

I cannot think of anything that would cause issues with dates. I suggest you open a bug so we can gather the necessary information and track the issue. Have you tried 3.5?

Tom



"David Conde" ---06/30/2009 01:42:15 AM---Hello Tom,


From:


"David Conde" <dconde-fzAlJQVsllk@public.gmane.org>


To:


"'Equinox development mailing list'" <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>


Date:


06/30/2009 01:42 AM


Subject:


RE: [equinox-dev] Problem after updating timezone Equinox v3.4





Hello Tom,

Thank you for your answer, but the problem continues being very rare, because of a workmate of mine, tried yesterday launching Equinox by console in basic mode with the version org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar, and it did not work at all, with the same error and Exception that I got. It is very strange because he did not launch the timezone updater (tzupdater.jar), and he got the same Exception in logFile with the same results.

Finally, today, just a couple of minutes ago, I tried again with the same command  (java -jar org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar –console) and it worked fine, as the same way, my workmate have launched the same command and doing nothing new regarding what it was done yesterday we have got good result and Equinox starting as normal as it did before yesterday.

Could it be a problema with the any dates in Equinox?

David
 
De: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org [mailto:equinox-dev-bounces <at> eclipse.org] En nombre de Thomas Watson
Enviado el: lunes, 29 de junio de 2009 15:48
Para: Equinox development mailing list
Asunto: Re: [equinox-dev] Problem after updating timezone Equinox v3.4

I would expect this error message if you are not specifying the configuration option eclipse.ignoreApp=true

Without this option we are expecting the full eclipse runtime to be active and available to start an eclipse application.

Tom



"David Conde" ---06/29/2009 06:13:41 AM---Hi,


From:


"David Conde" <dconde-fzAlJQVsllk@public.gmane.org>


To:


"'Equinox development mailing list'" <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>


Date:


06/29/2009 06:13 AM


Subject:


[equinox-dev] Problem after updating timezone Equinox v3.4





Hi,

I wrote about this in my previous thread, but I think it is better to write this thread separately to the other one, because of the other one was about PermissionAdmin service having nothing to do with this case:

Trying to launch Equinox v3.4 with security features I got the next exception:

Exception in thread "main" java.lang.NoClassDefFoundError: ûjar

It was very rare because I tried to launch the security command as I did before trying with Equinox v3.3 and Equinox v3.4 (when they working fine)

I was looking for the solution and I tried to update the dates with the timezone update by SUn (-jar tzupdater.jar), following the information which I found in Internet.

After that, I reboot my PC and then I tried to launch Equinox v3.3 without security and with security and worked fine, however, when I tried to launch Equinox v3.4 by console, with either basic or security features, did not work at all, getting the next exception in the logfile:


!ENTRY org.eclipse.osgi 4 0 2009-06-29 12:51:05.562
!MESSAGE Application error
!STACK 1
java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.java:150)


have these problem happen to anyone?


My used commands are as I used before, they were tried and were working fine, so I do not really know what happens now.

BASIC LAUNCHING:

java -jar org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar –console

SECURITY LAUNCHING:

Java -Declipse.security=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager -jar org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar –console



So I do not know what I am missing?

It is very strange case because of I tried with the same commands and I was fine a couple of months ago, so I think it is a problem related to updater and Equinoxv3.4.


Thank you in advance for any idea_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Permalink | Reply | 0 comments |
headers
Murphree, Michael | 2 Jul 00:12
Picon
Favicon

RE: FW: Classloader problem

As a follow up, we have a bit more information about our XML woes in Equinox on J9.  In trying to take the fix-the-manifests approach, we were still left with the problem of the JAXP API classloader design.  When JAXP factories load classes they use the current context classloader to do this.  Without anything else to change it, the thread's current context classloader in Equinox is usually DefaultClassLoader (the OSGi framework-level classloader, I think).  If I understand rightly, this classloader follows the standard parent delegation scheme and delegates to its parent, which would be the URLClassLoader in Equinox Main, whose parent is one of the three JRE classloaders.  J9 does have a bootclasspath override (-Xbootclasspath/p:{your-libraries-here}), which works well on 32-bit Windows, but seems to be ignored on AIX.

 

The net result is we don't have a good way of forcing third party libraries (like Log4J) to get their XML parsing needs taken care of by our bundles of javax.xml, Xerces and Xalan.    Consequently we started to take the approach of making our stack and our code live properly with what's available in the JRE.  In many cases, this is a problem of eliminating the use of convenience methods in the Apache libraries that now have JAXP and JAXB equivalents.  In some cases we've had to patch some of the libraries we use (like Apache Muse) to make this work.  Early results seem promising.

 

Regards,

 

Michael

 

.


The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

Permalink | Reply | 0 comments |
headers
Kirchev, Lazar | 2 Jul 13:39
Picon
Favicon

RE: Huge log file if org.eclipse.equinox.log.jar is not started when trying to start a DS with a reference to an inexisting interface

Hello,
 
Along with the issue, described below, for which I opened a bug (282142), we observed also the following: when this situation occurs, if the bundle org.eclipse.equinox.log.jar is installed but not started, we receive 10 MB of logs - in 10 files, 1 MB each. If the log is started, there is only one small log file with three exceptions. The exceptions in both cases are essentially the same, but in the case with the huge logs the exceptions are repeated many times and the stacktraces are much longer - cycles are observed in the them. Nothing in the stacktraces makes a hint that the problem may be in the log service being stopped.
 
Is this a normal behavior when the log service is not started, or should I open a bug for it?
 
In bug 282142 there are attached sample bundles to reproduce the below described issue. The problem with the logs is reprodueced by following the steps from the bug description, once with the log service started, and once with it stopped.
 
Kind regards,
Lazar
 

From: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org [mailto:equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org] On Behalf Of Kirchev, Lazar
Sent: Tuesday, June 30, 2009 3:12 PM
To: equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
Subject: [equinox-dev] Unclear warning in DS when a service componentprovides inexisting/unimplemented interface

Hello,
 
We are using declarative services and we came across the following situation. There are two components, A and B. A provides an interface and B references this interface. If the interface which A provides does not exist, or is not implemented, when the framework tries to create an instance of component B, a warning that there is probably a circular dependancy is logged. This does not help to find the real problem - that the interface does not exist and there is no such service.
 
In ComponentReference.getMethod(...), if the result of the call InstanceProcess.staticRef.getService(...) is null, then it is assumed that serviceObject cannot be created because of circularity. But InstanceProcess.staticRef.getService(...) returns null both when there is circularity and when the service object cannot be retrieved from the bundle context.
 
Also, if the component state is checked with the component command, it is Satisfied, saying in the dynamic information part that all references of the component are satisfied.
 
Is this the intended behavior of DS?
 
Kind regards,
Lazar Kirchev
Permalink | Reply | 1 comment |
headers
John Arthorne | 2 Jul 20:11
Picon

RE: Huge log file if org.eclipse.equinox.log.jar is not started when trying to start a DS with a reference to an inexisting interface


This doesn't sound like normal behaviour to me. Please enter a bug for this with some samples of the log contents.

John



"Kirchev, Lazar" <l.kirchev-y6kNeMnOB+c@public.gmane.org>
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

07/02/2009 07:39 AM

Please respond to
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
To
 "Equinox development mailing list" <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
cc
Subject
 RE: [equinox-dev] Huge log file if org.eclipse.equinox.log.jar is not        started when trying to start a DS with a reference to an        inexisting interface





Hello,
 
Along with the issue, described below, for which I opened a bug (282142), we observed also the following: when this situation occurs, if the bundle org.eclipse.equinox.log.jar is installed but not started, we receive 10 MB of logs - in 10 files, 1 MB each. If the log is started, there is only one small log file with three exceptions. The exceptions in both cases are essentially the same, but in the case with the huge logs the exceptions are repeated many times and the stacktraces are much longer - cycles are observed in the them. Nothing in the stacktraces makes a hint that the problem may be in the log service being stopped.
 
Is this a normal behavior when the log service is not started, or should I open a bug for it?
 
In bug 282142 there are attached sample bundles to reproduce the below described issue. The problem with the logs is reprodueced by following the steps from the bug description, once with the log service started, and once with it stopped.
 
Kind regards,
Lazar
 

From: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org [mailto:equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org] On Behalf Of Kirchev, Lazar
Sent: Tuesday, June 30, 2009 3:12 PM
To: equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
Subject: [equinox-dev] Unclear warning in DS when a service componentprovides inexisting/unimplemented interface

Hello,
 
We are using declarative services and we came across the following situation. There are two components, A and B. A provides an interface and B references this interface. If the interface which A provides does not exist, or is not implemented, when the framework tries to create an instance of component B, a warning that there is probably a circular dependancy is logged. This does not help to find the real problem - that the interface does not exist and there is no such service.
 
In ComponentReference.getMethod(...), if the result of the call InstanceProcess.staticRef.getService(...) is null, then it is assumed that serviceObject cannot be created because of circularity. But InstanceProcess.staticRef.getService(...) returns null both when there is circularity and when the service object cannot be retrieved from the bundle context.
 
Also, if the component state is checked with the component command, it is Satisfied, saying in the dynamic information part that all references of the component are satisfied.
 
Is this the intended behavior of DS?
 
Kind regards,
Lazar Kirchev_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Permalink | Reply | 0 comments |
headers
portal on behalf of emo | 5 Jul 06:00
Favicon
Gravatar

Project meta data is out of date for rt.equinox

Jeff, Thomas,
Projects are required to keep meta data up to date using the MyFoundation
Portal (http://portal.eclipse.org/).  The following problems were found
with this project's meta-data:

* The date for release "3.5" is in the past, but the release is not marked
as completed. If it is completed, it should be marked as completed; if it
has been postponed, it should be given a new target date.
* There is no next/future release of this project. All Eclipse projects
must have a "next release" planned and scheduled.
Permalink | Reply | 0 comments |
headers
Sameera Jayasoma | 5 Jul 07:32
Picon
Gravatar

Slide deck of the webinar: OSGi and Equinox jump start

Hi devs,

I've listen to the webinar "OSGi and Equinox jump start" by Chris Aniszczyk and Jeff McAffer. It was a very interesting one. I am planning to go through it once, since I missed some parts in the middle. Are you planning to host the recored webinar soon? I would be very delighed if you can make the slide dek available.

Thanks
Sameera

Permalink | Reply | 2 comments |
headers
Chris Aniszczyk | 6 Jul 19:11
Favicon
Gravatar

Re: Slide deck of the webinar: OSGi and Equinox jump start

On Sun, Jul 5, 2009 at 12:32 AM, Sameera Jayasoma <sameera.madushan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi devs,

I've listen to the webinar "OSGi and Equinox jump start" by Chris Aniszczyk and Jeff McAffer. It was a very interesting one. I am planning to go through it once, since I missed some parts in the middle. Are you planning to host the recored webinar soon? I would be very delighed if you can make the slide dek available.

Hi Sameera. This mailing list isn't the right venue for this type of question. The equinox-dev mailing list is primarily for developers of Equinox and deep technical questions. So please take note next time you send a message ;)

As for your question, we plan on posting an edited version soon, find out by paying attention to our blog:

If you have any general questions about equinox, you can always use the Equinox newsgroup:

Cheers, 

--
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
Permalink | Reply | 1 comment |
headers
Sameera Jayasoma | 6 Jul 19:30
Picon
Gravatar

Re: Slide deck of the webinar: OSGi and Equinox jump start

Hi Chris,

Thanks for the reply. I am really sorry for inconvenience caused.

Sameera


On Mon, Jul 6, 2009 at 10:41 PM, Chris Aniszczyk <zx-yiTCNibefIkYhU31cYVdIwC/G2K4zDHf@public.gmane.org> wrote:
On Sun, Jul 5, 2009 at 12:32 AM, Sameera Jayasoma <sameera.madushan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi devs,

I've listen to the webinar "OSGi and Equinox jump start" by Chris Aniszczyk and Jeff McAffer. It was a very interesting one. I am planning to go through it once, since I missed some parts in the middle. Are you planning to host the recored webinar soon? I would be very delighed if you can make the slide dek available.

Hi Sameera. This mailing list isn't the right venue for this type of question. The equinox-dev mailing list is primarily for developers of Equinox and deep technical questions. So please take note next time you send a message ;)

As for your question, we plan on posting an edited version soon, find out by paying attention to our blog:

If you have any general questions about equinox, you can always use the Equinox newsgroup:

Cheers, 

--
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource | http://twitter.com/caniszczyk

_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Permalink | Reply | 0 comments |
headers
Pepping, Florian | 7 Jul 17:06
Favicon

NullPointerException in org.eclipse.equinox.launcher.Main$EclipsePolicy during PermissionCheck

Hello,

using the FrameworkSecurityManager of Equinox, I get a
NullPointerException during a permission check using Java 1.5.
Using exactly the same code, starting the application with Java 1.6,
everything works fine.
Stepping through the code in EclipsePolicy, it seems, that the
CodeSource of the ProtectionDomain to be checked against is null.
Referring to the Javadoc, this is normal behaviour and allowed but the
EclipsePolicy does not check this.

Is this a bug or am I doing something wrong? Currently I've have no idea
what to do, to avoid this Exception.

Below you find the StackTrace of the exception occuring.

java.lang.NullPointerException
	at
org.eclipse.equinox.launcher.Main$EclipsePolicy.implies(Main.java:2432)
[org.eclipse.equinox.launcher-1.0.100.jar:na]
	at
java.security.ProtectionDomain.implies(ProtectionDomain.java:195)
[na:1.5.0_06]
	at
java.security.AccessControlContext.checkPermission(AccessControlContext.
java:249) [na:1.5.0_06]
	at
org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager.intern
alCheckPermission(FrameworkSecurityManager.java:119)
[org.eclipse.osgi-3.4.0.jar:na]
	at
org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager$CheckP
ermissionAction.run(FrameworkSecurityManager.java:84)
[org.eclipse.osgi-3.4.0.jar:na]
	at java.security.AccessController.doPrivileged(Native Method)
[na:1.5.0_06]
	at
org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager.checkP
ermission(FrameworkSecurityManager.java:90)
[org.eclipse.osgi-3.4.0.jar:na]
	at
org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager.checkP
ermission(FrameworkSecurityManager.java:219)
[org.eclipse.osgi-3.4.0.jar:na]
	at
java.lang.SecurityManager.checkConnect(SecurityManager.java:1034)
[na:1.5.0_06]
	at java.net.Socket.connect(Socket.java:501) [na:1.5.0_06]
	at java.net.Socket.connect(Socket.java:457) [na:1.5.0_06]
	at java.net.Socket.<init>(Socket.java:365) [na:1.5.0_06]
	at java.net.Socket.<init>(Socket.java:178) [na:1.5.0_06]
	at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSoc
ketFactory.java:22) [na:1.5.0_06]
	at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSoc
ketFactory.java:128) [na:1.5.0_06]
	at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:569)
[na:1.5.0_06]
	at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
[na:1.5.0_06]
	at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
[na:1.5.0_06]
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:94)
[na:1.5.0_06]
	at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
[na:na]
	at
javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown
Source) [na:1.5.0_06]
	at
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.inv
oke(RMIConnector.java:969) [na:1.5.0_06]
	at
application.connector.impl.Connector.invoke(Connector.java:558) [na:na]
      ...

Thanks a lot

Florian

--

-- 
WINCOR NIXDORF International GmbH 
Sitz der Gesellschaft: Paderborn 
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller 
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Permalink | Reply | 1 comment |
headers
Thomas Watson | 7 Jul 18:10
Picon
Favicon

Re: NullPointerException in org.eclipse.equinox.launcher.Main$EclipsePolicy during PermissionCheck

I opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=282704 to track this.

This appears to be RMI related. Can you update the bug report with more details on the scenario where this occurs?

Tom



"Pepping, Florian" ---07/07/2009 10:07:37 AM---Hello,


From:
"Pepping, Florian" <florian.pepping <at> wincor-nixdorf.com>

To:
"Equinox development mailing list" <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

Date:
07/07/2009 10:07 AM

Subject:
[equinox-dev] NullPointerException in org.eclipse.equinox.launcher.Main$EclipsePolicy during PermissionCheck



Hello,

using the FrameworkSecurityManager of Equinox, I get a
NullPointerException during a permission check using Java 1.5.
Using exactly the same code, starting the application with Java 1.6,
everything works fine.
Stepping through the code in EclipsePolicy, it seems, that the
CodeSource of the ProtectionDomain to be checked against is null.
Referring to the Javadoc, this is normal behaviour and allowed but the
EclipsePolicy does not check this.

Is this a bug or am I doing something wrong? Currently I've have no idea
what to do, to avoid this Exception.

Below you find the StackTrace of the exception occuring.

java.lang.NullPointerException
at
org.eclipse.equinox.launcher.Main$EclipsePolicy.implies(Main.java:2432)
[org.eclipse.equinox.launcher-1.0.100.jar:na]
at
java.security.ProtectionDomain.implies(ProtectionDomain.java:195)
[na:1.5.0_06]
at
java.security.AccessControlContext.checkPermission(AccessControlContext.
java:249) [na:1.5.0_06]
at
org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager.intern
alCheckPermission(FrameworkSecurityManager.java:119)
[org.eclipse.osgi-3.4.0.jar:na]
at
org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager$CheckP
ermissionAction.run(FrameworkSecurityManager.java:84)
[org.eclipse.osgi-3.4.0.jar:na]
at java.security.AccessController.doPrivileged(Native Method)
[na:1.5.0_06]
at
org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager.checkP
ermission(FrameworkSecurityManager.java:90)
[org.eclipse.osgi-3.4.0.jar:na]
at
org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager.checkP
ermission(FrameworkSecurityManager.java:219)
[org.eclipse.osgi-3.4.0.jar:na]
at
java.lang.SecurityManager.checkConnect(SecurityManager.java:1034)
[na:1.5.0_06]
at java.net.Socket.connect(Socket.java:501) [na:1.5.0_06]
at java.net.Socket.connect(Socket.java:457) [na:1.5.0_06]
at java.net.Socket.<init>(Socket.java:365) [na:1.5.0_06]
at java.net.Socket.<init>(Socket.java:178) [na:1.5.0_06]
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSoc
ketFactory.java:22) [na:1.5.0_06]
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSoc
ketFactory.java:128) [na:1.5.0_06]
at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:569)
[na:1.5.0_06]
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
[na:1.5.0_06]
at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
[na:1.5.0_06]
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:94)
[na:1.5.0_06]
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
[na:na]
at
javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown
Source) [na:1.5.0_06]
at
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.inv
oke(RMIConnector.java:969) [na:1.5.0_06]
at
application.connector.impl.Connector.invoke(Connector.java:558) [na:na]
     ...

Thanks a lot

Florian





--
WINCOR NIXDORF International GmbH
Sitz der Gesellschaft: Paderborn
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Permalink | Reply | 0 comments |

Gmane