Java.io.FileNotFoundException: JAR entry META-INF/wsdl/....

Hi Guys!
I am having the following problem with my webdynpro java application on CE 7.1:
In one of my dc's i am calling another dc which is an ejb. The called ejb calls a webservice.
(my dc --> ejb --> webservice)
My dc has nothing to do with the webservice. It just calls an ejb which calls a webservice.
Although I am getting a deploymentexception when I try to deploy my dc:
Caused by: java.io.FileNotFoundException: JAR entry META-INF/wsdl/....*.wsdl not found in /usr/sap/..../..wscl.war
I have no idea where I should put the wsdl file ...
Hope anyone can help me.
Cheers,
Andi

Sir
If I am not wrong you itself had mentioned that : My dc has nothing to do with the webservice. It just calls an ejb which calls a webservice.
Now I wanted to know about your workaround also request you to go at metadata file of your DC and chck that whether it contain the reference of the EJB or Webservice.
One more point : exception is FileNotFoundException so might you have manually put the reference of WSDL url/uri inside EJB xml file ??
Best Regards
Satish Kumar
Edited by: satish jhariya on Mar 24, 2010 2:20 PM

Similar Messages

JspParseException: TLD file under JAR's META-INF not found

I have succesully deployed an external generated WAR file using the Developer Studio 'Deploy View'. However, I get an exception at runtime:
com.sap.engine.services.servlets_jsp.jspparser_api.exception.JspParseException: Error in parsing the taglib tag in the JSP page. Cannot resolve URI: [http://www.some.url/some/location].
This URI is defined in a TLD file which is embeded in the META-INF of a JAR which is located in WEB-INF/lib of the WAR file.
This same exact WAR file deploys fine in Tomcat.
Could this be a bug in the J2EE Preview? Any workarounds here?
Enrique

Hello everybody
I,ve the same problem when I try to deploy a jsf application that uses Esri tags.
The war work fine In a Tomcat but when I deploy the application in the WAS 5 I get the error Error in parsing the taglib tag in the JSP page. Cannot resolve URI: [http://www.esri.com/adf/web].
I think there aren't problems with the TLD because the proyect runs fine in other environment. It seems like the WAS wasn't able to connect with the URI.
Do you know any solution ?
Thank in advance.
Fernando

Jar file META-INF content

Hi,
How can I specify what are the files will reside inside the META-INF folder while creating a jar file? What are command line options to be passed for jar utility in this regard.
Thanks in advance,

If you want stuff other than the manifest in there, just include it like any other file path. Create a META-INF directory in the tree you are going to jar.

Unable to read facec-config.xml in META-INF folder of webui-jsf.jar

Hi
I was getting following error when I placed webui-jsf.jar file in websphere 6.0 server
/WEB-INF/lib/jsf-extensions-dynamic-faces-0.1.jar!/META-INF/faces-config.xml
Digester E org.apache.commons.digester.Digester error Parse Error at line 24 column 14: Document is invalid: no grammar found.
org.xml.sax.SAXParseException: Document is invalid: no grammar found.
Do I need to add any other parser to read this file ?
Thanks
Himaja

Your classpath is polluted with different JSF implementations/versions. Clean it up.

Error with Java WebStart Signed Jars on 1.6.0_19's new Mixed Code

All,
First, we have a valid code signing certificate/keystore from Thawte that works for signing webstart jars as of update 18. For some reason, if you run our webstart application on update 19 JRE, the runtime believes that some of the jars are not signed and some are. Even though we create and sign the jars in the exact same way and after inspecting the jar the JRE believes are not signed they have the necessary signing entries/files in the manifest folder. Not sure why the signing process would work for some of our jars and not for others. There is nothing really all that different.
So, because the JRE believes some of the jars are not signed the new security warning "...contains both signed and unsigned code." pops up ( [Error Description|http://java.com/en/download/help/error_mixedcode.xml] ). If I press yes, then I get the following exception.
java.lang.SecurityException: trusted loader attempted to load sandboxed resource from https://path-to-our.jar
 at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
 at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(Unknown Source)
 at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
 at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
 at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
 at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(Unknown Source)
 at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at main.JwsMain.main(JwsMain.java:32)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at com.sun.javaws.Launcher.executeApplication(Unknown Source)
 at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
 at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
 at com.sun.javaws.Launcher.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)If I press "no" I get the following exception (I get this exception if I try to run our WebStart application with no signed jars as well, no warnings about missing certs, just straight to error)
java.lang.NullPointerException
 at com.sun.deploy.cache.CachedJarFile.findMatchingSignerIndices(Unknown Source)
 at com.sun.deploy.cache.CachedJarFile.entryNames(Unknown Source)
 at com.sun.deploy.cache.DeployCacheJarAccessImpl.entryNames(Unknown Source)
 at com.sun.deploy.security.CPCallbackHandler.assertTrust(Unknown Source)
 at com.sun.deploy.security.CPCallbackHandler.access$700(Unknown Source)
 at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
 at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(Unknown Source)
 at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
 at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
 at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
 at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(Unknown Source)
 at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at main.JwsMain.main(JwsMain.java:32)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at com.sun.javaws.Launcher.executeApplication(Unknown Source)
 at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
 at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
 at com.sun.javaws.Launcher.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)Does anyone know why this would be happening? It only occurs with the new update. We use the same keystore and process for signing all of our jars so it really doesn't make since why some of them work and some of them don't. Also, our JNLP is correct or it wouldn't work in update 18.
Edit: We've tried it on Windows XP SP3 and compiled the code using update 18 and used jarsigner both from 18 and 19 with same results.
Edited by: chenthor on Apr 1, 2010 8:44 AM
Edited by: chenthor on Apr 1, 2010 8:51 AM

Hi All,
So we've been battling this bug for a year or so now, and I've come up with a solution to the webstart bugs
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6967414
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6805618
(see the bugs for more details)
From what we can tell the bug stems from the way that the jar signers information is "cached" by webstart.
When a jar is loaded by webstart, it is represented by a CachedJarFile instance. When loading and using classes the signature for the jar is verified. The signers used is the one that is stored in the CachedJarFile instances. These "signers" are stored as SoftReferences. SoftReferences are like WeakReferences, except that they only become eligible for garbage collection when there is a small amount of available heaps space remaining and that the object is only softly reachable. (That's a pretty crude description, but it will do for now)
So what we found was happening is that when the JVM reached a certain heap size threshold and needed to allocate more heap, that these soft references (and hence the signers information) werebeing garbage collected. if you attempt to load a class after this you get the security error.
So I came up with a hack to work around this. At application startup, iterate through all of the CachedJarFile objects on the classpath and create a hard reference to each of the signers info by putting them in a static list somewhere. From our tests this seems to work. (though with the intermittent nature of the problem, it has been hard to prove conclusively, though we've had some success repro-ing the issue, by reducing the intial heap size and using VisualVM to watch for heap expansions and forcing gc's)
Below is the code for the hack, to run it just call JarSignersHardLinker.go() and it will do some sanity checks (running on webstart on java 1.6 update 19 or higher) before spawning a new thread to create hard refs for all signers info for all jars on the classpath.
import java.io.IOException;
import java.lang.ref.SoftReference;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.JarURLConnection;
import java.net.URL;
import java.net.URLConnection;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.LinkedHashSet;
import java.util.List;
import java.util.Set;
import java.util.jar.JarFile;
* A utility class for working around the java webstart jar signing/security bug
* see http://bugs.sun.com/view_bug.do?bug_id=6967414 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6805618
* @author Scott Chan
public class JarSignersHardLinker {
 private static final String JRE_1_6_0 = "1.6.0_";
 * the 1.6.0 update where this problem first occurred
 private static final int PROBLEM_JRE_UPDATE = 19;
 public static final List sm_hardRefs = new ArrayList();
 protected static void makeHardSignersRef(JarFile jar) throws java.io.IOException {
 System.out.println("Making hard refs for: " + jar );
 if(jar != null && jar.getClass().getName().equals("com.sun.deploy.cache.CachedJarFile")) {
 //lets attempt to get at the each of the soft links.
 //first neet to call the relevant no-arg method to ensure that the soft ref is populated
 //then we access the private member, resolve the softlink and throw it in a static list.
 callNoArgMethod("getSigners", jar);
 makeHardLink("signersRef", jar);
 callNoArgMethod("getSignerMap", jar);
 makeHardLink("signerMapRef", jar);
// callNoArgMethod("getCodeSources", jar);
// makeHardLink("codeSourcesRef", jar);
 callNoArgMethod("getCodeSourceCache", jar);
 makeHardLink("codeSourceCacheRef", jar);
 * if the specified field for the given instance is a Softreference
 * That soft reference is resolved and the returned ref is stored in a static list,
 * making it a hard link that should never be garbage collected
 * @param fieldName
 * @param instance
 private static void makeHardLink(String fieldName, Object instance) {
 System.out.println("attempting hard ref to " + instance.getClass().getName() + "." + fieldName);
 try {
 Field signersRef = instance.getClass().getDeclaredField(fieldName);
 signersRef.setAccessible(true);
 Object o = signersRef.get(instance);
 if(o instanceof SoftReference) {
 SoftReference r = (SoftReference) o;
 Object o2 = r.get();
 sm_hardRefs.add(o2);
 } else {
 System.out.println("noooo!");
 } catch (NoSuchFieldException e) {
 e.printStackTrace();
 return;
 } catch (IllegalAccessException e) {
 e.printStackTrace();
 * Call the given no-arg method on the given instance
 * @param methodName
 * @param instance
 private static void callNoArgMethod(String methodName, Object instance) {
 System.out.println("calling noarg method hard ref to " + instance.getClass().getName() + "." + methodName + "()");
 try {
 Method m = instance.getClass().getDeclaredMethod(methodName);
 m.setAccessible(true);
 m.invoke(instance);
 } catch (SecurityException e1) {
 e1.printStackTrace();
 } catch (NoSuchMethodException e1) {
 e1.printStackTrace();
 } catch (IllegalArgumentException e) {
 e.printStackTrace();
 } catch (IllegalAccessException e) {
 e.printStackTrace();
 } catch (InvocationTargetException e) {
 e.printStackTrace();
 * is the preloader enabled. ie: will the preloader run in the current environment
 * @return
 public static boolean isHardLinkerEnabled() {
 boolean isHardLinkerDisabled = false; //change this to use whatever mechanism you use to enable or disable the preloader
 return !isHardLinkerDisabled && isRunningOnJre1_6_0_19OrHigher() && isRunningOnWebstart();
 * is the application currently running on webstart
 * detect the presence of a JNLPclassloader
 * @return
 public static boolean isRunningOnWebstart() {
 ClassLoader cl = Thread.currentThread().getContextClassLoader();
 while(cl != null) {
 if(cl.getClass().getName().equals("com.sun.jnlp.JNLPClassLoader")) {
 return true;
 cl = cl.getParent();
 return false;
 * Is the JRE 1.6.0_19 or higher?
 * @return
 public static boolean isRunningOnJre1_6_0_19OrHigher() {
 String javaVersion = System.getProperty("java.version");
 if(javaVersion.startsWith(JRE_1_6_0)) {
 //then lets figure out what update we are on
 String updateStr = javaVersion.substring(JRE_1_6_0.length());
 try {
 return Integer.parseInt(updateStr) >= PROBLEM_JRE_UPDATE;
 } catch (NumberFormatException e) {
 //then unable to determine updatedate level
 return false;
 //all other cases
 return false;
 * get all the JarFile objects for all of the jars in the classpath
 * @return
 public static Set<JarFile> getAllJarsFilesInClassPath() {
 Set<JarFile> jars = new LinkedHashSet<JarFile> ();
 for (URL url : getAllJarUrls()) {
 try {
 jars.add(getJarFile(url));
 } catch(IOException e) {
 System.out.println("unable to retrieve jar at URL: " + url);
 return jars;
 * Returns set of URLS for the jars in the classpath.
 * URLS will have the protocol of jar eg: jar:http://HOST/PATH/JARNAME.jar!/META-INF/MANIFEST.MF
 static Set<URL> getAllJarUrls() {
 try {
 Set<URL> urls = new LinkedHashSet<URL>();
 Enumeration<URL> mfUrls = Thread.currentThread().getContextClassLoader().getResources("META-INF/MANIFEST.MF");
 while(mfUrls.hasMoreElements()) {
 URL jarUrl = mfUrls.nextElement();
// System.out.println(jarUrl);
 if(!jarUrl.getProtocol().equals("jar")) continue;
 urls.add(jarUrl);
 return urls;
 } catch(IOException e) {
 throw new RuntimeException(e);
 * get the jarFile object for the given url
 * @param jarUrl
 * @return
 * @throws IOException
 public static JarFile getJarFile(URL jarUrl) throws IOException {
 URLConnection urlConnnection = jarUrl.openConnection();
 if(urlConnnection instanceof JarURLConnection) {
 // Using a JarURLConnection will load the JAR from the cache when using Webstart 1.6
 // In Webstart 1.5, the URL will point to the cached JAR on the local filesystem
 JarURLConnection jcon = (JarURLConnection) urlConnnection;
 return jcon.getJarFile();
 } else {
 throw new AssertionError("Expected JarURLConnection");
 * Spawn a new thread to run through each jar in the classpath and create a hardlink
 * to the jars softly referenced signers infomation.
 public static void go() {
 if(!isHardLinkerEnabled()) {
 return;
 System.out.println("Starting Resource Preloader Hardlinker");
 Thread t = new Thread(new Runnable() {
 public void run() {
 try {
 Set<JarFile> jars = getAllJarsFilesInClassPath();
 for (JarFile jar : jars) {
 makeHardSignersRef(jar);
 } catch (Exception e) {
 System.out.println("Problem preloading resources");
 e.printStackTrace();
 } catch (Error e) {
 System.out.println("Error preloading resources");
 e.printStackTrace();
 t.start();
}

How to use ClassPath defined in META-INF/MANIFEST.MF in an EAR

Hi,
We have an EAR Shared Library (Name = AA) deployed in Weblogic. EAR contents are like ->
APP-INF/lib/directoryA/<<50 JAR Files>>
META-INF/MANIFEST.MF --->> Has Class Path to above JAR files, Spec Version, Impl Version etc
META-INF/application.xml
META-INF/weblogic.application.xml
This EAR is deployed as Shared Library, and our EJB (name = BB) refers to this EAR. Now the problem we are facing is that the JARs are not reachable by EJB BB. If we restructure the Shared Library project so that all the JARS are under APP-INf/lib/ directory, we are able to access the JARS from EJB BB. (This means that we are referring the shared library correctly, using "library-ref" tag correctly.
Is there a way we can specify EJB BB to look for CLASS PATH as present in the MANIFEST.MF file of the Shared Library ??
Thanks,

WebLogic specifies a separate classloader for the APP-INF/lib directory that is why it gets loaded
When you have some.jar file placed in an arbitrary directory, for example, somewhere. You can either
use application.xml, for example,
<application ...>
 <module>
 <ejb>EJB.jar</ejb>
 </module>
 <module>
 <web>
 <web-uri>Web.war</web-uri>
 <context-root>MiddlewareMagic</context-root>
 </web>
 </module>
 <library-directory>somewhere</library-directory>
</application> Or by using the manifest Class-Path entry option which requires adding a META-INF/MANIFEST.MF file with the following contents:
Manifest-Version: 1.0
Class-Path: somewhere/some.jarMore information on class loading and application packaging can be found here: http://middlewaremagic.com/weblogic/?p=6725

What is META-INF directory for ?

Hi Techies..
can any one please tell me, What is META-INF directory for ?
thanx in adv.
Regards
Nitin.V

One thing found in an 'executable' jar file META-INF directory if the manifest file:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.6.0_03-b05 (Sun Microsystems Inc.)
Main-Class: com.sdl.ArgsTest
Class-Path:
X-COMMENT: Main-Class will be added automatically by buildwhich, among other things, tells the JVM where the main class is.

Problem deploying connector: META-INF/ejb-jar.xml not found in jar file

 Has anyone seen this problem:
 I built Sun's Blackbox implementation and packaged
 it identical to the BlackBoxNoTx.rar included with
 Weblogic's 'jconnector' sample (even using the same
 ra.xml and weblogic-ra.xml). When I try to deploy
 it, the server reports:
 java.io.FileNotFoundException:
 META-INF/ejb-jar.xml not found in jar file
 I have no idea why the server thinks my connector
 is an EJB. If I deploy the BlackBoxNoTx.rar included
 with the sample, everything works without a hitch.
 The only variable that I'm changing in my BlackBoxNoTx.rar
 is that I build the Blackbox classes myself--otherwise,
 the RAR packagings are identical. Any assistance is
 greatly appreciated since I'm banging my head against
 a wall...
 Thanks,
 -jason


 I was finally able to resolve this one. On the odd chance that someone else encounters
 the same problem, here's what went wrong:
 My RAR file had two directories: 'META-INF' and 'meta-inf'. The first was created
 by the jar tool and contained the manifest.mf file. The second I created manually
 and it contained my ra.xml and weblogic-ra.xml. When I examined the RAR using
 any tools or I extracted the contents, it looked like it only contained one directory:
 META-INF (because NT is case-insensitive).
 "Jason L" <[email protected]> wrote:
 >
 >Has anyone seen this problem:
 >
 >I built Sun's Blackbox implementation and packaged
 >it identical to the BlackBoxNoTx.rar included with
 >Weblogic's 'jconnector' sample (even using the same
 >ra.xml and weblogic-ra.xml). When I try to deploy
 >it, the server reports:
 >
 >java.io.FileNotFoundException:
 >META-INF/ejb-jar.xml not found in jar file
 >
 >I have no idea why the server thinks my connector
 >is an EJB. If I deploy the BlackBoxNoTx.rar included
 >with the sample, everything works without a hitch.
 >The only variable that I'm changing in my BlackBoxNoTx.rar
 >is that I build the Blackbox classes myself--otherwise,
 >the RAR packagings are identical. Any assistance is
 >greatly appreciated since I'm banging my head against
 >a wall...
 >
 >Thanks,
 >
 >-jason

Persistence.xml under classes/META-INF makes other jar references to miss

Hi,
When I am adding persistence.xml to classes/META-INF folder where classes folder got other packages under it, classes in such packages are not getting reference to respective jar files in lib folder. So, deployment of the web project in OAS (Oracle application server) 10g fails mentioning NoClassDef found for classes from library jars referred. If I remove persistence.xml from here, the war file is getting deployed. Deployment fails even when the persistence.xml is available anywhere in classpath (like WEB-INF).
What is the reason & how to correct it?Any alternative approach like manifest or use some settings in OAS?

Hi,
To be accessible to the EJB JAR, WAR, or EAR file, a class or a JAR file must be on the deployment classpath. You can achieve this in one of the following ways:
Put the JAR file in the manifest classpath of the EJB JAR or WAR file. Do this by adding a classpath entry to the META-INF/MANIFEST.MF file in the JAR or WAR file. You may specify one or more directories or JAR files, separating them by spaces. The following example shows how the manifest file classpath entry adds the employee/emp-classes.jar file and the employee/classes directory to the classpath of the JAR file that contains the manifest file:
Class-Path: employee/emp-classes.jar employee/classes
Place the JAR file in the library directory of the EAR filethis will make this JAR file available on the application classpath and accessible by all of the modules deployed within the EAR file. By default, this would be the lib directory of the EAR file, although you may configure it to be any directory in the EAR file using the library-directory element in the application.xml deployment descriptor. The following example shows the application.xml file:
<application ...>
<library-directory>myDir/jars</library-directory>
</application>
Java EE allows for persistence support in a variety of packaging configurations. You can deploy your application to the following module types:
EJB modules: you can package your entities in an EJB JAR. When defining a persistence unit in an EJB JAR, the persistence.xml file is not optionalyou must create and place it in the META-INF directory of the JAR alongside the deployment descriptor, if it exists.
Web modules: you can use WAR file to package your entities. In this case, place the persistence.xml file in the WEB-INF/classes/META-INF directory. Since the WEB-INF/classes directory is automatically on the classpath of the WAR, specify the mapping file relative to that directory.
Persistence archives: a persistence archive is a JAR that contains a persistence.xml file in its META-INF directory and the managed classes for the persistence unit defined by the persistence.xml file. Use a persistence archive if you want to allow multiple components in different Java EE modules to share or access a persistence unit. The following example shows how to package entities in a persistence archive:
emp.ear
emp-persitence.jar
META-INF/persistence.xml
META-INF/orm.xml
examples/model/Employee.class
examples/model/Phone.class
examples/model/Address.class
examples/model/Department.class
examples/model/Project.class
Once you created a persistence archive, you can place it in either the root or the application library directory of the EAR. Alternatively, you can place the persistence archive in the WEB-INF/lib directory of a WAR. This will make the persistence unit accessible only to the classes inside the WAR, but it enables the decoupling of the definition of the persistence unit from the web archive itself.
Regards,
Vinay

Error while reading 'META-INF/weblogic-cmp-rdbms-jar.xml

Hi,
I am getting an error running appc. I am upgrading from wl 7 to wl 8.1. ejbc works
fine on wl 7. Anyone seen this before?
[J2EE:160121]Errors encountered while compiling module 'e:\dev\xstatic\tmp\xstatic_Intermediate.jar':
[EJB:011017]Error while reading 'META-INF/weblogic-cmp-rdbms-jar.xml'. The error
was:
java.lang.NullPointerException
at weblogic.ejb20.cmp.rdbms.finders.ExprWHERE.init_method()V(ExprWHERE.java:47)
at weblogic.ejb20.cmp.rdbms.finders.BaseExpr.init(Lweblogic.ejb20.cmp.rdbms.finders.QueryContext;Lweblogic.ejb20.cmp.rdbms.finders.QueryNode;)V(BaseExpr.java:230)
at weblogic.ejb20.cmp.rdbms.finders.ExprROOT.init_method()V(ExprROOT.java:89)
at weblogic.ejb20.cmp.rdbms.finders.BaseExpr.init(Lweblogic.ejb20.cmp.rdbms.finders.QueryContext;Lweblogic.ejb20.cmp.rdbms.finders.QueryNode;)V(BaseExpr.java:230)
at weblogic.ejb20.cmp.rdbms.finders.QueryContext.generateQuery()V(QueryContext.java:91)
at weblogic.ejb20.cmp.rdbms.finders.Finder.computeSQLQuery(Lweblogic.ejb20.cmp.rdbms.RDBMSBean;)V(Finder.java:1002)
at weblogic.ejb20.cmp.rdbms.RDBMSBean.generateFinderSQLStatements(Ljava.util.Iterator;)V(RDBMSBean.java:2692)
at weblogic.ejb20.cmp.rdbms.Deployer.readTypeSpecificData(Ljava.io.InputStream;Ljava.lang.String;)V(Deployer.java:479)
at weblogic.ejb20.persistence.PersistenceType.setTypeSpecificFile(Lweblogic.ejb20.interfaces.EntityBeanInfo;Lweblogic.ejb20.persistence.spi.CMPDeployer;)V(PersistenceType.java:483)
at weblogic.ejb20.persistence.PersistenceType.setupDeployer(Lweblogic.ejb20.interfaces.EntityBeanInfo;Ljava.io.File;Lweblogic.utils.Getopt2;Lweblogic.utils.jars.VirtualJarFile;)Lweblogic.ejb20.persistence.spi.CMPDeployer;(PersistenceType.java:414)
at weblogic.ejb20.deployer.CMPInfoImpl.setup(Ljava.io.File;Lweblogic.utils.Getopt2;Lweblogic.utils.jars.VirtualJarFile;)V(CMPInfoImpl.java:113)
at weblogic.ejb20.ejbc.EJB20CMPCompiler.generatePersistenceSources(Lweblogic.ejb20.interfaces.EntityBeanInfo;Lweblogic.utils.jars.VirtualJarFile;)Ljava.util.List;(EJB20CMPCompiler.java:64)
at weblogic.ejb20.ejbc.EJBCompiler.doCompile(Ljava.util.Collection;Lweblogic.utils.jars.VirtualJarFile;)V(EJBCompiler.java:245)
at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(Lweblogic.utils.classloaders.GenericClassLoader;Lweblogic.management.configuration.EJBComponentMBean;Lweblogic.management.descriptors.toplevel.EJBDescriptorMBean;Lweblogic.utils.jars.VirtualJarFile;Lweblogic.j2ee.valid
ation.ModuleValidationInfo;Lweblogic.ejb20.ejbc.VersionHelper;Ljava.util.Collection;)V(EJBCompiler.java:468)
at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(Lweblogic.utils.classloaders.GenericClassLoader;Lweblogic.utils.jars.VirtualJarFile;Lweblogic.j2ee.validation.ModuleValidationInfo;)V(EJBCompiler.java:387)
at weblogic.appc.compileEJB(Lweblogic.utils.classloaders.GenericClassLoader;Lweblogic.utils.jars.VirtualJarFile;Ljava.io.File;Lweblogic.j2ee.validation.ModuleValidationInfo;)V(appc.java:735)
at weblogic.appc.compileEJB()V(appc.java:709)
at weblogic.appc.compileInput()V(appc.java:446)
at weblogic.appc.runBody()V(appc.java:167)
at weblogic.utils.compiler.Tool.run([Ljava.lang.String;)V(Tool.java:146)
at weblogic.utils.compiler.Tool.run()V(Tool.java:103)
at weblogic.appc.main([Ljava.lang.String;)V(appc.java:961)

It is a bug for the EJB container to respond with an NPE.
(It's been fixed in v9 Beta, and it might be fixed in an 8.1 service pack but I can't recall off the top of my head). At any rate, I'm pretty sure that an EJB QL query with an empty WHERE clause will cause this. I would look for a query that ends in ' WHERE'.
-thorick

Unable to read TLD "META-INF/jsf_core.tld" from JAR file "file:

Hallo everybody :-) i've installed Workflow-Server + ARES + FormManager. When i call localhost:8080/adminui i can log in and the browser loads the next site --> it fails and says: org.apache.jasper.JasperException: Unable to read TLD "META-INF/jsf_core.tld" from JAR file "file:/C:/Adobe/LiveCycle/jboss/server/all/tmp/deploy/tmp56414LiveCycle.ear-contents/admi nui.war/WEB-INF/lib/jsf-impl.jar": org.apache.jasper.JasperException: Failed to load or instantiate TagExtraInfo class: com.sun.faces.taglib.FacesTagExtraInfo org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:5 0) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:183) org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:181) org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:418) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:483) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1539) org.apache.jasper.compiler.Parser.parse(Parser.java:126) org.apache.jasper.compiler.ParserController.doParse(ParserController.java:220) org.apache.jasper.compiler.ParserController.parse(ParserController.java:101) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203) org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322) com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87) com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200) com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117) javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) com.adobe.framework.SecurityFilter.doFilter(SecurityFilter.java:177) com.adobe.idp.um.auth.filter.PortalSSOFilter.doFilter(PortalSSOFilter.java:106) com.adobe.framework.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter .java:161) Any idea what' wrong? Thanks, Valerio

Hi Howard,
thank you for your post.
I actually new about the problems with the jvm version. Still i wanted to ask, cause there are different reports on this `java problems` and even though the 1.4.2_08 seems to be the best version (by the way this version is not to be downloaded any longer *sig*), there are people getting all installed with other versions. I couldn't find any regularity in the misbehavior of the servers while installing.
I finally achieved and got everything working ... but very slow. Loading the adminui or BAM features takes very long time (over one minute). Have you already had this delay. Any hint?
Thanks again,
Valerio

Java.io.IOException: cannot verify signature block file META-INF/MYKEY

Hello,
i have a serios problem in my company.
I developed javaws aplication running since years and now we have starting problems with actual java, it brings security warnings. This warning says this application will be blocked in further releases.
The app is signed with an old java 6 jarsigner. If I sign the jar files of the app with java 7 u45 or u40, I receive the following exception by webstart :
java.io.IOException: cannot verify signature block file META-INF/MYKEY
    at com.sun.deploy.cache.CacheEntry$10.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
    at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
    at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
    at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
    at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
    at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
do somebody have an idea what I could try to do to solve this problem?
I create the keystore on the follwoing way: C:\Programme\Java\jdk1.7.0_45\bin>keytool -genkey -keyalg RSA -alias MYKEY -keystore fspKeys -storepass xxxxxxxx

I have JRE 1.5.0_14 in the client machine.
Once this exception comes, no matter how many times I tried to relaunch the application same exception (cannot verify signature block is shown. Once i restart the server, its working fine.
Regarding jardiff, Yes. we use it.
Also, this exception is not shown on every machine which are trying to download same update. Only on few..
Any idea regarding this, please share it.
Chakri
Edited by: chakriv on Mar 22, 2010 9:02 PM

WAR meta-inf/manifest Class-Path jars use which classloader ?

If using an expanded EAR structure, my Web App requires some utility classes. I
can either put these in my :-
meta-inf/manifest.mf
Class-Path : utility.jar
OR
web-inf/lib
can contain the utility.jar
Is there any difference in terms of which classloader is used to load these classes,
the EAR/EJB classloader or the Web App child classloader ?
What is recommended ?

If have found out the answer myself by testing it :-
A jar in the meta-inf/manifest.mf e.g. Class-Path : utility.jar
will be loaded by the EAR/EJB level classloader
whereas
web-inf/lib containing utility.jar
will be loaded by the Web App level child classloader.
Dimitri Rakitine <[email protected]> wrote:
I have this question too - it appears that 6.1sp2 attempts to use Class-Path
in jars in WEB-INF/lib - what this Class-Path: is supposed to do ???
Pete <[email protected]> wrote:
If using an expanded EAR structure, my Web App requires some utilityclasses. I
can either put these in my :-
meta-inf/manifest.mf
Class-Path : utility.jar
OR
web-inf/lib
can contain the utility.jar
Is there any difference in terms of which classloader is used to loadthese classes,
the EAR/EJB classloader or the Web App child classloader ?
What is recommended ?--
Dimitri

Debug 11g ws proxy java.io.FileNotFoundException: \ade\..xmlparserv2.jar

Hi
in the new jdev 11g r1 I get this exception
java.io.FileNotFoundException: \ade\aime_xdk_407339\oracle\xdk\lib\xmlparserv2.jar
in debugging a ws proxy client . when I run it normally it works perfectly .
the old 11g jdev does it also fine
thanks Edwin

Hi,
I have the exact same problem!!!
Kind regards
Tage

How to include AdfcExceptionHandler entry from adf\META-INF\services\

I am referring to this article from Frank : http://thepeninsulasedge.com/frank_nimphius/2010/02/01/how-to-create-custom-adfc-exception-handler/
As mentioned in the blog, everything works , exception handler handles the exception , but
When I create AdfLib JAR, it does not include adf\META-INF\services\ folder
Thanks,

Frank,
Can we use AdfcExceptionHandler in our code directly with out worrying about any backward compatibility issues in future release of ADF? The reason I am asking this question is , it is from oracle.adfinternal. package and ORACLE can change it any time in future.
What is the alternative if we can not use it?
Thanks,
Rama

Java.io.FileNotFoundException: JAR entry META-INF/wsdl/....

Similar Messages

Maybe you are looking for