[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Virgo and ECF remote services

Hi Boris...no...all the ecf bundles are used...even if httpclient provider is used.   With a little refactoring a few classes couls be moved out...but it hasn't been enough to justify extra complexity


Sent from my Samsung Epicâ 4G Touch.  Please excuse my brevity.


-------- Original message --------
Subject: Re: [virgo-dev] Virgo and ECF remote services
From: Borislav Kapukaranov <b.kapukaranov@xxxxxxxxx>
To: Virgo Project <virgo-dev@xxxxxxxxxxx>
CC:


That's fine, reliability is a good thing. A final question/confirmation - So there isn't any bundle we can remove from the ECF package we have? I was wondering if adding the httpclient filetransfer would make other filetransfer bundles obsolete.

Thanks,
Borislav

On Tue, Jan 10, 2012 at 7:43 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Boris,


On 1/10/2012 7:19 AM, Borislav Kapukaranov wrote:
Hi Scott, 

We've taken the p2 bundles + dependencies from the Equinox SDK package.

Hmm.  I wasn't aware that Equinox wasn't putting the httpclient provider in the Equinox SDK package.  For reliability reasons, I would suggest that they *do* include the httpclient provider in the SDK package...but I'm not the maintainer of that package.


What other bundles do you think we can add to our current list to benefit from the improved http transport you mentioned?

The httpclient provider consists of two small ECF bundles:

org.eclipse.ecf.provider.filetransfer.httpclient
and
org.eclipse.ecf.provider.filetransfer.httpclient.ssl

these are dependent upon the apache httpclient 3.1 bundle...that we get from Orbit.  apache httpclient also depends upon apache a) commons codec and b) commons logging...so there are 3 bundles from orbit that we get:

org.apache.commons.codec
org.apache.commons.logging
org.apache.commons.httpclient



Also can you see any bundles becoming obsolete when we replace the transport? I'd like to keep the p2 bundles + their dependencies tight in the nano distribution and I'm looking for a minimal working set. :)

I understand.  The ECF httpclient provider bundles are very small...but unfortunately the apache httpclient bundle(s) are not as small as I would like.

So for you, I think it comes down to a choice between code size and reliability.  The reason the httpclient provider was added in the first place was to make up for reliability deficiencies in the jre urlconnection runtime behavior...but it is possible that some/all of the issues with the urlconnection impl have been fixed (by Oracle/Sun). 

Thanks,

Scott




Thanks,
Borislav

On Wed, Jan 4, 2012 at 8:21 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Boris,

On 1/4/2012 9:37 AM, Borislav Kapukaranov wrote:
Hi Scott,

Please do.

Here's the bug:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=367880

Thanksinadvance for the attention.  It should be an easy fix, I believe.


As for the new version of the httpclient, we got the "old" http transport when we started consuming p2 and basically this is what was included along with p2.

Hmmm.  We've been including the httpclient provider to p2/Platform for a couple of major Eclipse releases now (3.6, 3.7 at least), but maybe it's not included in some  (Equinox sdk?) distribution of p2.  It's definitely been in Eclipse for at least two years now.




My assumption is that when p2 starts bundling with the new ECF version and httpclient we would automatically get these when we update our p2 version to a newer milestone.

That should work just fine...as you indicate with bug below the Equinox/p2 team is moving to using the latest release build (3.5.4) of ECF filetransfer.   But given what you say above, I'm not sure what distro of p2/ECF filetransfer you are using to create nano...as it seems that maybe whatever you are using doesn't by default include the httpclient-based provider?  I know that for Eclipse the httpclient-based provider is included/used.


Currently we are using M03 and I saw in bug367794 that the update of the httpcleint and ECF in p2 will happen in M05.

Right...it's actually happening right now (this week's integration build) is my understanding. 

So it will be in Eclipse...but if you are not using the Eclipse distro of Equinox/p2/ecf filetransfer then you might not get it (I don't control how/what's included in various Equinox distros).

Thanks,

Scott



Is that right?

Best Regards
Borislav

On Wed, Jan 4, 2012 at 7:24 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Boris and all,

I corresponded with Thomas Watson about this resolution problem with httpclient 3.1 in virgo, and he said:

A bundle that expresses a Bundle-RequiredExcecutionEnvironment: J2SE-1.2
must be able to run on J2SE-1.4 and higher.  I would like to understand
what issue you see when the bundle does not also list J2SE-1.4.

Tom

<I explained what I was seeing>

Hmmm, it is possible Virgo is using a custom java profile that does not
list J2SE-1.2 in the property org.osgi.framework.executionenvironment.
That would be a bug in Virgo, if that is the case.

Tom

[Scott]  Should I open a bug for this against Virgo nano?...as it seems that given this the Orbit folks are not going to change the httpclient ee.

Thanks,

Scott



On 1/3/2012 9:19 PM, Scott Lewis wrote:
On 1/3/2012 9:03 PM, Scott Lewis wrote:
Hi Boris,

<stuff deleted>

One thing that I noticed while trying to install the httpclient 3.1 bundle from Orbit with a new feature...the httpclient bundle from Orbit wouldn't resolve:

org.osgi.framework.BundleException: The bundle "org.apache.commons.httpclient_3.1.0.v201012070820 [100]" could not be resolved. Reason: Missing
Constraint: Bundle-RequiredExecutionEnvironment: CDC-1.0/Foundation-1.0,J2SE-1.2

I've verified that if I add J2SE-1.4 to the set of required execution environments for the org.apache.commons.httpclient bundle, then it will install in Virgo just fine.  Unfortunately, this bundle (httpclient 3.1.0) is currently maintained by Orbit committers...not be me or the ECF project.

I've sent a note to the Orbit dev mailing list, to find out if j2se 1.4 can be added to the httpclient 3.1.0 min ee.

Thanks,

Scott





Does this make sense to you?  Does Virgo Nano not provide these execution environments?

Anyway...hopefully we can jointly work these things out.  Please let me know what you think.

Thanks,

Scott


On 1/3/2012 9:28 AM, Borislav Kapukaranov wrote:
Sure, you can find it on the Virgo milestones download page, under the Virgo Nano name.
You can access telnet via "telnet localhost 2401", the p2 commands are available there.

Best Regards,
Borislav

On Tue, Jan 3, 2012 at 7:24 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Boris,

Ok...thanks...I will do this.  Sorry I haven't been keeping up on all the Virgo Nano work...sounds great.  Is there a distribution available?  If so...could you point me in the right direction?

Thanks much,

Scott



On 12/29/2011 5:59 AM, Borislav Kapukaranov wrote:
Hey Scott, 

Just tested installing ECF's remote services on Virgo Nano and, as expected, it went quite smoothly. The bundles got installed fine. 
If you'd like you can play with Virgo Nano and the p2 commands to see if there are any problems with the remote services lurking around.

Happy Holidays,
Bobby

On Fri, Sep 23, 2011 at 6:53 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
HI Bobby,


On 9/23/2011 1:02 AM, Kapukaranov, Borislav wrote:

Hey Scott,

 

As of 3.5 equinox.common should come out of the box with Virgo as p2 has dependency to it too.

Youâll notice the bug doesnât provide much content â that will change once I push the baseline of the p2 integration and build from then on for the remaining features.

I have the integration prepared locally and itâs looking good, e.g. the startup time on Windows was decreased more than twiceâ but Iâm waiting on two p2 enhancements [1] [2] to get resolved. Without them the code wonât be building and working properly.

 

In the end if it turns out these are taking a lot of time to resolve weâll just update EBR with the working versions until an official build is ready and start producing 3.5 alphas.

 

Do you have the update site of the ECF's remote services? Iâd be happy to try it.


Sure.  ECF's 3.5.2 release repo [1].   In this repo there are a few features...the one that is of interest for this use case (instead of Eclipse), is entitled 'ECF Remote Services Target Components'.   Here [2] is a detailed description of adding this feature to one's target platform.

Also see [3] for a 'getting started' tutorial (with examples, etc).

In a previous note, Lorie referenced this wiki page [4] (thanks Lorie).  The one thing that I wanted to add was that I think that much of what's described on this page [4] is now actually *unnecessary*...due to changes for ECF's implementation of the Remote Service Admin spec.  This wiki page...although still valid/supported, I believe...requires more programming than is now strictly necessary.  I will try to update it and simplify it when I can.

Also...for general reference, see [5].

Thanks,

Scott

[1] http://www.eclipse.org/ecf/downloads.php
[2] http://wiki.eclipse.org/EIG:Add_to_Target_Platform
[3] http://wiki.eclipse.org/EIG:Getting_Started_with_OSGi_Remote_Services
[4] http://wiki.eclipse.org/Using_Spring_with_ECF_Remote_Services
[5] http://wiki.eclipse.org/ECF#OSGi_Remote_Services



_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev




_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev


_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev




_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev



_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev



_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev


_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev




_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev


_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev




_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev


_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev