I deployed a component having SOAP webservices in an Open Nebula recently. After deployment, we noticed the WSDL responses to be having a different namespace prefix
Problem: AlertBot was expecting to see
<ax25:response>TEST</ax25:response>
but, it started seeing
<ax21:response>TEST</ax21:response> instead. We compared the build between the new and old host, and saw no differences in config files, or the java package.
We need to figure out why the ax25 part namespace prefix got changed to ax21 on the new host
NOTE: We use AXIS2 library for generating WSDLs
Related
I am building a dropwizard service which will connect to multiple data sources including mySQL and Elasticsearch. All the mySQL settings can be defined in the yaml config file which gets read in after running from the commandline.
But what about other settings that I need to read in for other data sources that I will connect with myself, for example Elasticsearch? Where can I define those settings?
I thought I could add another commandline Command - which I tried, but I can only run a single command (from the commandline) at a time - so I can't seem to run both the 'server' command as well as my custom command, 'custom' which is followed by the my own config file for elasticsearch.
How can I introduce settings either individually or from a file - which are defined at run time (not hard coded)?
Thanks
Anton
Check out the Dropwizard Core documentation on adding custom configuration.
You'd create an ElasticSearchFactory class similar to the MessageQueueFactory in the example, reference this in your Configuration (that's in turn referenced in your Application), and then the options you need can be added to your main yaml configuration.
I couldn't find answer to this in Dart documentation.
My application's server-side is driven by Spray and by convention static files are stored in /webapp folder. When I try to build Dart project I get following error
C:\work\externals\dart-sdk\bin\pub.bat build --mode=release
Your package must have a "web" directory, or you must specify the source directories.
How can I change it from web to webapp ? My pubspec.yaml looks like this
name: dart_spray_example
description: A sample Dart/Spray application
dependencies:
browser: any
Here is layout of my application right now
You just pass it as an additional argument.
pub build --mode=release webapp
but I would expect troubles doing it this way because only some top-level directory names are compliant with the pub package layout convention.
pub build --mode=release example
would be fine.
It might be easier to just use web as the source directory and move the generated output to webapp. I'm aware that this can cause problems during development but I would expect it to be easier to fix the development setup instead of the build setup.
Using frameworks like Angular and Polymer which make heavy use of transformers have a strong dependency on the package layout convention.
I'm new in JAVA\Grails\Groovy. Just began to create simple apps.
I've got a task to create grails app that:
1) shows a list of source zip files on a remote server, that is available by FTP and SSH
2) shows a list of destination remote servers with predefined target folders, that are available only by SSH
3) after choosing source zip and dest server it copies zip to target server\folder and unzippes. Progress bar must be shown.
4) performs some additional commands, such as ls or something like that
All configurations must by either in config files or in the database.
No information should be hardcoded in app.
Please help me to choose approach, plugin or framework.
Any help would be appreciated
I've used JSch a lot for SCP file transfer and remote exec using SSH and works very well. You could use it directly like you would in a Java app, by adding a dependency for the jar in BuildConfig.groovy
compile 'com.jcraft:jsch:0.1.51'
but the most trivial Google search I could manage that included "Grails" and "SSH" tells me that there's this plugin which looks great, and this plugin which also looks great, and this blog post which looks great, and also this plugin which uses a different library but also looks great.
Those options cover the ssh and scp/sftp parts, and you can use the JDK support for Zip files, e.g. java.util.zip.ZipFile and the other related classes in that package, to unzip the files. The rest is pretty straightforward, but if you need more help ask more questions (one question per question).
Suppose I have a Grails application named myCoolApp.
Furthermore, suppose I have defined some basic properties in grails-app/conf/Config.groovy and grails-app/conf/DataSource.groovy under the test and production profiles.
Config.groovy is set to merge with the following .groovy external configuration file, if found at all:
grails.config.locations = ["file:${userHome}/.grails/${appName}-config.groovy"]
Finally, I have also defined, inside an external testing server, such a file, under a local *NIX user path:
/home/appServerTestUser/.grails/myCoolApp-config.groovy
Sadly, I find that for some reason, the external .groovy file's properties are not being merged when a Tomcat instance starts up.
What options do I have to make Grails tell me: "Oh, yes, I found your external config file at: /home/appServerTestUser/.grails/myCoolApp-config.groovy" and these are the properties I merged into Config.groovy?
Thanks!
File-based paths don't make much sense in a deployed app. It could work when deploying on your dev machine for testing, but will likely fail on any other machine. And it'll probably fail locally even if configured with the correct path since the process will like run as a different low-priviledge user.
You can use absolute paths, e.g. /etc/myapp/path/to/file, but this tends to couple deployment to filesystem structure, so if you develop in Windows and deploy on Linux it'd be tricky to get them both working.
So the best bet for Tomcat deployment is to use the classpath syntax. You can specify multiple files and it will load all that it finds, so I usually have one entry for local dev and one for the deployed app:
grails.config.locations = [
"classpath:${appName}-config.groovy",
"file:./${appName}-config.groovy"
]
I delete the entries for .properties files because Groovy syntax is so much more flexible, but use them if you like. I also keep the dev files in the project root (and exclude from source control).
So when deploying, name the file correctly (different apps will have different files, so no clashing there) and put them in Tomcat's lib directory. This is in the classpath, and so the classpath: entry will see it.
I created an .eba file (enterprise bundle archive) that contains one osgi bundle having a apache camel route (Java DSL). The camel context definition is done via a blueprint xml file. When I tried to deploy the .eba file in Websphere Application Server 8.5, I got the following exception:
org.apache.aries.application.modelling.ModellerException: CWSAL0126E: An exception occurred while modelling bundle ib-base_0.0.1.SNAPSHOT: org.apache.aries.application.modelling.ModellerException: org.osgi.service.blueprint.container.ComponentDefinitionException: Unsupported node namespace: http://camel.apache.org/schema/blueprint.
My blueprint xml file is as follows:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:camel="http://camel.apache.org/schema/blueprint"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-
blueprint.xsd">
<camel:camelContext id="cbrContext" trace="false">
<camel:packageScan>
<camel:package>a.b.c.d</camel:package>
</camel:packageScan>
</camel:camelContext>
</blueprint>
I am not too sure why this fails in Websphere. The same .eba file gets successfully deployed in Karaf 3.0.0-SNAPSHOT. (This version of Karaf uses Aries Blueprint version 1.0.0).
I guess the same is used or a forked version of the Aries Blueprint 1.0.0 is used in Websphere 8.5.
As per the OSGi specs, any blueprint extension handlers for custom namespaces like camel: are retrieved from the OSGi Service Registry under the key (osgi.service.blueprint.namespace). The value element tells the actual namespace uri .
eg:
<service interface="org.apache.aries.blueprint.NamespaceHandler">
<service-properties>
<entry key="osgi.service.blueprint.namespace" value="http://camel.apache.org/schema/blueprint"/>
<entry key="osgi.service.blueprint.namespace" value="http://camel.apache.org/schema/blueprint/cxf"/>
</service-properties>
<bean class="org.apache.camel.blueprint.handler.CamelNamespaceHandler">
</bean>
</service>
I am not too sure why IBM does not honor this spec.
Another interesting point to ponder over is the fact that when I tried to create a blueprint .xml file using Websphere Application Developer Tool, it shows only 4 extensions as shown below:
IBM Blueprint Extension
JPA Blueprint Support
Blueprint Transaction Support
Blueprint Resource Reference support
I ensured that both the camel-core and camel-blueprint bundles are deployed in the internal repository in websphere.
I tried to deploy the .eba file as an asset.
Not too sure, if I have missed something. I would be glad if someone can point me in the right direction.
best regards,
Sriraman.
WebSphere does not support custom namespace extension (other than the one provided by IBM). The main reason being it runs on Aries (Blueprint container) isolated runtime. There are two options
Use camel api instead of blueprint tags
Use other container (for e.g. Karaf) which supports custom namespace extension
Karaf is a friendly container for camel.