This page gives some notes on CSS/SEAL integration issues. It should not be considered necessarily up-to-date.
Which EPICS CA API shall we use?
This is problematic: Consider these points:
- org.csstudio.platform.libs.epics - is the CSS package that "wraps" JCA/JNI. Specifically it contains jca.jar and jca.so. (in thia case we're using "wrap" to mean that it defines that it says those files are part of the plugin).
- org.csstudio.utility.pv.epics - is Kay's utility wrapper API for JCA, that offers a nicer API for JCA, and is presently used by CSS apps.
- SNS's XAL xal.jar, also wraps JCA (by including a file "ext.jar", which itself contains jca.jar).
So, if we want to use CSS and XAL together, we must address which one of them will contribute JCA; or as a 3rd possibility, make them both use an external JCA which they share.
Our solution, as described by Paul in email to Kay:
Hi Kay,
After a lengthy discussion among Greg, Ernest, Sergei and myself yesterday afternoon, we decided the path forward for us for the JCA within our application framework:
1. Use org.csstudio.platform.libs.epics plugin as one can access JCA directly.
2. Use org.csstudio.utility.pv.epics plugin so we can use any CSS apps.
3. Add the preferences "gov.aps.jca.jni.epics.linux-x86.library.path" and "gov.aps.jca.jni.epics.linux-x86.caRepeater.path" to the org.csstudio.platform.libs.epics plugin so it can use a different set of CA/JCA libraries outside CSS – we can then use our own copy of the CA/JCA native libraries. This is very important because we, at LCLS, may use a different version of EPICS/JCA. I believe many other accelerator facilities will be in the same situation.
4. We can then make XAL CA/JCA wrapper a plugin which depends on org.csstudio.platform.libs.epics, i.e. using the same jca.jar. This XAL JCA wrapper provides simpler APIs for channel access.
As all the above steps done, developers can have choice of all 3 ways to access JCA (1. directly, 2. via org.csstudio.utility.pv.epics, or 3. via XAL JCA wrapper plugin).