[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.

Tschüß,
Stefan

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]
        ProxyProvider(UnixProxyProvider).getSystemProxyInfo(String)
line: 166
        ProxyProvider(UnixProxyProvider).getProxyForTypes(String[])
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
        AccessController.doPrivileged(PrivilegedExceptionAction<T>)
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:
319
        Class<T>.forName0(String, boolean, ClassLoader) line: not
available [native method]
        Class<T>.forName(String) line: 169
        Activator.getProxyService() line: 163

UrlConnectionRetrieveFileTransfer(AbstractRetrieveFileTransfer).setupPro
xies() line: 844

UrlConnectionRetrieveFileTransfer(AbstractRetrieveFileTransfer).sendRetr
ieveRequest(IFileID, IFileRangeSpecification, IFileTransferListener,
Map) line: 776

UrlConnectionRetrieveFileTransfer(AbstractRetrieveFileTransfer).sendRetr
ieveRequest(IFileID, IFileTransferListener, Map) line: 477
        MultiProtocolRetrieveAdapter.sendRetrieveRequest(IFileID,
IFileTransferListener, Map) line: 95
        ECFTransport.transfer(IRetrieveFileTransferContainerAdapter,
String, OutputStream, IConnectContext, IProgressMonitor) line: 215
        ECFTransport.performDownload(String, OutputStream,
IConnectContext, IProgressMonitor) line: 164
        ECFTransport.download(String, OutputStream, IProgressMonitor)
line: 144
        SimpleArtifactRepository.downloadArtifact(IArtifactDescriptor,
URI, OutputStream, IProgressMonitor) line: 463
        SimpleArtifactRepository.downloadArtifact(IArtifactDescriptor,
OutputStream, IProgressMonitor) line: 446
        SimpleArtifactRepository.getArtifact(IArtifactDescriptor,
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
        InstallerThread$WRPhaseSet(PhaseSet).perform(ActionManager,
EngineSession, IProfile, Operand[], ProvisioningContext,
IProgressMonitor) line: 44
        Engine.perform(IProfile, PhaseSet, Operand[],
ProvisioningContext, IProgressMonitor) line: 51
        InstallerThread.run() line: 162

TIA,
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
queries.

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].

[1]
http://wiki.eclipse.org/Equinox/p2/Proposals/Query_Management_and_Optimi
zation

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

cheers,
ian



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
seeing
        with our previously 3.4-based installer.
        At some point in the installation process I reach a native call
which
        does not return:

        ProxyProvider:166
        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
alternatives?
        E.g, I'm guessing that one should favor overriding the
IMatchQuery base
        classes instead of putting logic into Collectors?
        TIA,
        Ciao, hh
        P.S.: I could help write a migration guide, using my experience
there,
        if you could use that info?

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





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

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