Thanks, @nacx!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/157#issuecomment-89669599
See http://markmail.org/thread/oto47qk2kzcdtebb
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds/pull/721
-- Commit Summary --
* Using a custom ConnectorFactory for ssh-agent that only tries netcat
-- File Changes --
M
drivers/sshj/src
Comment from @nacx: "I've built your branch and I've been able to list nodes
without issues (in OSX)." Now to find out what the build problem is...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#issuecomment-90569677
Closed #721.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#event-275270624
Looks like a Jenkins issue - let's try this again...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#issuecomment-90574235
> I assume the same fix has to be applied to the jsch driver?
Not yet...testing this one first. Good point! ;-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#issuecomment-90577830
> Failed — Merged build finished.
Another Jenkins error, by the looks of things? Just cleared the workspace.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#issuecomment-90579956
> could we merge that now? thanks!
Yes, looks good to me! Please squash'n'merge...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-examples/pull/72#issuecomment-90586951
> All is well — Merged build finished.
Phew ;-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#issuecomment-90597950
I don't think there are any issues with adding the license, but I'm not sure we
_need_ it? jclouds-examples is not part of the jclouds distribution.
@abayer @ccustine: Some expert ASF advice would be appreciated ;-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jcloud
Closed #721.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#event-277196258
Merged to
[master](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=search;s=Andrew+Phillips;st=author).
@nacx: Also backport to 1.9.x?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#issuecomment-91238084
Follow-up to 01dcca14
Before change:
After change:
Also needs to be backport
Merged to
[master](https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;a=commit;h=d5a780059a7db13ad29e7ad3369cdc01e61696f0)
and
[1.9.x](https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;a=commit;h=7f5de857b0bca07f041581840bb0855b359d99f5)
---
Reply to this email directly or view i
Backported to
[1.9.x](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=0e2ee14)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#issuecomment-91247353
@nacx: Just to be sure...is this OK for you?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/721#issuecomment-91096783
@nacx: ping? ;-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/26#issuecomment-91096715
> @@ -153,7 +153,7 @@ context.close();
> {% endhighlight %}
>
> There are many options available for creating a `Context`. Please see the
> -[ContextBuilder](http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html)
> Javadocs for
> +[ContextBuilder](https://jclouds.apache.org/re
> +Object service = super.addingService(reference);
> +if (serviceToken.isAssignableFrom(service.getClass())) {
> +cacheManager.bindService((T) service);
> +}
> +return service;
> +}
> +
> +@
> @@ -61,7 +65,9 @@ public void start(BundleContext context) throws Exception {
> cacheProviderRegistration =
> context.registerService(CacheProvider.class.getName(), cacheProvider, new
> Hashtable());
>
>
> -chefServiceTracker = CacheUtils.createServiceCacheTracker(context,
> if (chefService != null) {
> -Iterable cookbookVersions =
> chefService.listCookbookVersions();
> + Iterable cookbookVersions =
> chefService.getApi().chefService()
[minor] Indent off?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclou
> if (!Strings.isNullOrEmpty(id)) {
> -ChefService service = null;
> -for (ChefService svc : services) {
> -if (id.equals(svc.getContext().unwrap().getName())) {
> -service = svc;
> + ApiContext service = null;
[minor]
> }
>
> -public static ChefService findOrCreateChefService(String api, String
> name, String clientName, String clientCredential, String clientKeyFile,
> String validatorName, String validatorCredential, String validatorKeyFile,
> String endpoint, List chefServices) {
> + public sta
> @@ -192,10 +198,10 @@ public static ChefService getChefService(String id,
> String api, List }
>
> if (!Strings.isNullOrEmpty(api)) {
> -ChefService service = null;
> -for (ChefService svc : services) {
> -if (api.equals(svc.getContext(
> it is more correct to inject directly the context that provides access to
> both the ChefApi and the ChefService.
A bit of a non-expert question here, but do we _need_ access to both? Would
e.g. ChefApi not be enough?
---
Reply to this email directly or view it on GitHub:
https://github.com/j
> @@ -50,6 +52,10 @@
> public static final String JCLOUDS_CHEF_VALIDATOR_KEY_FILE =
> "JCLOUDS_CHEF_VALIDATOR_KEY_FILE";
> public static final String JCLOUDS_CHEF_VALIDATOR_CREDENTIAL =
> "JCLOUDS_CHEF_VALIDATOR_CREDENTIAL";
> public static final String JCLOUDS_CHEF_ENDPOINT =
> "
> @@ -61,7 +65,9 @@ public void start(BundleContext context) throws Exception {
> cacheProviderRegistration =
> context.registerService(CacheProvider.class.getName(), cacheProvider, new
> Hashtable());
>
>
> -chefServiceTracker = CacheUtils.createServiceCacheTracker(context,
> @@ -50,6 +52,10 @@
> public static final String JCLOUDS_CHEF_VALIDATOR_KEY_FILE =
> "JCLOUDS_CHEF_VALIDATOR_KEY_FILE";
> public static final String JCLOUDS_CHEF_VALIDATOR_CREDENTIAL =
> "JCLOUDS_CHEF_VALIDATOR_CREDENTIAL";
> public static final String JCLOUDS_CHEF_ENDPOINT =
> "
> but I hope the motivation is a bit more clear now
Yes, that makes sense - thank you for the detailed explanation! I guess my
question really boils down to "Can we cache ChefApi rather than the context?" -
from a quick glance, it seems we only use the context directly in the
completers, and we
> The key point here is that the services jclouds-karaf provides, have to be
> "named". And the ChefApi and ChefService alone don't have a name.
That's what I understood too, based on your description (thanks!). I should
start by saying that I'm fine with the change as-is and I don't want to spe
> We are extracting the name exactly from the same object as before.
Perhaps we were previous also using the "first named object." But given that, I
think it makes a lot of sense to keep things as they are.
A separate note: do we need any additional tests for this?
With the exception of the out
> @@ -80,3 +80,7 @@ A context represents a specific connection to a particular
> provider. From the pe
> Once you have created a context via the
> [ContextBuilder](http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html)
> and are "connected" to a particular cloud service, you can
> You can also get a view back from the ContextBuilder and _later_ unwrap it
> to access the underlying API or provider.
> +
> +The context also provides access to some low level resources, such as the
> dependency injection framework or the executors used to perform concurrent
> operations, so
> Pushed to master. Thanks!
Thanks, @nacx! See https://github.com/jclouds/jclouds-site/pull/167
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/166#issuecomment-100070734
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds-site/pull/167
-- Commit Summary --
* Removing duplicate text about closing the context
* Using new HEAD Javadocs URL
-- File Changes --
M start/concepts.md (12)
-- Patch Links --
htt
Rendered:
Javadoc links seem to work, too.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/167#issuecomment-100074443
@nacx I take it you're OK with this, then..? ;-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/167#issuecomment-100289562
@nacx Ping..?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/167#issuecomment-100946331
> lgtm :)
Thanks, @nacx! Merged to
[master](https://git1-us-west.apache.org/repos/asf?p=jclouds-site.git;a=commit;h=584d42566169503fd1df7d1076787abb433e3a4e)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/167#issuecomment-101430856
Closed #167.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/167#event-303274679
Still lots of test failures, I'm afraid :-(
https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/1799/testReport/
Before we try to dig into those, could you perhaps explain _why_ this change is
needed? I don't disagree that the behaviour is arguably not correct, but as you
can see this is
> The original motivation was to make
> https://github.com/bouncestorage/swiftproxy pass swift's functional tests
@kahing Thanks for clarifying. Yes, the list/put divergence is not fun. Hm.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/758#issueco
> I think the right approach for forks would be to change the groupId
Agreed. jclouds tries to stick to semver, and if private users want to use a
different version scheme, I'd say that it should be easy enough for them to
patch `JcloudsVersion` as needed? Not sure why that change would need to
> Is that possible?
@grkvlt I think nightly builds sound like a pretty good idea, in general,
assuming we can get the release process sufficiently automated, of course. I'm
not sure what the ASF thoughts would be on where to publish those, though,
since I doubt the ASF release repo is the right
> @@ -45,7 +46,7 @@ protected BaseView(@Provider Context backend, @Provider
> TypeToken @SuppressWarnings("unchecked")
> @Override
> public C unwrap(TypeToken type) {
> - checkArgument(checkNotNull(type,
> "type").isAssignableFrom(backendType), "backend type: %s not assignable t
> + isSuperTypeOfTypeToken =
> TypeToken.class.getDeclaredMethod("isSupertypeOf", TypeToken.class);
> + } catch (NoSuchMethodException nsme) {
> + try {
> +// Guava 18 and earlier method
> +isSuperTypeOfType =
> TypeToken.class.getDeclaredMethod("isAss
> @@ -104,7 +104,7 @@ public void testPeanutButterDidntTurnIntoWine() {
> wine.unwrap(typeToken(PeanutButter.class));
> fail();
>} catch (IllegalArgumentException e) {
> - assertEquals(e.getMessage(), "backend type:
> org.jclouds.internal.BaseViewTest$Water not
>}
> + Set actualTags = actualTagsBuilder.build();
> + assertThat(actualTags).containsAll(tags);
Just curious: related to this PR, or just cleanup?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gi
> +// Guava 18 and earlier method
> +isSuperTypeOfType =
> TypeToken.class.getDeclaredMethod("isAssignableFrom", Type.class);
> +isSuperTypeOfTypeToken =
> TypeToken.class.getDeclaredMethod("isAssignableFrom", TypeToken.class);
> + } catch (NoSuchMethod
> +(the "License"); you may not use this file except in compliance with
> +the License. You may obtain a copy of the License at
> +
> +http://www.apache.org/licenses/LICENSE-2.0
> +
> +Unless required by applicable law or agreed to in writing, software
> +distributed under the License is distr
> +See the License for the specific language governing permissions and
> +limitations under the License.
> +-->
> +
> +http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xs
> +
> + org.apache.jclouds.karaf.bundles
> + jsch-agentproxy-jsch
> + jclouds :: Karaf :: JSCH Agentproxy Shaded Bundle
> + bundle
> +
> +
> +
> + org.apache.servicemix.bundles
> +
> org.apache.servicemix.bundles.jsch-agentproxy-jsch
> + ${jsch.agentproxy.bundle.version}
>
> +${import.packages}
> +
> +
> +
> +
> +org.apache.maven.plugins
> +maven-shade-plugin
> +2.4.3
> +
> +
> +package
> +
> + shade
> +
> +
> +
> +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> +See the License for the specific language governing permissions and
> +limitations under the License.
> +-->
> +
> +http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:sch
> +
> +Unless required by applicable law or agreed to in writing, software
> +distributed under the License is distributed on an "AS IS" BASIS,
> +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> +See the License for the specific language governing permissions and
> +limit
Thanks for putting this together, @nacx! Just minors and nits from me - can be
taken care of during the merge, I think.
Independently of this PR: now that we have the framework for including shaded
bundles relatively easily, perhaps worth considering making one that applies
ymnk/jsch-agent-prox
@nacx Quick ping on the comments here?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/77#issuecomment-244759266
@nacx @iocanel Thoughts on this? Close or merge?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/64#issuecomment-244826526
> +${import.packages}
> +
> +
> +
> +
> +org.apache.maven.plugins
> +maven-shade-plugin
> +2.4.3
> +
> +
> +package
> +
> + shade
> +
> +
> +
> The problem is that the scriptEngine is not loaded and is always null when
> running in the interactive shell, which results in silently printing null
> values when a NPE occurs.
Which value is passed in for the `engine` parameter? From your explanation and
what I can see in the code, the pro
> I've also copied the classes mentioned here but that didn't work...
Just to confirm: you followed the instructions in that blog post and replaced
```
private final ScriptEngineManager scriptEngineFactory = new
ScriptEngineManager();
```
with
```
private final ScriptEngineManager scriptEngineFa
The question I would have at this point is whether this ever worked? I'd be
surprised if it was broken all the way from the time it was implemented. So I
wonder what has changed (on the Felix side?) to break this?
--
You are receiving this because you are subscribed to this thread.
Reply to thi
> @@ -23,6 +23,7 @@ limitations under the License.
> chef
> org.apache.jclouds.karaf
> 2.0.0-SNAPSHOT
> +../..
I don't think this is correct - the `chef` artifact is indeed one level up
--
You are receiving this because you are subscribed to this thread.
Reply to this email di
> @@ -21,6 +21,7 @@ limitations under the License.
> jclouds-karaf
> org.apache.jclouds
> 2.0.0-SNAPSHOT
> +..
Isn't that the default value?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.c
> +http://www.apache.org/licenses/LICENSE-2.0
> +
> +Unless required by applicable law or agreed to in writing, software
> +distributed under the License is distributed on an "AS IS" BASIS,
> +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> +See the License for the sp
> @@ -23,6 +23,7 @@ limitations under the License.
> chef
> org.apache.jclouds.karaf
> 2.0.0-SNAPSHOT
> +../..
See comment below
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/j
@nacx Suggestion: break out the "fix output" issue out into a different JIRA
issue and PR? I think that's a slightly different discussion from the bundle
fix that this PR is about?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on Gi
> @@ -23,6 +23,7 @@ limitations under the License.
> chef
> org.apache.jclouds.karaf
> 2.0.0-SNAPSHOT
> +../..
See comment below
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/j
> +http://www.apache.org/licenses/LICENSE-2.0
> +
> +Unless required by applicable law or agreed to in writing, software
> +distributed under the License is distributed on an "AS IS" BASIS,
> +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> +See the License for the sp
> @@ -23,6 +23,7 @@ limitations under the License.
> chef
> org.apache.jclouds.karaf
> 2.0.0-SNAPSHOT
> +../..
See comment below
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/j
Thanks for the changes, @nacx! Just one more additional thing that I noticed
while working on this: the dependency on
`org.apache.servicemix.bundles.jsch-agentproxy-jsch` in the root POM can
probably be removed too.
--
You are receiving this because you are subscribed to this thread.
Reply to
> +${import.packages}
> +
> +
> +
> +
> +org.apache.maven.plugins
> +maven-shade-plugin
> +2.4.3
> +
> +
> +package
> +
> + shade
> +
> +
> +
Thanks for this, @nacx! I think I'm a little closer to getting the
`OGSiScriptEngineManager` approach that you linked to originally to work - will
try to see if I can figure that out one way or the other soon
--
You are receiving this because you are subscribed to this thread.
Reply to this ema
Alternative to #78, but addressing the same issue.
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds-karaf/pull/79
-- Commit Summary --
* Try to use an OSGi-compliant way of loading JSR 223 script engines
-- File Changes --
M
commands/s
> @@ -0,0 +1,79 @@
> +/*
Lots of cleanup and review still to go with these three classes
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/79/files/0b99dad1aa7786eaf11028bf91fc1d27
> + return null;
> +}
> + }
> +
> + /**
> + * Iterates through all bundles to get the available @link
> ScriptEngineFactory classes
> + * @return the names of the available ScriptEngineFactory classes
> + * @throws IOException
> + */
> + private List findFa
@nacx Could you give (a CLI built from) this a shot? It looks like it should be
working
```
jclouds> jclouds:compute-service-create --provider aws-ec2 --identity key
--credential secret --name test
Waiting for compute service with name: test.
jclouds> jclouds:location-list --provider aws-ec2 --n
> BTW, regarding the shaded bundle fix, it works, but there is still this error
> when the CLI starts:
>From [this example of
>`startup.properties`](https://github.com/apache/karaf/blob/karaf-2.3.11/assemblies/apache-karaf/src/main/filtered-resources/etc/startup.properties#L75),
> it looks like
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds-cli/pull/31
-- Commit Summary --
* Align the startup.properties file with Karaf 2.3.11
* Remove a non-existent feature from the list of features to boot on startup
* Tentatively remove Gua
> @@ -137,13 +137,13 @@
>
> false
>
> -
> +
> @@ -39,11 +39,12 @@
> org/apache/aries/blueprint/org.apache.aries.blueprint.api/${aries.blueprint.api.
>
> org/apache/aries/blueprint/org.apache.aries.blueprint.core/${aries.blueprint.core.version}/org.apache.aries.blueprint.core-${aries.blueprint.core.version}.jar=20
>
> org/apache/aries/bl
> \ No newline at end of file
> +featuresBoot=jclouds-chef,jclouds-aws-ec2,jclouds-aws-s3
`config:list` and other commands still seem to be present
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/j
> We have already the default engine jars in the classpath, and if we throw an
> exception users won't be able to workaround it.
Given that, as you say, we _should_ have valid scripting engines on the
classpath, if we are not able to load those in the OSGi environment I would
consider that some
> so let's assume it is good to ignore it as long as the functionality we care
> about is working?
Sounds like a plan ;-)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/77#issu
> @@ -468,11 +469,6 @@ limitations under the License.
>
>
>
> -org.apache.servicemix.bundles
> -
> org.apache.servicemix.bundles.jsch-agentproxy-jsch
> -${jsch.agentproxy.bundle.version}
Can this property (i.e. `jsch.agentproxy.bundle.version`) go too?
--
> Good find.
Agreed - looks good to me, too. Thanks for taking care of that, Ignasi!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/32#issuecomment-245503249
> @@ -0,0 +1,79 @@
> +/*
> Do you plan to re-style the classes to align them to our coding style and
> change them to cleanup the code?
I think we should certainly align the code style; not sure about more
comprehensive re-writes, though. Agree that we should change the functionality
(esp. th
>private final ScriptEngine scriptEngine;
>
>/**
> * Constructor
> * @param engine
> */
> - public ScriptEngineShellTable(String engine) {
> -this.engine = engine;
> -this.scriptEngine = scriptEngineFactory.getEngineByName(engine);
> + public ScriptEngineShellTable(S
> @@ -51,9 +47,7 @@ public String evaluate(Object obj, String expression) {
> try {
>scriptEngine.put(getType(), obj);
>result = String.valueOf(scriptEngine.eval(expression));
> -} catch (Exception ex) {
> - //Ignore
> -}
> +} catch (Exception ignored) {}
>
> I've just tried a rebased version of this branch on top of the shade one and
> everything works fine! :)
@nacx Nice! Agree with most of your comments - please feel free to add commits
to this branch with any changes you think would make sense.
Thanks for taking a look, and for testing!
--
Y
> @@ -137,13 +137,13 @@
>
> false
>
> -
> +
> @@ -468,11 +469,6 @@ limitations under the License.
>
>
>
> -org.apache.servicemix.bundles
> -
> org.apache.servicemix.bundles.jsch-agentproxy-jsch
> -${jsch.agentproxy.bundle.version}
> Nope. It is used here to import the dependency to shade.
Ah, OK, t
Thanks for the updates, @nacx! [This minor
comment](https://github.com/jclouds/jclouds-karaf/pull/77/files/c2ec97b044018464a713d89b65edb342703af918#r77740874)
would be the only one I still have, but that could be taken care of during the
merge, or ignored.
Looks good to me!
--
You are receivi
> @@ -0,0 +1,10 @@
> +Apache jclouds-karaf bundles
> +
> +
> +This module provides convenience bundles to let jclouds run properly in OSGi
> environments.
> +Some of the bundles contained here are not publicly available, and others
> are just repackaged
> +to make them
+1 - looks good to me. Thanks, @nacx!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/80#issuecomment-245798899
> @@ -0,0 +1,79 @@
> +/*
> No changes to the notice file should be required as the copyright owner of
> the copied files is already the ASF.
Ah, good to know. Then I think we should be OK just to reformat and perhaps
tweak the style where applicable?
--
You are receiving this because you are
@nacx Good to close this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/78#issuecomment-246185494
>private final ScriptEngine scriptEngine;
>
>/**
> * Constructor
> * @param engine
> */
> - public ScriptEngineShellTable(String engine) {
> -this.engine = engine;
> -this.scriptEngine = scriptEngineFactory.getEngineByName(engine);
> + public ScriptEngineShellTable(S
> @@ -51,8 +52,9 @@ public String evaluate(Object obj, String expression) {
> try {
>scriptEngine.put(getType(), obj);
>result = String.valueOf(scriptEngine.eval(expression));
> -} catch (Exception ex) {
> - //Ignore
> +} catch (Exception exception) {
> + res
@nacx Reformatted and added the ISE if the requested engine can't be loaded.
Please take a look to see there's anything that still needs to be changed!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclou
201 - 300 of 4824 matches
Mail list logo
