Re: [equinox-dev] Bridging the plain Java and OSGi classloading worlds
sure, you just have to have a class loader in common. The way this would work is to modify the exports of the System bundle (an option when starting the framework in Equinox) to export the classes from the base class path you need. Then there is no class loader issues, as they're both using the same. On Aug 19, 2009, at 11:56 AM, Michael Furtak wrote: Hi all, I am using the EclipseStarter.startup(…) method to bring up the Equninox framework from within a plain ol’ Java application. My question is this: Is it possible to allow the plain ol’ Java environment to get and call service objects from the OSGi side? I know their respective classloader environments are disjoint, but is there any hope at all of bridging them? Has anyone been dumb/crazy enough to want to do this? Thanks, -Mike THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. ___ 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] Bridging the plain Java and OSGi classloading worlds
You can also check out: http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html note the section Creating and Configuring the Framework Instance, and the use of the property org.osgi.framework.system.packages.extra which makes this a bit easier. Works the same way with Equinox. On Aug 19, 2009, at 12:13 PM, Hal Hildebrand wrote: Sure. See http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/ for an in depth discussion by Costin of SS. On Aug 19, 2009, at 12:08 PM, Michael Furtak wrote: Hi Hal, Thanks very much for your reply. I’m heartened that you’re confident in this possibility. Is there any documentation for the option you mention that I can refer to? Thanks, -Mike THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org ] On Behalf Of Hal Hildebrand Sent: Wednesday, August 19, 2009 3:01 PM To: Equinox development mailing list Subject: Re: [equinox-dev] Bridging the plain Java and OSGi classloading worlds sure, you just have to have a class loader in common. The way this would work is to modify the exports of the System bundle (an option when starting the framework in Equinox) to export the classes from the base class path you need. Then there is no class loader issues, as they're both using the same. On Aug 19, 2009, at 11:56 AM, Michael Furtak wrote: Hi all, I am using the EclipseStarter.startup(…) method to bring up the Equninox framework from within a plain ol’ Java application. My question is this: Is it possible to allow the plain ol’ Java environment to get and call service objects from the OSGi side? I know their respective classloader environments are disjoint, but is there any hope at all of bridging them? Has anyone been dumb/crazy enough to want to do this? Thanks, -Mike THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. ___ 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 ___ 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] No mail in future
I promise not to send your mails in the future. On Aug 18, 2009, at 5:35 PM, cpint...@pt.lu wrote: Please don't send my mails in future.Thanks in advance. ___ 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] policy=dynamic in Declarative Services.
There's also Spring/DM, which does I think what you want - i.e. 1..1
cardinality, but not dropping the service is its dependencies
momentarily flicker.
On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:
You cannot directly do this, because mandatory reference is mandatory
at all times. However, you could make the reference optional and
perform some kind of internal activation/deactivation in the
bind/unbind methods.
However, if that still doesn't work for you then you're trying to do
something outside the scope of use-cases supported by DS, so you
should drop down to the ServiceTracker API.
Regards,
Neil
On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
sameera.madus...@gmail.com wrote:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory
service
reference that is not valid anymore, the referring component has
to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory
when the
component is activated. Once the component is activated, the
service is a
optional one. That mean I don't want my component to be de-
activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered
before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of
components.
This is the default unless you declare the component itself
“immediate”. The
meaning is: Unless no one wants to use your service, the component
(the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera
Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com
wrote:
if u want to the component isn't deactivated,u should set the bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service
should
be registered before the component is activated. in that case I
have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy
attribute
in
the reference element, the component is deactivated once the
bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid
value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected void activate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is activated ***
);
}
protected void deactivate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is deactivated
*** );
}
protected void setRegistryService(RegistryService
registryService) {
System.out.println(Set Registry
Service);
}
protected void unsetRegistryService(RegistryService
registryService)
{
System.out.println(Unset Registry
Service);
}
}
When I stop the bundle which registers the
org.wso2.carbon.registry.core.service.RegistryService,
following out
put
is generated.
*** Carbon Core bundle is deactivated ***
{org.wso2.carbon.core.internal.CarbonCoreDSComponent}
Unset Registry Service
This mean carbon.core bundle is deactivated right?
Expected behavior: When the RegisterService is unregisterd, only
the
unbind
method should be called. But here first the bundle is deactivated
and
then
the unbind method is called.
Any solution would be greatly appreciated.
Thanks
--
Sameera Jayasoma
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://tech.jayasoma.org
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
=
| BlueDavy |
| OSGi China User Group Director|
| http://china.osgiusers.org
Re: [equinox-dev] policy=dynamic in Declarative Services.
Well, Spring/DM will still work. The issue will be when he tries to
actually send a message to the service, in which case it will throw a
runtime exception.
On May 4, 2009, at 7:31 AM, BJ Hargrave wrote:
This does not sound like a flicker problem. DS can handle that
also for a dynamic 1..1 reference. The new service would be passed
to bind before the old service is passed to unbind. So the component
is never without a dependent service.
I think the issue here is that there is no replacement service
available and, with a 1..1 cardinality, the component is deactivated.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Hal Hildebrand hal.hildebr...@oracle.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date: 2009/05/04 10:24
Subject:Re: [equinox-dev] policy=dynamic in Declarative Services.
Sent by:equinox-dev-boun...@eclipse.org
There's also Spring/DM, which does I think what you want - i.e. 1..1
cardinality, but not dropping the service is its dependencies
momentarily flicker.
On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:
You cannot directly do this, because mandatory reference is
mandatory
at all times. However, you could make the reference optional and
perform some kind of internal activation/deactivation in the
bind/unbind methods.
However, if that still doesn't work for you then you're trying to do
something outside the scope of use-cases supported by DS, so you
should drop down to the ServiceTracker API.
Regards,
Neil
On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
sameera.madus...@gmail.com wrote:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory
service
reference that is not valid anymore, the referring component has
to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory
when the
component is activated. Once the component is activated, the
service is a
optional one. That mean I don't want my component to be de-
activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered
before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of
components.
This is the default unless you declare the component itself
“immediate”. The
meaning is: Unless no one wants to use your service, the component
(the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera
Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative
Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com
wrote:
if u want to the component isn't deactivated,u should set the
bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service
should
be registered before the component is activated. in that case I
have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy
attribute
in
the reference element, the component is deactivated once the
bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid
value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected void activate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is activated ***
);
}
protected void deactivate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is deactivated
*** );
}
protected void setRegistryService(RegistryService
registryService) {
System.out.println(Set Registry
Service);
}
protected void unsetRegistryService(RegistryService
registryService)
{
System.out.println
Re: [equinox-dev] policy=dynamic in Declarative Services.
Yes, I see the point. He wants the service to become available before
the dependency arrives.
Sry for the confusion.
On May 4, 2009, at 7:55 AM, Toedter, Kai wrote:
@Hal, but DM will always create the service component eagerly since
it does not support lazy instantiation, right?
Kai
From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org
] On Behalf Of Hal Hildebrand
Sent: Montag, 4. Mai 2009 16:53
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Well, Spring/DM will still work. The issue will be when he tries to
actually send a message to the service, in which case it will throw
a runtime exception.
On May 4, 2009, at 7:31 AM, BJ Hargrave wrote:
This does not sound like a flicker problem. DS can handle that
also for a dynamic 1..1 reference. The new service would be passed
to bind before the old service is passed to unbind. So the component
is never without a dependent service.
I think the issue here is that there is no replacement service
available and, with a 1..1 cardinality, the component is deactivated.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Hal Hildebrand hal.hildebr...@oracle.com
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2009/05/04 10:24
Subject:
Re: [equinox-dev] policy=dynamic in Declarative Services.
Sent by:
equinox-dev-boun...@eclipse.org
There's also Spring/DM, which does I think what you want - i.e. 1..1
cardinality, but not dropping the service is its dependencies
momentarily flicker.
On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:
You cannot directly do this, because mandatory reference is
mandatory
at all times. However, you could make the reference optional and
perform some kind of internal activation/deactivation in the
bind/unbind methods.
However, if that still doesn't work for you then you're trying to do
something outside the scope of use-cases supported by DS, so you
should drop down to the ServiceTracker API.
Regards,
Neil
On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
sameera.madus...@gmail.com wrote:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory
service
reference that is not valid anymore, the referring component has
to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory
when the
component is activated. Once the component is activated, the
service is a
optional one. That mean I don't want my component to be de-
activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered
before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of
components.
This is the default unless you declare the component itself
“immediate”. The
meaning is: Unless no one wants to use your service, the component
(the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera
Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative
Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com
wrote:
if u want to the component isn't deactivated,u should set the
bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service
should
be registered before the component is activated. in that case I
have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy
attribute
in
the reference element, the component is deactivated once the
bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid
value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected
[equinox-dev] Removing access restrictions on classes.jar
Sorry for asking the development list, but I'm at my wit's end. I upgraded to Ganymede and now I have [EMAIL PROTECTED]@ access restrictions on my JRE 1.5 classes.jar. These access restrictions are marked as unmodifiable - and low and behold they are unmodifiable. I am using a class in sun.* and this worked fine in the previous version of Eclipse. First, can someone please - dear god, please - help me overcome this problem. Second, why are these *unmodifiable*? Third, when did this work in previous versions but now bangs me on the head in Ganymede Thanks ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Removing access restrictions on classes.jar
Okay, figured out this is due to some odd change to a restricted development environment form the workspace defined JRE. Not sure how that happened, but frightening non-the-less. Sorry for the spam. On Jul 23, 2008, at 11:27 AM, Hal Hildebrand wrote: Sorry for asking the development list, but I'm at my wit's end. I upgraded to Ganymede and now I have [EMAIL PROTECTED]@ access restrictions on my JRE 1.5 classes.jar. These access restrictions are marked as unmodifiable - and low and behold they are unmodifiable. I am using a class in sun.* and this worked fine in the previous version of Eclipse. First, can someone please - dear god, please - help me overcome this problem. Second, why are these *unmodifiable*? Third, when did this work in previous versions but now bangs me on the head in Ganymede Thanks ___ 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] Removing access restrictions on classes.jar
Nope. Was a Maven project, using the Maven plugin. Don't know why on earth things got messed up during the upgrade. The Ganymede maven plugin stuff is a bit more paternalistic than the old one. Thanks for the response... :) On Jul 23, 2008, at 2:18 PM, Thomas Watson wrote: Hi Hal, Is the project a PDE project? If so then this could happen when you set the Bundle-ExecutionEnvironment header in your bundle manifest and have PDE update your classpath settings. This will apply an execution environment definition to your VM to prevent you from accessing packages which are not in one of the defined EEs (e.g. J2SE-1.4 execution environment does not contain sun.* classes). You can actually remove these access rules by going to the projects Properties-Java Build Path-Libraries tab and selecting the JRE System Library to edit. Instead of using an Execution Environment you can use an Alternative JRE that does not use an Execution Environment definition. Tom graycol.gifHal Hildebrand ---07/23/2008 01:40:28 PM---Okay, figured out this is due to some odd change to a restricted development environment form the ecblank.gif From: ecblank.gif Hal Hildebrand [EMAIL PROTECTED] ecblank.gif To: ecblank.gif Equinox development mailing list equinox-dev@eclipse.org ecblank.gif Date: ecblank.gif 07/23/2008 01:40 PM ecblank.gif Subject:ecblank.gif Re: [equinox-dev] Removing access restrictions on classes.jar Okay, figured out this is due to some odd change to a restricted development environment form the workspace defined JRE. Not sure how that happened, but frightening non-the-less. Sorry for the spam. On Jul 23, 2008, at 11:27 AM, Hal Hildebrand wrote: Sorry for asking the development list, but I'm at my wit's end. I upgraded to Ganymede and now I have [EMAIL PROTECTED]@ access restrictions on my JRE 1.5 classes.jar. These access restrictions are marked as unmodifiable - and low and behold they are unmodifiable. I am using a class in sun.* and this worked fine in the previous version of Eclipse. First, can someone please - dear god, please - help me overcome this problem. Second, why are these *unmodifiable*? Third, when did this work in previous versions but now bangs me on the head in Ganymede Thanks ___ 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 ___ 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] Eclipse and the Mac System Log - Runaway CPU
Thanks for the reply. Yea, I have no idea where this is coming from, but it's definitely coming from the Eclipse process (via pid). Things got so bad I literally had to turn off the system log - which is a lovely way to be running your system, I might add ;) On Feb 20, 2008, at 11:18 AM, John Arthorne wrote: No idea For what it's worth, these don't look like log messages produced by the platform or framework log. I don't recall ever seeing log output like this before. John Hal wrote on 02/19/2008 06:38:16 PM: 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 ___ 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] 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
[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] Maven and all that [was: Jetty and commons logging]
nice. On Jan 7, 2008, at 5:15 AM, Tom Huybrechts wrote: On Jan 7, 2008 3:45 AM, Jeff McAffer [EMAIL PROTECTED] wrote: [redoing the subject to be more accurate as we are well and truly off the original topic...] That doc talks about releases but does not define the term. Do you know what the expectation is? One of our builds can be 200MB or so and we end up running at least one and sometimes multiple a day in some (unhappy) cases. Last I knew ibiblio was not keen on this sort of publishing. Our weekly integration builds would be a candidate though they might prefer only the 6week milestones. Either way the process is the same. We run several such builds during the integration/milestone week and in the end declare one of them as good and promote it. We do not apriori know which build is going to be the one as a mess o' testing is done after the build (automated and manual). A publishing step such as discussed here would have to be after the fact and so cannot be built into the build itself. What is really needed is a tool that would take an Eclipse build (e.g., update site or download zip or ...) and fire it into the desired repo in the desired form. These tools exist. See e.g. http://maven.apache.org/plugins/maven-eclipse-plugin/to-maven-mojo.html (although I do not agree with the conventions it uses to map osgi identifiers onto Maven identifiers) or Tycho ( http://svn.m2eclipse.codehaus.org/browse/ ~raw,r=374/m2eclipse/tycho/trunk/readme.txt ) which I wrote but which could use a little more documentation. Tom This would accommodate the myriad of different build mechanisms/ processes that exist today at Eclipse and allow anyone who wanted the content in another repo to do so without having to depend on the particular project build team/process. With this in hand we could talk about getting particular build teams to call the tool when they promote a build. Alternatively and more generally it would be interesting to have an RSS feed (forgive me Kim) for build promotions. External parties can then start sucking content as soon as it is released. Jeff Hal Hildebrand [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/06/2008 09:08 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] Jetty and commons logging I guess I'm a little confused... There's a few sites which will do the mirroring for you, like ibiblio.org. Ibiblio, and the myriad of mirrors for the site, host a plethora of maven artifacts for projects all over. I'm not completely up on the mechanisms for publishing to these repositories - i.e. what are the protocols, contacts, etc - but considering that plenty of projects and code bases publish there means it can't be too hard to do. Further, tools exist for Ant and Maven to make this publishing part of the build release process. Or, at the very least, a target of the build which can be manually called when appropriate. So, it seems like everyone could be happy. Those actually build outside of Eclipse (strange, I know) could have access to Eclipse artifacts from a maven repository hosted by Ibiblio rather than having to provide your own space, and you Eclipse folks would have this folded into your build in a painless fashion. This link has the Apache documentation on publishing to their site which is mirrored by Ibiblio: http://www.apache.org/dev/release-publishing.html Although this wouldn't be what you'd be doing, I'm fairly certain the process would be similar. Hope this helps all involved... On Jan 6, 2008, at 5:29 PM, Jeff McAffer wrote: Hey Alex, Please note that I started my reply by saying I don't disagree. The point is that the team available to do this sort of work is small and the diskspace/mirror capacity to do it is similarly restricted. I'm not happy about it either. As with many of these things, if there are folks in the community who care deeply about this and want to do the work/supply the space, we'd be happy to work with them. You are also correct in observing that in the p2 work we did indeed decide to have separately downloadable repository (metadata and artifact) indexing. Further our general approach has been to allow for individual bundle download/install rather than whole feature management. These moves have been a big win and should go a long way towards addressing the valid usecases you point out. I completley agree that the update site structure is lacking in these areas but disagree with you that Maven addresses the issues. The POM file certainly can represent the metadata in a bundle but its primary focus is to drive the build. So, for example, if the build generates the dependency information into the output manifest.mf (e.g., using bnd or mangen style processing) then that dependency
Re: [equinox-dev] Maven and all that [was: Jetty and commons logging]
I think the determination is entirely up to you. Maven has the concept of SNAPSHOTS, which are incrementals of a release. Myself, I wouldn't bother with these, as just having officially released artifacts would be enough to start with and given the prodigious output... WRT your suggestion at the end, I think that's a great idea given what you point out about your process. And it sounds like an excellent project for someone who wants to see the artifacts made available in Maven. Myself, I'll see what I can do about investigating the building of such a tool. +1 on the RSS feed. That would be bitchin'. On Jan 6, 2008, at 6:45 PM, Jeff McAffer wrote: [redoing the subject to be more accurate as we are well and truly off the original topic...] That doc talks about releases but does not define the term. Do you know what the expectation is? One of our builds can be 200MB or so and we end up running at least one and sometimes multiple a day in some (unhappy) cases. Last I knew ibiblio was not keen on this sort of publishing. Our weekly integration builds would be a candidate though they might prefer only the 6week milestones. Either way the process is the same. We run several such builds during the integration/milestone week and in the end declare one of them as good and promote it. We do not apriori know which build is going to be the one as a mess o' testing is done after the build (automated and manual). A publishing step such as discussed here would have to be after the fact and so cannot be built into the build itself. What is really needed is a tool that would take an Eclipse build (e.g., update site or download zip or ...) and fire it into the desired repo in the desired form. This would accommodate the myriad of different build mechanisms/processes that exist today at Eclipse and allow anyone who wanted the content in another repo to do so without having to depend on the particular project build team/ process. With this in hand we could talk about getting particular build teams to call the tool when they promote a build. Alternatively and more generally it would be interesting to have an RSS feed (forgive me Kim) for build promotions. External parties can then start sucking content as soon as it is released. Jeff Hal Hildebrand [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/06/2008 09:08 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] Jetty and commons logging I guess I'm a little confused... There's a few sites which will do the mirroring for you, like ibiblio.org. Ibiblio, and the myriad of mirrors for the site, host a plethora of maven artifacts for projects all over. I'm not completely up on the mechanisms for publishing to these repositories - i.e. what are the protocols, contacts, etc - but considering that plenty of projects and code bases publish there means it can't be too hard to do. Further, tools exist for Ant and Maven to make this publishing part of the build release process. Or, at the very least, a target of the build which can be manually called when appropriate. So, it seems like everyone could be happy. Those actually build outside of Eclipse (strange, I know) could have access to Eclipse artifacts from a maven repository hosted by Ibiblio rather than having to provide your own space, and you Eclipse folks would have this folded into your build in a painless fashion. This link has the Apache documentation on publishing to their site which is mirrored by Ibiblio: http://www.apache.org/dev/release-publishing.html Although this wouldn't be what you'd be doing, I'm fairly certain the process would be similar. Hope this helps all involved... On Jan 6, 2008, at 5:29 PM, Jeff McAffer wrote: Hey Alex, Please note that I started my reply by saying I don't disagree. The point is that the team available to do this sort of work is small and the diskspace/mirror capacity to do it is similarly restricted. I'm not happy about it either. As with many of these things, if there are folks in the community who care deeply about this and want to do the work/supply the space, we'd be happy to work with them. You are also correct in observing that in the p2 work we did indeed decide to have separately downloadable repository (metadata and artifact) indexing. Further our general approach has been to allow for individual bundle download/install rather than whole feature management. These moves have been a big win and should go a long way towards addressing the valid usecases you point out. I completley agree that the update site structure is lacking in these areas but disagree with you that Maven addresses the issues. The POM file certainly can represent the metadata in a bundle but its primary focus is to drive
