Hi Aaron,
I think this solution could avoid adding the dependency of script API
into camel-core in Camel 2.x. +1 for it.
When we move to Camel 3.x, we could let the camel-core looking up the
ScriptEngineFacotries.
BTW, we are closing to Camel 2.6 release, if the patch can't catch up
the last train, we will leave it to Camel 2.7.0.
Willem
On 1/14/11 8:50 PM, Aaron Mulder wrote:
So right now, I have the Activator identifying and actually loading
ScriptEngineFactories, which is why there is the dependency on
javax.script.
For now (Camel 2.x) I can instead have the Activator just identify the
bundles with a script engine config file (META-INF/services/...) and
hand out URLs to the script engine config files instead.
That way, in camel-script, instead of just asking for a script engine
from the OSGi configuration, it'll ask for all the script engine
config files, and load the scripting engines itself.
Thanks,
Aaron
On Fri, Jan 14, 2011 at 12:45 AM, Claus Ibsen<claus.ib...@gmail.com> wrote:
Hi
On Fri, Jan 14, 2011 at 3:23 AM, Aaron Mulder
<ammul...@alumni.princeton.edu> wrote:
I would like to get https://issues.apache.org/jira/browse/CAMEL-3481
into the 2.6 release (make camel-script work in OSGi). I have a
solution available, but it adds a dependency to javax.script in
camel-core in the OSGi Activator (fine for Java 1.6, new dependency
for 1.5). Just want to make sure that's OK before proceeding.
No we should not mess with camel-core dependencies.
Camel 3.0 will be JDK 1.6+ btw so why not wait for that version.
For Camel 2.x we could look to introduce a SPI API which the
camel-core-osgi module can use to load the script engines using OSGi
Activators.
I'll put in the OSGi integration test showing the problem, but it
doesn't pass unless you get an OSGi-ified JRuby or other scripting
language, so I'm leaving it @Ignored for now.
Thanks,
Aaron
On Tue, Jan 11, 2011 at 3:13 AM, Claus Ibsen<claus.ib...@gmail.com> wrote:
Hi
Apache Camel 2.6 starts to look really good. There is only a few tickets left.
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12311211&fixfor=12315690
So if you have any of those tickets assigned, then please work on
getting the ticket resolved this week (sooner the better).
In this release we have added new components and as usual they often
depend on OSGi bundles to be released. Today we have 2 SNAPSHOT's
pending
The pom.xml file in camel/platforms/karaf/features lists the following
2 SNAPSHOTs:
<aws-java-sdk-bundle-version>1.1.1_1-SNAPSHOT</aws-java-sdk-bundle-version>
<spymemcached-bundle-version>2.5_1-SNAPSHOT</spymemcached-bundle-version>
They are needed for the camel-aws and camel-kestrel components.
Jean Bonofre from the SMX team have promised to release those bundles.
We should get in touch with him so he can start releasing them today.
The problem is that the Apache release process takes approx 3 days
(IMHO a bit overkill for a SMX bundle wrap release).
The CI test of Camel at Apache seems also very good.
https://hudson.apache.org/hudson/job/Camel.trunk.fulltest/
Usually it can fail with a, but the component works fine
- Caused by: java.net.BindException: Address already in use
So we should keep an eye on CI builds and make sure to focus on any
last minute bug fixes, and fix/improve unit test if needed.
--
Claus Ibsen
-----------------
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
--
Claus Ibsen
-----------------
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
