[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] 3.5 M5 migration issue

Hi Helmut,

Can you please open a bug for this proxy problem within Platform/Team to track this.


Haigermoser, Helmut wrote:
Thanks Ian :)
Sounds like I should try to get more code into the query class! :)
Back in 3.4 I considered queries to be merely match queries and
collectors the ones where I could look at the resulting set of matching
IUs and filter that set to my wishes, looks like this concept is not the
right one to move forward so I'll adapt. You guys adapted as well
(LatestIUVersionCollector was removed, guess that logic is in a query
now..) so there is examples I can start with :)

Yeah, URL->URI, that's easy, a bit frustrating to run into some
exceptions if URL.toURI is used with platform-returned URLS but quickly
fixed by using the URIUtils :) My real problem there is that I heavily
used the MetadataRepositories class as input for views, a class that was
heavily reworked and can't be used the way I used to, it's queryable
now, where it was a simple container of URL(or URI)s. I'll adapt here as
well.. :)

That native deadlock is my biggest problem right now, I'm wondering if
anybody else saw this?
Thread [Thread-11] (Suspended)
        UnixProxyProvider.getGConfProxyInfo(String) line: not available
[native method]
line: 166
line: 69
        ProxyProvider(UnixProxyProvider).getProxyData() line: 62
        ProxyManager.getNativeProxyData() line: 182
        ProxySelector.getProxyData(String) line: 66
        ProxyType.getProxyData(String) line: 426
        ProxyType.updateHttpSystemProperties() line: 382
        ProxyType.updateSystemProperties(IProxyData) line: 211
        ProxyType.initialize() line: 509
        ProxyManager.initialize() line: 281
        Activator.start(BundleContext) line: 179
        BundleContextImpl$1.run() line: 807
line: not available [native method]
        BundleContextImpl.startActivator(BundleActivator) line: 798
        BundleContextImpl.start() line: 779
        BundleHost.startWorker(int) line: 352
        BundleHost(AbstractBundle).start(int) line: 280
        SecureAction.start(Bundle, int) line: 408
        EclipseLazyStarter.postFindLocalClass(String, Class,
ClasspathManager) line: 111
        ClasspathManager.findLocalClass(String) line: 447
        DefaultClassLoader.findLocalClass(String) line: 194
        BundleLoader.findLocalClass(String) line: 376
        SingleSourcePackage.loadClass(String) line: 33
        BundleLoader.findClassInternal(String, boolean, ClassLoader)
line: 440
        BundleLoader.findClass(String, boolean) line: 405
        BundleLoader.findClass(String) line: 393
        DefaultClassLoader.loadClass(String, boolean) line: 88
        DefaultClassLoader(ClassLoader).loadClass(String) line: 251
        DefaultClassLoader(ClassLoader).loadClassInternal(String) line:
        Class<T>.forName0(String, boolean, ClassLoader) line: not
available [native method]
        Class<T>.forName(String) line: 169
        Activator.getProxyService() line: 163

xies() line: 844

ieveRequest(IFileID, IFileRangeSpecification, IFileTransferListener,
Map) line: 776

ieveRequest(IFileID, IFileTransferListener, Map) line: 477
IFileTransferListener, Map) line: 95
String, OutputStream, IConnectContext, IProgressMonitor) line: 215
        ECFTransport.performDownload(String, OutputStream,
IConnectContext, IProgressMonitor) line: 164
        ECFTransport.download(String, OutputStream, IProgressMonitor)
line: 144
URI, OutputStream, IProgressMonitor) line: 463
OutputStream, IProgressMonitor) line: 446
OutputStream, IProgressMonitor) line: 513
        WRInstallAction.execute(Map) line: 45
        ParameterizedProvisioningAction.execute(Map) line: 33
        Install(Phase).mainPerform(MultiStatus, EngineSession, IProfile,
Operand[], ProvisioningContext, SubMonitor) line: 116
        Install(Phase).perform(MultiStatus, EngineSession, IProfile,
Operand[], ProvisioningContext, IProgressMonitor) line: 62
EngineSession, IProfile, Operand[], ProvisioningContext,
IProgressMonitor) line: 44
        Engine.perform(IProfile, PhaseSet, Operand[],
ProvisioningContext, IProgressMonitor) line: 51
        InstallerThread.run() line: 162

Ciao, hh
-----Original Message-----
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On
Behalf Of Ian Bull
Sent: Wednesday, March 11, 2009 11:04 PM
To: P2 developer discussions
Subject: Re: [p2-dev] 3.5 M5 migration issue

I don't know about the native call, but I can offer some advice on the

We are trying to move away from collectors (more work in 3.6) in favour
of more advanced queries.  The reason for this is that repository
implementors could potentially optimize queries based on their
repository implementation.  For example, get latest version, could be a
quick query if the repository stored all the IUs in sorted order based
on their version.

We would like to remove the requirement that collectors *must* be
returned, and those implementing IQueryables could return their own
collectors (possibly based on Futures or some other lazy loading
technology).  For more information on this, see [1].


As for the URL thing, you should be using URIs now.


On Wed, Mar 11, 2009 at 11:13 AM, Haigermoser, Helmut
<Helmut.Haigermoser@xxxxxxxxxxxxx> wrote:

        Ciao Guys :)
        I was wondering if you could help me with a migration issue I'm
        with our previously 3.4-based installer.
        At some point in the installation process I reach a native call
        does not return:

        The native call is UnixProxyProvider.getGConfProxyInfo(String)
(this is
        gnome/gtk specific).

        The p2 version I'm using is the I-build of this week, same is
true for
        M5.. :(

        Also, in the past we were using Collectors a lot, as well as the
        MetadataRepositories class that was fed some URLs,
        looks like these concepts are not to be used anymore, Collector
is not
        derived more then 10 times anymore, and MetadataRepositories
cannot be
        fed URLs so easily anymore, do you have some pointers for
        E.g, I'm guessing that one should favor overriding the
IMatchQuery base
        classes instead of putting logic into Collectors?
        Ciao, hh
        P.S.: I could help write a migration guide, using my experience
        if you could use that info?

        p2-dev mailing list

R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

p2-dev mailing list