I have created an ESB application which fails to execute the flow because the library js-engine-1.1-jdk14.jar is present in Mule Runtime server 3.9.0 Community Edition.
So I want to know how can I remove this jar js-engine-1.1-jdk14.jar from the mule runtime server in Anypoint Studio so that my flow can execute properly.
Error is :
com.sun.phobos.script.util.ExtendedScriptException:
org.mozilla.javascript.EcmaError: ReferenceError: "load" is not
defined. (#3) in at line number 3
You should never remove a jar from the runtime, under risk of breaking it. Same with thing with overriding or updating them. Instead, at least for Mule 3.x, you have to adapt your application to the libraries provided.
You didn't mention what was the error or problem why it fails. If the application is using a different and incompatible version than the one provided, then it needs to be modified to use the same one than the runtime.
In the EE you have the alternative method of fine grained class loading control though it is not useful for every use case.
The lib can be found inside plugins/org.mule.tooling.server.3.9.0_6.4.0.201710051922\mule\lib\opt. We can remove it from there.
Related
I'm working with IBM MobileFirst 7.1, and trying to get integration for ISAM working. So far I've been working with the sample application provided here, but I'm having issues with it when working with 7.1 MobileFirst client-side tools.
If I download and unzip the v3.5 integration package, and unzip the ISAMforMobileFirst test project, and I build it with the v7.0 CLI, it builds successfully. However, if I build it with the v7.1 CLI, I get an error like this:
Migrating project from version 7.0.0.00.20150211-0917 to version 7.1.0.00.20150807-0630.
[Error:
BUILD FAILED
/Applications/IBM/MobileFirst-CLI-7.1/mobilefirst-cli/node_modules/generator-worklight-server/lib/build.xml:497: com.worklight.upgrader.UpgradeEngineException: FWLPL0019E: Migrating the ISAMforMobileFirst project from version 7.0.0.00.20150211-0917 to version 7.1.0.00.20150807-0630 has failed because Cannot parse /Users/ferriera/Downloads/AmWorklightAdapter-3.5/sample/ISAMforMobileFirst/server/conf/authenticationConfig.xml
at com.worklight.upgrader.WLUpgradeEngine.upgradeProject(WLUpgradeEngine.java:271)
at com.worklight.upgrader.ant.UpgraderTask.execute(UpgraderTask.java:100)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
A colleague also sees this exact error in MobileFirst Studio 7.1 (in Eclipse) so I'm guessing it's not a CLI-specific error.
I would assume that support for something has changed in authenticationConfig.xml in 7.1, and this hasn't been reflected in the migrator.
A few questions:
Is ISAM integration supported in 7.1?
Whilst I realise the sample application isn't technically supported in 7.1, if/since ISAM integration is, in theory it should be feasible to make it work. What's changed in authenticationConfig.xml syntax?
Edit: looks like the failure happens due to the following: <parameter name="embedded-pki-bridge-ca-p12-file-path" value="<file-path>"/> and more specifically: <file-path>.
Change it to the actual file path, and it will not fail importing.
Nothing in the authenticationConfig.xml file is about ISAM really; it's all declarations of realms, login modules, security tests...
There is a clear failure, and a PMR should be opened.
As for a local workaround, I've attempted to remove segments in the file that I thought might trigger it, but did not succeed to find a pattern that causes it...
Mule id plugin Url is not working. Can any one help to get an alternate url for the same plugin.
http://dist.muleforge.org/mule-ide/updates-2.1.x/
This url is also mentioned in the below tutorial.
http://www.mulesoft.org/documentation-3.2/display/32X/Installing+Mule+ESB+3+and+the+Mule+IDE
Below is the error which i am receiving after accessing this url in browser.
Network Error (tcp_error)
A communication error occurred: "Connection refused"
The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.
For assistance, contact your network support team.
Mule version 2X uses the url :- http://dist.muleforge.org/mule-ide/updates-2.1.x/ and for Mule version 3X the url :- http://www.mulesoft.org/documentation-3.2/display/32X/Installing+Mule+ESB+3+and+the+Mule+IDE is being used.
You need to check the version of Mule you are using and need to use the url that matches your Mule version.
If you are using Mule Enterprise edition you can take support from the MuleSoft Support, else if you are not using Enterprise you can post the issue in their forum
I seriously doubt there is still support for the Mule IDE, it was deprecated in favour of Mule Studio (that then became Anypoint Studio).
Do you really need to do a new development on Mule 2.x? If not, please consider using the much better Anypoint studio. If you need to stick to the 2.x version, you could just use a vanilla version of eclipse that will take care of the the autocompletion and then export to the apps directory of a running mule container for a hot deployment.
I'm trying to create a Web Service Client using the option WSDL URL in NetBeans IDE 7.0. Unfortunately, it is not able to create one and is failing with the following error:
Saxon cannot write a DOMResult unless saxon9-dom.jar is on the classpath
After seeing this error message, I even confirmed whether saxon9-dom.jar is added to the Libraries in NetBeans. Yes, it is already available. I don't know why still the error is appearing. Can somebody let me know what is going wrong?
I'm trying to create web service client for this WSDL. I'm choosing JAX-WS Style in Client Style option while creating New Web Service Client in NetBeans.
UPDATE:
After googling, I read about some clues from the following 2 places:
1) http://www.mail-archive.com/fop-dev#xmlgraphics.apache.org/msg09659.html
This is due to the new event-handling framework that has been added
after 0.95. The step in the build process that generates the resource
files for the various messages, seems to require a writable DOM
implementation.
As the message indicates, Saxon offers such an implementation in a
separate JAR, which needs to be added to the classpath when building
FOP Trunk.
2) http://xmlbeans.apache.org/sourceAndBinaries/index.html
Using XPath/XQuery requires an additional download of
saxonb9-0-0-4j.zip and placing on the classpath of the files
saxon9.jar and saxon9-dom.jar that it contains. The zip is available
here. We cannot distribute this zip in a binary distribution due to
licensing issues.
So, I thought of changing saxon9-dom.jar in the classpath. I was using saxon9-dom.jar from saxonb9-1-0-8j.zip before, but when I tried to include saxon9-dom.jar available in saxonb9-0-0-8j.zip, now this error has disappeared and am getting a different error now as shown below. Any ideas/clues?
Web Services are described using WSDL files, so in order to create a Web Consumer for them you'll have to specify the WSDL url.
You can obtain it by adding ?WSDL ar the and of the url.
For example:
CrudService.asmx becomes
CrudService.asmx?WSDL
(It you have tested your web service and it appears ?Tester at the end, just replace it with ?WSDL).
I try to use the com.google.gwt.user.server.Base64Utils to encode my image on the server side, but the compiler giving me this info (later causing an error):
*"[INFO] [ERROR] Errors in 'jar:file:/C:/.../....rpc-1.12-SNAPSHOT.jar!/...////PictureFileDTO.java'
[ERROR] Line 46: No source code is available for type com.google.gwt.user.server.Base64Utils; did you forget to inherit a required module?"*
Using GWT 2.1.0 and Maven in Eclipse.
What am I missing here? Any ideas?
The gwt-user.jar is the library you develop against, regardless whether you develop client-side or server-side code. It contains everything, UI widgets, utility-classes for the client-side, as well as utility-classes for the server-side.
The gwt-servlet.jar is used at runtime. I'm not talking about development mode, but about running your web application on some web server (Apache, IIS...). The gwt-servlet.jar contains the classes that are needed by the web server to run server-side GWT stuff.
So yes, the Base64Utils class is in both JAR files. Nevertheless it is not available for client-side development.
If you need something that work on both sides, check this out:
http://www.source-code.biz/base64coder/java/
I'm trying to call a web service in my back end java code when it's
running in hosted mode. Everything loads fine, the GWT RPC call works
and I can see it on the server, then as soon as it tries to call an
external web service (using jax-ws) the jetty falls over with a
Internal Server Error (500).
I have cranked the log all the way up to
ALL but I still don't see any stack traces or cause for this error. I just get one line about the 500 Error with the request header and response.
Does anyone know if the internal jetty keeps a log file somewhere, or
how I can go about debugging what's wrong?
I'm running GWT 1.7 on OS X 10.6.1
Edit: I know that I can use the -noserver option, but I'm genuinely interested in finding out where this thing lives!
From the documentation:
You can also use a real production
server while debugging in hosted mode.
This can be useful if you are adding
GWT to an existing application, or if
your server-side requirements have
become more than the embedded web
server can handle. See this article on
how to use an external server in
hosted mode.
So the simplest solution would be to use the -noserver option and use your own Java server - much less limitations that way, without any drawbacks (that I know of).
If you are using the Google Plugin for Eclipse, it's easily set up in the properties of the project. Detailed information on configuration can be found on the official site.
Edit: you could try bypassing the Hosted Mode TreeLogger, as described here: http://blog.kornr.net/index.php/2009/01/27/gently-asking-the-gwt-hosted-mode-to-not):
Just create a file called
"commons-logging.properties" at the
root of your classpath, and add the
following line:
[to use the Log4j backend]
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
[to use the JDK14 backend]
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
[to use the SimpleLog backend]
org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
Edit2: the trunk of GWT now also supports the -logfile parameter to enable file logging, but it probably won't help in this case, since the problem lies in the way the Hosted Mode treats the exceptions, not the way it presents them.