Community
Participate
Working Groups
I20090127 There are situations where the ECF transport is not initialized and "Tranport initialization error" is reported. A situation where I can get that to happen regularly is the following: - Start with a new SDK - Import a plug-in as source code - Export the plug-in using the "install in running instance" option You will notice the error that I mentioned.
*** Bug 265723 has been marked as a duplicate of this bug. ***
I have released a hack that forces the ecf.provider.filetransfer to be started on creation of the ECF*Transport instances (see ECFTransport and ECFMetadataTransport). It would still be good, though much less important to understand who/what is causing ecf.provider.filetransfer to be started when we are running normally.
Olivier hit this same problem when trying to test for bug 263272. This test was using the p2.artifact.mirror ant task run from a self hosted workspace.
Created attachment 126488 [details] Modified ECFTransport I've been using the method in bug 263491 to duplicate this problem, in this case the director application is used to install an IU from a local repository using a pre-existing config directory in the workspace. When this is used, only org.eclipse.ecf.internal.filetransfer.Activator is activated (bug 265723 saw the same.) However, the first time the configuration directory is used, or if the the repository and file are remote, then 3 all ECF Activators are called: org.eclipse.ecf.internal.filetransfer.Activator org.eclipse.ecf.internal.core.ECFPlugin org.eclipse.ecf.internal.provider.filetransfer.Activator Looking at the call stacks at the time of activation, the only cases I saw ECF fail to start occur with SimpleRepositoryManager. I replaced the code in the org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport with that of org.eclipse.equinox.internal.p2.updatesite.ECFTransport (a few minor changes were required, Pascal's fix is not present in this ECFTransport,) after this change ECF started properly through SimpleRepositoryManager. It would seem the issue is caused by this particular version of the ECFTransport class. I've attached a patch with the copied ECFTransport, and an update Messages file. (This ECFTransport seems to have been missed with a few changes made to the other two.) Perhaps a long-term solution is to merge the ECFTransports as per bug 216278.
Created attachment 126507 [details] ECFTransport patch Andrew and I took another look at the call stacks, and it looks like that the reason ECF is started when we go through the updatesite.ECFTransport, or ECFMetadataTransport, is that both have a method doGetLastModified which contains a catch block for org.eclipse.ecf.core.ContainerCreateException. The catch block is evidently enough to start ECF. artifact.repository.ECFTransport doesn't have a method to determine date of a modification, so doesn't have enough to trigger the main ECF plugin's activation. Pascal's patch doesn't seem to be starting the main ECF bundle, this modification ought to.
To be clear, the ECF bundles are being lazily started when classes get loaded. org.eclipse.ecf causes lazy activation of org.eclipse.ecf.identity due to ecf.identity interfaces used in method signatures in ecf. In turn, ecf.identity loads the other bundles by going through the registry extensions. The updatesite.ECFTransport does not contain any instance variables or method signatures using ecf classes, but it does contain the a try/catch block on an ecf type. It is the verifier that loads these classes causing lazy activation. Tom indicated that this behaviour around the catch block is not spec'ed, and some vms may be more lazy than others with respect to loading these classes. We should not be relying on such a tenuous connection to get the transports started.
Scott, we looking at explicitly starting ECF bundles rather than relying on references in classes. So we were wondering if starting the org.eclipse.ecf.provider.filetransfer bundle would be enough, or should we also/alternatively start org.eclipse.ecf.identity or even org.eclipse.ecf? Thanks.
(In reply to comment #7) > Scott, we looking at explicitly starting ECF bundles rather than relying on > references in classes. So we were wondering if starting the > org.eclipse.ecf.provider.filetransfer bundle would be enough, or should we > also/alternatively start org.eclipse.ecf.identity or even org.eclipse.ecf? > Thanks. > Sorry about the slow response...I missed this one in a personal flood. Due to the potential for ClassCircularityErrors, it's necessary to start: org.eclipse.ecf and then org.eclipse.ecf.provider.filetransfer
CC'ing Henrik as this may affect him as he works on merging the Transport classes.
(In reply to comment #9) > CC'ing Henrik as this may affect him as he works on merging the Transport > classes. > Thanks, I will make sure that both bundles get started as per Scott's reply.
*** This bug has been marked as a duplicate of bug 262351 ***
This should not have been closed as dupe
The ECF bundles are now started when the repository Activator method getRetrieveFileTransferFactory is called for the first time. This method is called when a file retrieval factory is required (happens each time a transfer is made). Can someone verify that the original reported problem is fixed so this issue can be closed?
Closing.
