[equinox-dev] [prov] use of Foundation 1.1
There are several projects in p2 currently that list J2SE 1.4 and Foundation 1.1 in the BREE for the bundle. This is good but they list them in that order. The net result is that J2SE 1.4 is used to compile the code. What happens in some cases people don't have 1.4 so PDE uses the next best thing which ends up being 1.5 or 1.6. In the end we get references to things we ought not. In particular, I just had a setup in which there were no XML api in my workspace or target yet everything was compiling ok. Took quite some time to figure out how this could be so. If everyone agrees, I will go through the projects and update them accordingly. Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] OSGi interaction with external Java Programs.
Well, you can simply use RMI, SOAP, XML-RPC or JMX. Just write a bundle that exports its wrapped bundle context (to conform to whatever protocol requirements there are). On Feb 19, 2008, at 5:01 AM, Srijith Kochunni wrote: Hi,, I`m a new kid on the block as far as OSGi is concerned and am picking up pieces here and there. I would like to basically understand how an OSGi based implementation of a project, or rather a project built on top of OSGi is deployed. ? Could you please point me to appropriate articles upon the same, or share your thoughts on the same. I am using equinox as my framework implementation. I`ve been reading about equinox headless startup etc. wherein, it runs daemonized, if I am not wrong. I am interested in knowing how I could write a simple java console application and obtain a BundleContext reference to the running equinox session. Let`s say I want to implement a standalone utility outside of osgi to display all installed bundles or invoke a particular service provided by the bundle. How can this be done.? Thanks in Advance for your help.! Cheers, Srijith. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] use of Foundation 1.1
The org.eclipse.equinox.registry also has J2SE 1.4 listed before Foundation 1.1. If I remember correctly, this is because we do not have a bundle at pde-build time that provides the XML api to bundles with BREE J2SE 1.4. I think if you simply reorder the BREEs we will get a build failure for bundles needing XML stuff to compile. We would need an XML bundle to be available at build time also. Tom From: Jeff McAffer [EMAIL PROTECTED] To: 'Equinox development mailing list' equinox-dev@eclipse.org Date: 02/19/2008 07:57 AM Subject:[equinox-dev] [prov] use of Foundation 1.1 There are several projects in p2 currently that list J2SE 1.4 and Foundation 1.1 in the BREE for the bundle. This is good but they list them in that order. The net result is that J2SE 1.4 is used to compile the code. What happens in some cases people don’t have 1.4 so PDE uses the next best thing which ends up being 1.5 or 1.6. In the end we get references to things we ought not. In particular, I just had a setup in which there were no XML api in my workspace or target yet everything was compiling ok. Took quite some time to figure out how this could be so. If everyone agrees, I will go through the projects and update them accordingly. Jeff___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] [prov] use of Foundation 1.1
Right. At the very least we should establish a consistency setup where the team members have J2SE 1.4 installed (I did not). Having 1.4 first on the BREE is more community/developer friendly because it will “work” without having to install another JRE and get an XML parser/API from somewhere (e.g., eRCP). However, as we saw recently, it is easy for other references to creep in (including refs to XML stuff without a corresponding import and refs to classes/methods not in 1.4 or Foundation 1.1) We should also be consistent about it. Some bundles in p2 have Foundation 1.1 first. Others have J2SE1.4 first. In any event, this discussion is why I posted here. We should come to an agreement on the approach and move forward based on that. Jeff From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Watson Sent: Tuesday, February 19, 2008 10:02 AM To: Equinox development mailing list Subject: Re: [equinox-dev] [prov] use of Foundation 1.1 The org.eclipse.equinox.registry also has J2SE 1.4 listed before Foundation 1.1. If I remember correctly, this is because we do not have a bundle at pde-build time that provides the XML api to bundles with BREE J2SE 1.4. I think if you simply reorder the BREEs we will get a build failure for bundles needing XML stuff to compile. We would need an XML bundle to be available at build time also. Tom Inactive hide details for Jeff McAffer ---02/19/2008 07:57:02 AM---There are several projects in p2 currently that list J2SE Jeff McAffer ---02/19/2008 07:57:02 AM---There are several projects in p2 currently that list J2SE 1.4 and Foundation 1.1 in the BREE for the bundle. This is good but t From: Jeff McAffer [EMAIL PROTECTED] To: 'Equinox development mailing list' equinox-dev@eclipse.org Date: 02/19/2008 07:57 AM Subject: [equinox-dev] [prov] use of Foundation 1.1 _ There are several projects in p2 currently that list J2SE 1.4 and Foundation 1.1 in the BREE for the bundle. This is good but they list them in that order. The net result is that J2SE 1.4 is used to compile the code. What happens in some cases people don’t have 1.4 so PDE uses the next best thing which ends up being 1.5 or 1.6. In the end we get references to things we ought not. In particular, I just had a setup in which there were no XML api in my workspace or target yet everything was compiling ok. Took quite some time to figure out how this could be so. If everyone agrees, I will go through the projects and update them accordingly. Jeff___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev image001.gifimage002.pngimage003.png___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Eclipse and the Mac System Log - Runaway CPU
Sorry if this is a really inappropriate message for this list, but I'm at my whit's end and I doubt my question will be answered on the newsgroup. Basically, I'm seeing MEGABYTES of info logged from Eclipse. There's no errors, just reams and reams and reams of info regarding the libraries I'm using everything I runt junit tests or whatever.It's literally causing poor syslogd to chew up more than 1 CPU (and 120 megabytes so far, after 1/2 hour) trying to digest this stuff. So, the question is, how on earth do I stop this useless info from being logged to the system log? Is there some hidden flag I can turn on (please say yes) and/or modify which will stop it? I think what happened is that with the latest (10.5.2) update to Leopard, syslog changes (some new db format or something) is now causing way more CPU usage than normal. So it could well be that Eclipse was spewing out this much info all along and I just never noticed it. I've completely reinstalled Eclipse from the latest download and nothing changed - still get periodic swarms of Eclipse spew. Unfortunately, I'm noticing it now. With this happening all the time, it basically makes battery mode operation an impossibility. Any help? Or pointers? Hopefully, I'm not abusing this list, but as I said I am extremely desperate here... Any help appreciated... Sys info: Mac OS X 10.5.2 Eclipse: Version: 3.3.1.1 Build id: M20071023-1652 sample of log output: Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY: /System/Library/Java/ Extensions/CoreAudio.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY (original): /System/ Library/Java/Extensions/dns_sd.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY: /System/Library/Java/ Extensions/dns_sd.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY (original): /System/ Library/Java/Extensions/j3daudio.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY: /System/Library/Java/ Extensions/j3daudio.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY (original): /System/ Library/Java/Extensions/j3dcore.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY: /System/Library/Java/ Extensions/j3dcore.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY (original): /System/ Library/Java/Extensions/j3dutils.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY: /System/Library/Java/ Extensions/j3dutils.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY (original): /System/ Library/Java/Extensions/jai_codec.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY: /System/Library/Java/ Extensions/jai_codec.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY (original): /System/ Library/Java/Extensions/jai_core.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY: /System/Library/Java/ Extensions/jai_core.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY (original): /System/ Library/Java/Extensions/mlibwrapper_jai.jar Feb 19 15:33:06 dhcp-2op9-2op10-west-130-35-99-82 [0x0-0x18018].org.eclipse.eclipse[182]: LIBRARY: /System/Library/Java/ Extensions/mlibwrapper_jai.jar ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] DS exception in activate method
I have recently raised the same question in OSGi. It was decided that in this case only unbind() methods will be called. The OSGi specification will contain clarification about that in its next release. Regards, Stoyan - Original Message - From: Lukasz Bobowiec To: equinox-dev@eclipse.org Sent: Tuesday, February 19, 2008 6:56 PM Subject: [equinox-dev] DS exception in activate method Hello, I have not found in the OSGi r4 compendium what is the behaviour when an exception is raised in the activate(ComponentContext context) method in a component which is managed by Declarative Services. Does deactivate() should be invoked? or only unbind() methods? The specification should be more specific in this case. Could you provide me this information? BTW I found that in the old DS equinox implementation no action was taken. However in the ProSyst contribution unbind() is invoked on the component instance. --- Best regards, Lukasz Bobowiec Software Engineer, Common Agent Services [EMAIL PROTECTED] (+48 12) 628 9882 IBM SWG Lab, Cracow, Poland IBM Polska Sp. z o.o. oddział w Krakowie ul. Armii Krajowej 18 30 -150 Kraków NIP: 526-030-07-24 Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy KRS KRS 012941, Kapitał zakładowy: 3.073.600 PLN -- ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev __ NOD32 2886 (20080219) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
