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/
>
