Community
Participate
Working Groups
This is important when we try to get ECF working on embedded devices which have whacky EE's ;)
btw, will be working on this as I'm trying to get ECF working on some eRCP devices which run Foundation 1.1
For some odd reason, the IBM J9 VM for F1.1 isn't working right for me, but using a F1.0 VM with the F1.1 class libraries showed that the javax.security.auth.callback.Callback interface is the only problem (that being that it doesn't exist) for org.eclipse.ecf (I didn't check any other plug-ins since that's irrelevant unless the core plug-in is fixed). Over seventy errors were detected when using F1.0 class libraries, the ones I spotted seemed to be caused by the lack of public constructors/methods in Exception and RuntimeException.
(In reply to comment #2) > For some odd reason, the IBM J9 VM for F1.1 isn't working right for me, but > using a F1.0 VM with the F1.1 class libraries showed that the > javax.security.auth.callback.Callback interface is the only problem (that being > that it doesn't exist) for org.eclipse.ecf (I didn't check any other plug-ins > since that's irrelevant unless the core plug-in is fixed). I could introduce a new interfaces: CallbackHandler, Callback, and new exception class UnsupportedCallbackException in org.eclipse.ecf.security to replace the ones in javax.security.auth. Then no missing dependencies would exist for 1.1, right? Also...what's the status of 1.1 availability/adoption relative to 1.0? i.e. when was 1.1 introduced? Are most/all folks using 1.1 now? This creates some issues with ultimately using jaas, however. > > Over seventy errors were detected when using F1.0 class libraries, the ones I > spotted seemed to be caused by the lack of public constructors/methods in > Exception and RuntimeException. > OK. Obviously these could be fixed as well...but I guess what I'm getting at above is: do we think it's necessary?
changing back to open. accidently marked as fixed
So I think we need to tease out: 1) Which JRE (1.4 or 1.5) 2) Which EE (CDC or OSGi) 3) Which runtime version (1.0 or 1.1) And decide for each of these which ECF needs to support...and for how long (In reply to comment #4) > changing back to open. accidently marked as fixed >
I would like to see ECF run on devices so F1.1 would be great. I would also like to see some of the providers to stride for running on devices if possible. Also, ECF is nice in terms of OSGi because currently OSGi runs on a single VM and communicating, say amongst services residing in other VM's isn't easy.
(In reply to comment #3) > Then no missing dependencies would exist for 1.1, right? Just tried this for myself, Callback, CallbackHandler, NameCallback, and UnsupportedCallbackException would need to be created. > Also...what's the status of 1.1 availability/adoption relative to 1.0? i.e. > when was 1.1 introduced? Are most/all folks using 1.1 now? Chris, can you comment on this? But from your comment #6, I guess most are on 1.1? > This creates some issues with ultimately using jaas, however. True, per section 2.6 in JSR-219 (http://www.jcp.org/en/jsr/detail?id=219&showPrint), JAAS is one of the three optional packages for F1.1. So I guess the question is how common is the inclusion of the optional JAAS package in an embedded device nowadays? (In reply to comment #5) > 1) Which JRE (1.4 or 1.5) > 2) Which EE (CDC or OSGi) > 3) Which runtime version (1.0 or 1.1) For those that are unfamiliar with the EEs, you can refer to Appendix 1 at http://www.eclipse.org/eclipse/development/readme_eclipse_3.2.1.html. So if we're going JRE 1.5, most embedded devices won't be able to run ECF. The Nokia 770 would be such an exception (I think?).
(In reply to comment #3) > (In reply to comment #2) > > Over seventy errors were detected when using F1.0 class libraries, the ones I > > spotted seemed to be caused by the lack of public constructors/methods in > > Exception and RuntimeException. > > > > OK. Obviously these could be fixed as well...but I guess what I'm getting at > above is: do we think it's necessary? I forgot to mention that java.net.URI is another cause of problem in F1.0. I think that the Throwable-related issues can probably be taken care of via using extending from CoreException, but I'm not so sure about this lil' bugger. Filtered error output from F1.0 (barring deletion errors whilst copying/pasting from Eclipse): Callback cannot be resolved to a type CallbackHandler cannot be resolved to a type The constructor Exception(String, Throwable) is undefined The constructor Exception(Throwable) is undefined The constructor FileOutputStream(File, boolean) is undefined The constructor RuntimeException(InstantiationException) is undefined The import java.net.URI cannot be resolved The import java.net.URISyntaxException cannot be resolved The import javax.security cannot be resolved The method getAlgorithms(String) is undefined for the type Security The method getCallbackHandler() is undefined for the type IConnectContext The method getStackTrace() is undefined for the type Exception The method getStackTrace() is undefined for the type Throwable The method toURI() is undefined for the type BaseID URI cannot be resolved to a type URISyntaxException cannot be resolved to a type
As of 10.14.2006 4:10 PST I've added the new interfaces org.eclipse.ecf.core.security.Callback; org.eclipse.ecf.core.security.CallbackHandler; org.eclipse.ecf.core.security.NameCallback; org.eclipse.ecf.core.security.UnsupportedCallbackExceptionor to replace javax.security.auth.callback.Callback; javax.security.auth.callback.CallbackHandler; javax.security.auth.callback.NameCallback; javax.security.auth.callback.UnsupportedCallbackException; See comment #7 If you can Remy, please try these out with F1.1. As for problems with URI for F1.0...I don't think it's possible for us to do without the URI class. So I think that F1.0 is going to be out of the question. Anyone know how much of an imposition is this likely to be?
Created attachment 52006 [details] Patch to remove Callback import. (In reply to comment #9) > If you can Remy, please try these out with F1.1. Close, patch attached mops things up for org.eclipse.ecf. I don't exactly have the whole world checked out, but for the record... org.eclipse.ecf.discovery org.eclipse.ecf.fileshare org.eclipse.ecf.provider.irc ...are all go. org.eclipse.ecf.provider uses XML parsers in org.eclipse.ecf.provider.app.ServerConfigParser, and poses a problem.
Patch applied and checked in. Import removed in 0.9.3 (stable release due ~10/21). Thanks Remy. (In reply to comment #10) > Created an attachment (id=52006) [edit] > Patch to remove Callback import. > > (In reply to comment #9) > > If you can Remy, please try these out with F1.1. > > Close, patch attached mops things up for org.eclipse.ecf. > > I don't exactly have the whole world checked out, but for the record... > org.eclipse.ecf.discovery > org.eclipse.ecf.fileshare > org.eclipse.ecf.provider.irc > ...are all go. org.eclipse.ecf.provider uses XML parsers in > org.eclipse.ecf.provider.app.ServerConfigParser, and poses a problem. >
(In reply to comment #10) > org.eclipse.ecf.provider uses XML parsers in > org.eclipse.ecf.provider.app.ServerConfigParser, and poses a problem. Actually, I've come to realize that this shouldn't be a problem. In eRCP, XML APIs and an implementation are automatically included as a dependency when your plug-in requires org.eclipse.osgi (which basically means all plug-ins). So org.eclipse.ecf.provider will build cleanly on a F1.1 workspace/project JRE setting as long as it's setup correctly (by setting the PDE target platform to eRCP).
Despite the recent changes to org.eclipse.ecf.core.ID, some work is still needed to bring all the core API plug-ins up to specifications of being capable of running on a CDC-1.0/Foundation-1.0 runtime. Comment #8 outlines most of the problems, which may either require/cause massive API breakage of subclasses of ECFException or ECFException needs to be updated to handle all those super(?) calls accordingly by passing them to CoreException (that being ECFException should now subclass CoreException instead of Exception and passing on IStatuses upwards wrapping around the String message or Throwable cause). Of course, the best way to visualize all the errors is to just install a F1.0 runtime on one's machine, I have outlined the necessary steps to do so for Windows/Linux operating systems at [1] which describes the setting up of an F1.1 environment, but there is really essentially no difference between the two. [1] - http://wiki.eclipse.org/index.php/ECF_Development_Guidelines
Hi Remy, Thanks, I'm thinking of changing ECFException to be the following: import org.eclipse.core.runtime.CoreException; import org.eclipse.core.runtime.Status; import org.eclipse.core.runtime.IStatus; import org.eclipse.ecf.internal.core.identity.Activator; public class ECFException extends CoreException { private static final long serialVersionUID = 3256440309134406707L; public ECFException() { this(null,null); } /** * @param message message associated with exception */ public ECFException(String message) { this(message,null); } /** * @param cause the cause of the new exception */ public ECFException(Throwable cause) { this(null,cause); } /** * @param message * @param cause */ public ECFException(String message, Throwable cause) { this(new Status(IStatus.ERROR,Activator.PLUGIN_ID,0,message,cause)); } /** * @param status */ public ECFException(IStatus status) { super(status); } } This should allow existing ECFException-using code to remain the same, and allow CDC 1.0/Foundation 1.0 compatibility as it doesn't use Exception(Throwable) or Exception(String,Throwable). Seem reasonable? (In reply to comment #13) > Despite the recent changes to org.eclipse.cf.core.ID, some work is still > needed to bring all the core API plug-ins up to specifications of being capable > of running on a CDC-1.0/Foundation-1.0 runtime. > > Comment #8 outlines most of the problems, which may either require/cause > massive API breakage of subclasses of ECFException or ECFException needs to be > updated to handle all those super(?) calls accordingly by passing them to > CoreException (that being ECFException should now subclass CoreException > instead of Exception and passing on IStatuses upwards wrapping around the > String message or Throwable cause). > > Of course, the best way to visualize all the errors is to just install a F1.0 > runtime on one's machine, I have outlined the necessary steps to do so for > Windows/Linux operating systems at [1] which describes the setting up of an > F1.1 environment, but there is really essentially no difference between the > two. > > [1] - http://wiki.eclipse.org/index.php/ECF_Development_Guidelines >
(In reply to comment #14) > Thanks, I'm thinking of changing ECFException to be the following: I think this is a workable solution for the time being. All the other subclasses can be refactored to create proper IStatuses without breaking API later.
There are still pending issues that needs to be resolved. IServiceInfo/ServiceInfo in discovery uses URI. The static getAlgorithms(String) method in java.security.Security doesn't exist in F1.0 in GUID's initializeRandom(String, String) method. In other parts of the ECF core code there are some exception chaining that needs to be altered. For an example of what I mean, I'm talking about something like ContainerTypeDescription's constructor that wraps an InstantiationException in a RuntimeException.
> There are still pending issues that needs to be resolved. > IServiceInfo/ServiceInfo in discovery uses URI. The static I removed the references to URI in discovery (and the org.eclipse.ecf.provider.jmdns implementation). I removed references to RuntimeException/Exception(String,Throwable) (now throws NullPointerException instead). (In reply to comment #16) > getAlgorithms(String) method in java.security.Security doesn't exist in F1.0 in > GUID's initializeRandom(String, String) method. I put a try/catch (Exception) around this getAlgorithms(String) method, and now on F1.0 it will always default to using "SHA1PRNG" if getAlgorigthms isn't available. > > In other parts of the ECF core code there are some exception chaining that > needs to be altered. For an example of what I mean, I'm talking about something > like ContainerTypeDescription's constructor that wraps an > InstantiationException in a RuntimeException. I modified these to throw NullPointerException rather than use Exception(Throwable) or Exception(String,Throwable). If there are others please let me know. I don't see any others from above list. From the initial list above this looks like all of them, but I do want to test with the F1.0 EE environment with some small app. Note that the org.eclipse.ecf.provider bundle probably won't work on F1.0.
Created attachment 53730 [details] Patch to finish the last leg of F1.0 migration. This patch fixes up the remaining exception problems, updates .classpath to use an F1.0 JRE, and also changes all the MANIFEST.MF files to be F1.0/J2SE-1.3. Also, in the 0.9.3 N&N draft, org.eclipse.ecf.presence should be added to the F1.0-compatible section.
(In reply to comment #18) > Created an attachment (id=53730) [edit] > Patch to finish the last leg of F1.0 migration. > > This patch fixes up the remaining exception problems, updates .classpath to use > an F1.0 JRE, and also changes all the MANIFEST.MF files to be F1.0/J2SE-1.3. Thanks. Applied this patch. Also applied the J2SE-1.3 to org.eclipse.ecf and org.eclipse.ecf.remoteservice. > > Also, in the 0.9.3 N&N draft, org.eclipse.ecf.presence should be added to the > F1.0-compatible section. Done. I'm resolving this bug fixed...if additional F1.0 problems are found then we can reopen or file new bug. Thanks Remy for all the help with this.
closing and adding to ip log for patch
