Bugzilla – Full Text Bug Listing
| Summary: | [transport] Transport not initialized properly | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Simon Clarkson <simone.clarkson> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | katya.stoycheva, pascal, sunil.kalpathi |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
The NPE appears to be happening because the Transport is not registered as a service. The code that you have above is not API so it is quite likely that there is setup code which is not being called. Are you truly calling these internal methods/classes or are you calling API and getting this error? If API, then which ones? (In reply to comment #1) > The code that you have above is not API so it is quite likely that > there is setup code which is not being called. Are you truly calling these > internal methods/classes or are you calling API and getting this error? If API, > then which ones? Thanks DJ for knowing the problem. But there is no API for the org.eclipse.equinox.p2.updatesite bundle. If you look at the manifest you see the only API is a single package available to pde build and I am not using pde build so I cannot use this bundle without breaking API. Export-Package: org.eclipse.equinox.internal.p2.updatesite;x-friends:="org.eclipse.pde.build", org.eclipse.equinox.internal.p2.updatesite.artifact;x-internal:=true, org.eclipse.equinox.internal.p2.updatesite.metadata;x-internal:=true It may just be that this bug is a documentation error and the documentation needs to be changed to say that update sites are only accessible from pde build or to say that the bundle only works in an environment with certain services running. If there is no API for this bundle then I suppose I can still access it through the extension point that it extends and that would not break API. I can look for classes I can use to do that. Perhaps I am forced to use MetadataRepositoryManager or perhaps I will just have to figure out how to register the service you mention. In general I would think the transport service should already be registered, so I find this surprising. Are you sure you want to be calling the update site code directly? The metadata repository manager will call this code automatically if it discovers and old-style update site and needs to load it. Users shouldn't have to call it. Is there more to do here? (In reply to comment #5) > Is there more to do here? NPEs like this are result of hidden start order of p2 bundles. This causes difficulties mainly when trying to run custom OSGi configuration containing p2 bundles. The workaround is to define/guess the explicit start order which may affect user experience in negative way. Since most of the p2 bundles declare ds components, it would be pretty easy to replace direct lookup in activator with referencing corresponding ds component and this should be enough. If you are interested in fixing this you may keep this bug open and/or create an umbrella one to keep track of similar issues. Let me know if this is the case and we can discuss further. As a user it is frustrating when the update goes on and on and on and then just fails! I am unable to use the install new software as well. I use a Windows XP machine ... I have had this problem in Equinox too. Is this ever going to be fixed? Are there any work-arounds!? Sunil, I think your issue is different than this one. Please open a new bug reports with details of what is happening. Thx. (In reply to comment #6) > NPEs like this are result of hidden start order of p2 bundles. This causes > difficulties mainly when trying to run custom OSGi configuration containing p2 > bundles. The workaround is to define/guess the explicit start order which may > affect user experience in negative way. > Since most of the p2 bundles declare ds components, it would be pretty easy to > replace direct lookup in activator with referencing corresponding ds component > and this should be enough. > > If you are interested in fixing this you may keep this bug open and/or create > an umbrella one to keep track of similar issues. Let me know if this is the > case and we can discuss further. Without doing an implementation I would be interested in understanding how you want to fix this. Don't forget that most services are scoped to the agent (IProvisioningAgent). Also what would happen when some key service is missing (say the Planner). *** This bug has been marked as a duplicate of bug 298987 *** |
Build Identifier: 3.7 I upgraded to Eclipse 3.7 and I now get a null pointer exception when mirroring a bundle from an old style update site into our repository. This worked fine with previous versions (3.6 and prior) so this is a regression. !ENTRY org.eclipse.equinox.app 4 0 2011-07-18 21:49:44.724 !MESSAGE !STACK 0 java.lang.NullPointerException at org.eclipse.equinox.internal.p2.updatesite.UpdateSite.loadActualSiteFile(UpdateSite.java:202) at org.eclipse.equinox.internal.p2.updatesite.UpdateSite.load(UpdateSite.java:144) at org.eclipse.equinox.internal.p2.updatesite.metadata.UpdateSiteMetadataRepositoryFactory.initializeRepository(UpdateSiteMetadataRepositoryFactory.java:87) at com.level3.opsConsole.repositorytools.BaseApplication.checkForNewClarifyEjb(BaseApplication.java:749) at com.level3.opsConsole.repositorytools.DeployApplication.start(DeployApplication.java:102) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.equinox.internal.app.AnyThreadAppLauncher.run(AnyThreadAppLauncher.java:26) at java.lang.Thread.run(Thread.java:595) Reproducible: Always Steps to Reproduce: 1. call this code: UpdateSiteMetadataRepositoryFactory factory = new UpdateSiteMetadataRepositoryFactory(); factory.setAgent(agent); IMetadataRepository metadataUpdateSite = factory.loadRepository(location, null); factory.initializeRepository(metadataUpdateSite, location, new NullProgressMonitor()); 2. Get null pointer exception 3.