gmane.comp.ide.eclipse.equinox.devel

Servlet Bridge

Dan Lipofsky — 2012-05-16T21:19:11

I am trying to use servletbridge to get OSGi in tomcat as described at

http://www.eclipse.org/equinox/server/http_in_container.php
http://eclipse.dzone.com/articles/embedding-osgi-tomcat

I got it to work using the pre-built bridge.war.
However that was last built in 2007.
I'd like to use a newer version of OSGi, so I tried to build my
own version of bridge.war with new OSGi but that didn't work.

The servletbridge JAR itself is still from 2007 so it is possible it
is not compatible with newer versions of OSGi.  Does anyone know about
this?  I couldn't find a newer servletbridge.  Does anyone know if one
exists or if this project is being maintained?

The JARs I tried to use were

org.eclipse.core.jobs-3.5.0.v20100515.jar
org.eclipse.equinox.common-3.6.0.v20100503.jar
org.eclipse.equinox.http.registry-1.0.0-v20070608.jar
org.eclipse.equinox.http.servlet-1.0.0-v20070606.jar
org.eclipse.equinox.http.servletbridge-1.0.0-v20070523.jar
org.eclipse.equinox.registry-3.5.0.v20100503.jar
org.eclipse.osgi-3.6.0.v2010

Re: Enabled pre-receive hook on equinox gitrepositories

Thomas Watson — 2012-05-15T12:39:02

Thanks for setting us up Paul.

Tom




                                                                                                                           
  From:       Paul Webster <pwebster-cmaem7PIVQT44Nm34jS7GywD8/FfD2ys< at >public.gmane.org>                                                                  
                                                                                                                           
  To:         Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org>,                                                  
                                                                                                                           
  Date:       05/15/2012 07:33 AM                                                                                          
                                                                                                                           
  Subject:    [equinox-dev] Enabled pre-receive hook on

Enabled pre-receive hook on equinox git repositories

Paul Webster — 2012-05-15T12:30:43

Hi,

I have enabled the pre-receive hook on the equinox git repositories.

For more info:
*Bug 362363* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=362363> - Better
policy ... provide hooks to allow a committer to delete <userid>/branchname
branches

Re: Service Lookup by GUID very Slow - theFrameworkScalability

Thomas Watson — 2012-05-10T18:49:30

I agree with Gunner.  Please open a bug report and attach a test that we
can reproduce with.

Tom




                                                                                                                         
  From:       Gunnar Wagenknecht <gunnar-DDAdSCQIZD/oSeNpYEG0Jg< at >public.gmane.org>                                                                
                                                                                                                         
  To:         equinox-dev-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org,                                                                                   
                                                                                                                         
  Date:       05/10/2012 01:23 AM                                                                                        
                                                                                                                         
  Subject:

Re: Service Lookup by GUID very Slow - the FrameworkScalability

Gunnar Wagenknecht — 2012-05-10T06:21:31

Stanly,

Am 08.05.2012 20:18, schrieb Stanley_Poon-9gNvg8MwaQo< at >public.gmane.org:

I find your report very valuable. I think at this time the best thing is
to submit a bug and attach the sample project. The project should
contain all the code that is necessary to execute the test. This allows
the developers to look at the code and run the tests. Otherwise things
might get lost in between mails.

If Equinox is really 50x slower than two other frameworks then it looks
like there is room for improvement.

Thanks!

-Gunnar

Adding unbundled JARs to OSGi

Dan Lipofsky — 2012-05-09T16:12:36

I am trying to convert a legacy project top OSGi, and I've got a bunch of
3rd party JARs that are not OSGi bundles I need to reference.
What is really the best way to do this?

I found some of them (but not all of them) as OSGi bundles at
http://ebr.springsource.com/repository/app/bundle

I tried wrap protocol
http://team.ops4j.org/wiki/display/paxurl/Wrap+Protocol
but couldn't get it work (if anyone has a working example of that it would
be great).

I really don't want to maintain my own repository of wrapped JARs.

I read the article
"Exposing the boot classpath in OSGi"

http://blog.springsource.org/2009/01/19/exposing-the-boot-classpath-in-osgi
/

I think this is the way I'd prefer to go.
However I can't seem to add anything to the classpath.
I tried setting the CLASSPATH env var, and also using the -cp flag
but neither worked.  When I log System.getProperty("java.class.path")
I just see org.eclipse.osgi_3.7.2.v20120110-1415.jar.
I am running equinox like this
$ java -jar org.eclipse.osgi_3.7.2.v20120110

Re: Service Lookup by GUID very Slow - the Framework Scalability

Neil Bartlett — 2012-05-08T18:22:23

My guess would be something in the implementation of the filter. Sorry I 
have lost track of which framework implementation was slow... but 
nevertheless I don't know enough about the internal details of any of 
them. Perhaps the slow framework is recompiling the filter each time?

I have created a Gist showing, in simplified form, how to use 
ServiceTracker to create a dynamic index for the services using a 
particular ID property. I would be interested in hearing whether this 
speeds things up, and by how much. Here's the link: 
https://gist.github.com/2638180

Regards
Neil

Re: Service Lookup by GUID very Slow - the Framework Scalability

2012-05-08T18:18:02

Thank you Neil.

But the exact same example runs 50X faster on the other two OSGi runtime. Any thoughts? And we observed the other runtime used more memory. Will they be using some indexing (in memory)?

Thanks,
Stanley

From: equinox-dev-bounces< at >eclipse.org [mailto:equinox-dev-bounces< at >eclipse.org] On Behalf Of Neil Bartlett
Sent: Tuesday, May 08, 2012 11:02 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Service Lookup by GUID very Slow - the Framework Scalability

* No, services are not created lazily by default. You are creating the services yourself in your code sample, i.e., the 'serviceObject' variable.

There are some frameworks such as Declarative Services that create service instances lazily, however the creation of the service (and therefore the associated cost) would not be triggered by merely calling getServiceReferences(). It would be triggered by calling getService() on one of the ServiceReference objects.

* By creating a ServiceTracker, you can be notified s

Re: Service Lookup by GUID very Slow - the Framework Scalability

Neil Bartlett — 2012-05-08T18:01:58

* No, services are not created lazily by default. You are creating the 
services yourself in your code sample, i.e., the 'serviceObject' variable.

There are some frameworks such as Declarative Services that create 
service instances lazily, however the creation of the service (and 
therefore the associated cost) would not be triggered by merely calling 
getServiceReferences(). It would be triggered by calling getService() on 
one of the ServiceReference objects.

* By creating a ServiceTracker, you can be notified synchronously as 
each service is registered. You could then very cheaply extract the ID 
property from each service and store it in a ConcurrentHashMap for later 
reference.

I'm pretty sure that the poor performance of your example is due to the 
fact that the framework is forced to evaluate the filter expression 
"(ID=x)" against every entry in the registry. You don't even allow it to 
return when it finds the first match, because you have called 
getServiceReferences(), plural, so it must find

Re: Service Lookup by GUID very Slow - the Framework Scalability

2012-05-08T17:44:35

The key question is about the scalability of the runtime, in terms of


-         Number of services, 100K, 1M, 10M, etc

-         Registering and unregistering them, churn over long period of time

-         Is it primarily memory bound? Assuming that services are not CPU heavy or thread hungry

Some details of the experiment we had:

The code is pretty straightforward. We only have a 5 Service Classes. We add an ID property to each service object we register and later look it up using that ID. The look up through getServiceReferences() took 4-5 seconds when we have 200K services registered.

Also, can someone shed some light for the following questions:

-        Do you think lazy service creation may be the reason? Is lazy creation the default? How to configure it?
-        Can you outline the steps to use ServiceTrackerCustomizer to build index? Do you mean trapping the registration events and build the needed indexes?

Service Registration: we register all the 200K service instances i

Re: JVM arguments passed through launcher commandline?

Ben Abernathy — 2012-05-08T17:07:16

Ah yes, that was the problem. Thanks for the help Stephan.

Ben

On Tue, May 8, 2012 at 11:02 AM, Stephan Herrmann
<stephan-CFLBMwTPW48UNGrzBIF7/Q< at >public.gmane.org> wrote:

Re: JVM arguments passed through launcher commandline?

Stephan Herrmann — 2012-05-08T17:02:53

Ben,

that's why we need the docs :-/
I remember a discussion to use --launcher.appendVmargs only
as a toggle, you'd still need -vmargs in addition.
Also, I'm not sure if all is supported on the command line or whether
the toggle must occur in the .ini file
(see https://bugs.eclipse.org/bugs/show_bug.cgi?id=149994#c56 )

Stephan

On 05/08/2012 06:57 PM, Ben Abernathy wrote:

Re: JVM arguments passed through launcher commandline?

Ben Abernathy — 2012-05-08T16:57:06

Stephan,

Thank you for the reply. I also found this doc related issue[1].

Unfortunately, I am still not able to get the property added to the
VM. When I execute the launcher by:

application.exe -console --launcher.appendVmargs -Daprop=avalue

The original vmargs in the ini are there, but the additional property
is not being appended.

Ben


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=352235

On Tue, May 8, 2012 at 10:37 AM, Stephan Herrmann
<stephan-CFLBMwTPW48UNGrzBIF7/Q< at >public.gmane.org> wrote:

Re: JVM arguments passed through launcher commandline?

Stephan Herrmann — 2012-05-08T16:37:20

Exactly. See the bug for details.
It seems the documentation for this feature fell through the cracks.
I just filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=378868

best,
Stephan

Re: JVM arguments passed through launcher commandline?

Ben Abernathy — 2012-05-08T16:25:56

We have an ini file as well with some standard vmargs in it. What
think I'm noticing is, if you have vmargs specified on the command
line, the vmargs in the ini file are ignored. Is that correct? Is
launcher.appendVmargs intended to address this by combining command
line and ini vmargs?

Thanks,

Ben

On Tue, May 8, 2012 at 10:18 AM, Stephan Herrmann
<stephan-CFLBMwTPW48UNGrzBIF7/Q< at >public.gmane.org> wrote:

Re: JVM arguments passed through launcher commandline?

Stephan Herrmann — 2012-05-08T16:18:28

I was going to suggest --launcher.appendVmargs to avoid surprises [1],
but I can't find it in the docs. What happened?

best,
Stephan

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=149994

On 05/08/2012 06:04 PM, Pascal Rapicault wrote:

Re: JVM arguments passed through launcher commandline?

Pascal Rapicault — 2012-05-08T16:04:27

See -vmargs on  http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html

HTH

Pascal

On 2012-05-08, at 9:01 AM, Ben Abernathy wrote:

JVM arguments passed through launcher command line?

Ben Abernathy — 2012-05-08T16:01:17

I'm not sure if this is the right list to ask, but here it goes. We
have an OSGi application built that uses the equinox launcher. I would
like to be able to pass -D properties via the command line in order to
aid automated integration testing of our application.

For example, I'm trying to accomplish this:
application.exe -Dsomeprop=somevalue

However, this doesn't appear to work. Is this not possible or am I
missing something else? I realize I can declare these properties in
the launcher ini, but I'd prefer not to do that as I'd have to create
a new ini for each integration test.

Any help would be greatly appreciated.

Ben

Re: Service Lookup by GUID very Slow

2012-05-07T18:00:17

The code is pretty straightforward. We only have a 5 Service Classes. We add an ID property to each service object we register and later look it up using that ID.

Also, can you shed some light for these two?

-        Do you think lazy service creation may be the reason? Is lazy creation the default? How to configure it?
-        Can you outline the steps to use ServiceTrackerCustomizer to build index? Do you mean trapping the registration events and build the needed indexes?


Service Registration: we register all the 200K service instances in a loop. They are one of 5 different server classes.
BundleContext bc,

            Dictionary<String, String> props = new Hashtable<String, String>(1);
            props.put(“ID”, “ID0000001”);
            bc.registerService(ServiceClass, serviceObject, createProperties(props));


Service Look up:

            BundleContext bc,
            bc.getServiceReferences(ServiceClass, "(ID=ID0000001)”);


Thank you,
Stanley
From: equinox-dev

Project meta data is out of date for rt.equinox

portal on behalf of emo — 2012-05-05T04:00:15

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:

* Project home page does not exist (projecturl = http://eclipse.org/equinox
returns a 404)

Re: Service Lookup by GUID very Slow

BJ Hargrave — 2012-05-04T17:18:47

Equinox also indexes by objectClass alone. So I am not sure what the 
discrepancy is here. Would be nice to have the test case code to analyze. 
Stanley, can you post a gist with the code?