I am trying to install EAR file with EJB module on IBM WAS 7.0.0.27 by using WSADMIN-wsInstallApp (for automation). but its getting below error
**WASX7109E: Insufficient data for install task "MapResRefToEJB.**
But the same ear file can be deployed manually by IBM console.
it looks ejb mapping reference issue. i tried so many ways but couldnt get the solution.
can anyone please suggest for a solution.
Code
target name="installEAR"
wsInstallApp ear="${earFile}" options="-appname ${application}" wasHome="${wasHome.dir}" profileName="${profileName}" conntype="${connType}" port="${port}" host="${hostName}" user="${userId}" password="${password}" /target>
Try:
options="app-name ${application} -usedefaultbindings"
If you actually want to specify bindings, you'll need to replace -usedefaultbindings with -MapResRefToEJB ..., where the options you specify need to be formatted based on the wsadmin scripting language you're using (jacl or jython). See the InfoCenter for a full AdminApp options, including -MapResRefToEJB and -MapModulesToServers.
Related
I'm using Apache Camel in a project and when I needed to use the camel-ftp component to send some files to an remote server, I've got this exception:
com.jcraft.jsch.JSchException: Session.connect: java.security.NoSuchAlgorithmException: DH KeyPairGenerator not available
I was wondering why it could be happening in my project. So, I've started a quick small project with camel-core and camel-ftp components only and I pasted the route there and it worked fine.
from("file:data/input?noop=true")
.log("Uploading file ${file:name}")
.to("sftp://www.mydestination.com:22/../opt/tmp?autoCreate=false&username=MyUser&password=MyPassword&passiveMode=true")
.log("Uploaded file ${file:name} complete.");
I'm using Apache Karaf to run OSGI Bundles (my application is one of them). I've checked in different environments but the result still beeing the exception.
I really don't know what it could be. Anyone has some ideas about what can be the possible cause of it?
DH KeyPair Generator is normally part of the JRE/JSE and should be included if your JDK (>BTW which exact JDK version are you using ?).
Given that, your error is probably due to a wrong classpath.
I suggest you to check the value of "-Djava.ext.dirs" property (and the contents of the corresponding folders), for instance:
Windows:
java -Djava.ext.dirs="C:\Program Files\Java\jdk1.6.0_07\jre\lib\ext;C:\dir2"
Unix:
java -Djava.ext.dirs=$JAVA_HOME/jre/lib/ext:/dir2
You also need to specify/modify the Karaf security provider, take a look at:
https://karaf.apache.org/manual/latest/security
I am trying to deploy EAR file on Websphere Application Server but while deploying it's showing an error.
ERROR CODE:
SEVERER: Exception org.exolab.castor.xml.ValidationException was not added to the list of sorted types.
The project was not built since its build path is incomplete. Cannot find the class file for org.exolab.castor.xml.ValidationException. Fix the build path then try building this project.
I am using Castor in my project but it's there in classpath which i am setting through Shellscript.
Thanks for help in advance.
Your dependencies need to be expressed to the application server runtime, not added to some shell variable or standalone java invocation. Either package them in your application or create an isolated shared library and associate it with your dependent application.
I have a standalone Java program which sends a message to MQ and receives a message. I need to use the wmq.jmsra.rar which has 10+ jar files in it. It works fine, if I unzip the rar and use jars in the classpath. I was wondering whether there is a way i can use this .rar file directly instead of unzipping it and adding each jar into classpath or adding the folder to classpath.
My question is related to this, but different... Is it correct or incorrect for a Java JAR to contain its own dependencies?
Thanks
Jugunu
The Resource Adapter (wmq.jmsra.rar) should be used when configuring a JavaEE application server. Details on getting that are at http://www-01.ibm.com/support/docview.wss?uid=swg21633761
Please don't unzip this to get at the component parts; instead use the MQ Classes for JMS 'allclient' jar or the OSGi bundles. Information on how to get those are available at http://www-01.ibm.com/support/docview.wss?uid=swg21683398
Those technotes give information for the latest releases. The 'allclient' is a v8 statement only - however installation of the client support packs (eg MQC75) will give you access to the JMS client.
I have a very large project with a ton of dependancies, and am getting the following exception when trying to send mail:
javax.mail.NoSuchProviderException: smtp
I know the code works because it is part of a library that is used in other projects. Does anyone know what would cause this exception to happen? I have looked through all of the jar's and the only one containing 'javax.mail' is 'mail-1.4.4-SNAPSHOT.jar'.
Is there some file/class that registeres the 'smtp' protocol, and it could be happening somewhere else in my classpath?
It's been a while since this question has been asked but it's still worth answering :
What's happening is that your mail service is using the SMTP (usually, it is even considered as the default protocol to use)protocol to send mail. No matter what concrete class you're using as mail service (might depend on whether you're working with Java EE, Spring or something else), it ends up using classes from the javamail API. In this API, in order to establish a connection to your mail server, an instance of javax.mail.Session will be created and this object will dynamically load classes that provide support for the protocol to use.
When loading the required class, in case it is not found, the ClassNotFoundException is caught and re-threw as javax.mail.NoSuchProviderException, with a message indicating the missing protocol support.
The solution in that case is to add the smtp.jar to your classpath.
With a Maven-based project, simply add the following dependency
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>smtp</artifactId>
<version>1.4.5</version>
</dependency>
I had this issue. Putting smtp.jar in classpath solved the issue.
The way I have fixed this was to remove the mail jar from the classpath. Somewhere in the classpath there exists another instance of mail.jar, and I have yet been able to find it. If anyone else runs into this problem, additional information on trouble shooting can be found here:
http://forum.springsource.org/showthread.php?t=90737
and
http://forums.sun.com/thread.jspa?threadID=5442371
I got same problem while we upgrade jboss from 4.x to 6.x.
Here Problem is setting classpath to the more number of mail.jar files(default server will take the mail.jar from its common/lib foler if it available there).
To confirm which jar file it is using, following statement is usefull.
System.out.println(getClass().getResource("/javax/mail/Address.class"));
if it is using the another jar file which you are not expecting.. set classpath to that instead which you are using. other wise remove that jar file from the above printed location.
This can also happen when you have an incorrect version of the "mailapi.jar" file in your classpath as well.
I'd recently upgraded a project to use PayPal's soap API, and PayPal's distribution contained a mailapi.jar file, which was different than the one I'd currently had in my project, and caused my app to fail when sending mail.
So for me, I just had to revert to my old mailapi.jar and I was fine.
I had this isssue right now. The problem was two javax.mail.jar in the same classpath.
I have problem with deploying JSR168 portlet using xmlaccess. I have no problem with deploy and join to conrete page but I would like to add shared library reference automatically. Is it possible?? I added shared library named 'libshared' using IBM WS console. Can I add this reference in input xml using by xmlaccess?
I don't think you can do this in xmlaccess. But you may try putting a reference to the library under the Manifest.MF file of the META-INF directory of your portlet's war file.
Or could just put the shared jar file under your /shared/ext directory. Or you could put it inside your wps.ear file. Mind you, either of these two solutions would share your library with the entire portal installation, rather than just select portlets.
You can deploy the application using wsadmin or similar and use that to update the classpath (i.e. for the shared library), you can then use xmlaccess to deploy the portlets and reference the previously deployed application - although I think this may only work in WebSphere Portal 6.1.
Give me a shout if you need further details.
I encountered this as well, a while ago... and researched it to the max, including spending some time chatting with IBM's support in various levels.
The XMLAccess protocol doesn't provide for such "system-level" configuration alongside Portlet application deployment; it can only be used to install, customize and uninstall Portlet applications and related artifacts.
If your deployment strategy involves deploying WAR files directly through XMLAccess, then you will have to manually add the shared-library to the application through the WAS admin console; this will have to be done manually because, when deploying WAR files through XMLAccess, an EAR with some random name is being created by WebSphere Portal to "host" your WAR file; hence you can't script the attachment of a shared library.
(alternatively, you may wish to add the shared library to the server's (WebSphere_Portal) classpath)
If your deployment strategy, instead, involves deploying Portlet applications packaged as EARs, then you're in a better position; you could automate the shared-library attachment as part of your EAR deployment process, then use XMLAccess to inform WebSphere Portal about the location, in the EAR, of your Portlet applications (which is what Michael mentioned above; it works in WebSphere Portal 6.0 as well).
Good luck.