I have an .ear file with the standard lib directory.
I have a .jar file in that lib directory. It contains UserInfoManager, which is an interface. It contains (for these purposes) no other classes. It also contains a META-INF/beans.xml file.
I have another .jar file in that lib directory. It contains a class named UserInfoResource that is a JAX-RS resource class. That class has the following inside it:
#Inject
private UserInfoManager userManager;
Next, I have an EJB .jar file at the root of the .ear file. It contains a class named UserManagerBean that implements the UserInfoManager interface. This class is annotated with #Stateless and basically nothing else (thus making it a local stateless session bean exposed via its local business interface (UserInfoManager). This .jar file also has a META-INF/beans.xml file.
Next, I have a .war file with an Application class in it and nothing else. This serves as the "mounting point" for any and all JAX-RS resources discovered at deployment time present in the lib directory. I do not declare this Java EE 6 module as a CDI bean archive since it contains no beans.
This spec-compliant arrangement fails at deployment time. Weld (the CDI implementation in GlassFish 3.1.2) claims that the injection point detailed above cannot be satisfied, as there are no known implementations of UserInfoManager available to it.
When that injection point is annotated with #EJB instead, everything works fine.
How do I get CDI to inject a local stateless session bean reference into a JAX-RS resource that is present on the classpath?
Update: Because no matter how I look at this it seems like a specification violation, I have filed a bug with a testcase attached. I encourage readers to take a look and see if they can get it to work.
Update: The workaround is to make sure that your JAX-RS classes are not bean archives, but are annotated with #ManagedBean. In addition, the {{.war}} file that serves as their mount point must be a bean archive (must have a {{WEB-INF/beans.xml}} file). Some combination of these requirements is a CDI specification violation. The following bug tracks these issues: http://java.net/jira/browse/GLASSFISH-18793
Jersey does not treat Resources as managed beans unless there is an explicit scope/#ManagedBean annotation attached to it. So, you need to annotate your resource with #ManagedBean or #RequestScoped for the injection to work.
Seems the problem occurs only if beans.xml is included in the resource jar file. When I remove it and attach #ManagedBean annotation to the resource class (instead of #RequestScoped, since #RequestScoped does not work if no beans.xml is present) it works. I am not a CDI expert, so not sure if this is as designed or a bug.
Related
I have a class in a Mule application which resides in a jar of a third party library. The library gets included in the lib folder after the project builds so it is definitely in the classpath. The class is then used in a Mule component. The applications deploys successfully in AnyPoint Studio'sembedded server. However, when the Mule component is processing data, Mule complains that it can't find the class.
As soon as the line with the following code snippet is encountered it throws the NoClassDefFoundError.
populator.put(ScanType.MRI,container);
Here is a portion of the stacktrace:
Root Exception stack trace:
java.lang.ClassNotFoundException: com.tcfg.utils.defn.Populator
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at org.mule.module.launcher.FineGrainedControlClassLoader.findClass(FineGrainedControlClassLoader.java:175)
at org.mule.module.launcher.MuleApplicationClassLoader.findClass(MuleApplicationClassLoader.java:134)
at org.mule.module.launcher.FineGrainedControlClassLoader.loadClass(FineGrainedControlClassLoader.java:119)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
I also know that this is the only instance of the class in the whole project when I use a tool to search the entire lib folder for instances of the class. This is definitely not a situation of multiple versions of the class or of other classes existing in one of the jars with a similar name. What could be the cause of this and how can I resolve it?
Even though if you add the jar in lib folder you need to manually add that jar to your class path.So, that it will be available.
They are 2 possibilities here one is there might be a need of OS specific library to be downloaded and configured in Anypoint Stduio in Run configurations like for SAP we need to point it to the DLL which windows will refer to. Giving below an example.
-Djava.library.path=C:\Users\adm-snandu\AnypointStudio\workspace\
For most of the Class Notfound errors you need to make sure the maven dependency is given in the pom.xml which takes care of downloading all the relevant libraries and referring to them during run time.
I'd like to include a resource file (e.g. some xml config file) in my bundle and make it visible to all other bundles in the container. Is it possible without using the Fragment-Host manifest header? I'd like this resource file to always be visible in the classpath of all bundles running alongside my bundle, even those that do not exist yet, but will potentially be added in future.
EDIT:
To clarify - that resource must be available passively, i.e. the other bundles should be able to find it in their classpath, and not by refering to any special API or service of my bundle.
Some more background - my environment is a bit messy but I have no control over it and cannot change its existing bundles. The only way I can modify it is by adding my own bundles. That environment includes several copies of the ch.qos.logback.classic bundle. When logback starts up, it looks for specific XML config files in the classpath. If it doesn't find any of them, then its default behaviour is to print everything to stdout with debug level. This environment was previously used to host a GUI application so it didn't matter that much before, but now I am trying to adapt it so I can use some of its functionality in headless mode. So now it becomes important to me to be able to configure it in such a way that only warning and errors are printed to the console.
In general, no you cannot do this. Class-space isolation is at the heart of OSGi, but you want to put a resource in the class loader of one bundle and make it visible to all other bundles. That's not OSGi, it's the global application classpath.
The only thing you can do to add to the internal classpath of a specific bundle is to write a fragment which attaches to that bundle. A fragment can attach to multiple host bundles, but only if those hosts have the same symbolic name, i.e. because they are different versions of the same bundle. See OSGi R6 Core Specification, section 3.14.
You did however state that the bundles you want to attach are all copies of ch.qos.logback.classic. If that means they all have that exact symbolic name then perhaps a fragment will work after all.
You can not change the classpath of other bundles this way.
What you can do is retrieve the classloader of your bundle from your bundleContext. You can give this classloader to another bundle to retrieve your resource.
ClassLoader cl = context.getBundle().adapt(BundleWiring.class).getClassLoader();
Another option is to give the other bundle the URL of the resource.
As long as the resource is on the classpath, any bundle can access the resource if it can get hold of the class loader of the bundle that contains the resource.
For example:
ClassLoader classLoaderOfBundleWithResource = ...
classLoaderOfBundleWithResource.getResourceAsStream("org/example/resource.xml");
From a maintenance and API point of view, I would not recommend exposing a resource that way. Java types are much better suited therefore. Instead, let the resource bundle export a class that gives clients access to the contents of the resource.
For example:
public class XmlDocumentProvider {
public InputStream openDocument() {
return getClass().getResourceAsStream("resource.xml");
}
}
Assuming that both the resource.xml and the XmlDocumentProvider reside in the same package, openDocument will return the resource content just like in the first example.
I am using Anypont Studio 5.3.0 and server runtime 3.7.0. I want to invoke a main() method from my component. Application is developed using Maven, SpringBoot and JPA. It sits in the jar file and have the following structure.
com
package
Application.class (with main method)
another package
Other classes
lib
other jars
META-INF
persistance.xml
MANIFEST.MF
Org
springframework boot loader and other spring classes.
when file arrives with file pattern that I detect with mule polling component I would like to invoke Java component in mule flow that has main class and all the supporting classes.
Thanks,
David
did you mavenize your Application? If yes, you can add that as a dependency in your mule project pom, which is also mavenize. But you need to make sure that the jars are added in your maven repository i.e. execute first "mvn clean install" to your java application. Otherwise, add the jars in you build path. When you are able to do those, you can create a spring bean or create a java component in mule where they could call your class with main() method.
I never came across this kind of production scenario where there is a need to call main method of java class in enterprise application. Are you sure you have only main method to access other classes, it should have initialize, spring way of injection etc. Simple answer to you question, create a mule java component and override onCall method to call Application(class).main. I will never do this kind of stuff [for sure it will give more problems based on what is being written in main method]. In general we will use main method invocation in desktop application. if possible work on (or let the application team to work on) jar file to have better initializing options
I created a JAX-WS Web Service and an EJB skeleton from a WSDL file by following a Tutorial in the Rational Application Developer for WebSphere 8.0.4 help.
It created an EJB project to contain my EJB code.
It created an EJBEar project to build an ear file.
It created a RouterWebProject to create a war file.
The RouterWebProject provides servlet information so that I can post an HTTP soap request to the servlet to be routed to my web service code in the EJB.
The EJB service code calls a class in the same EJB project that uses a ResourceBundle to read a property file with the name AppSDKExamples.properties
static {
ResourceBundle props = ResourceBundle.getBundle("AppSDKExamples", Locale.getDefault());
brokerPartnerId = props.getString("broker.partner.id");
buyPartnerId = props.getString("svc.dealer.partner.id");
sellPartnerId = props.getString("platform.partner.id");
sellPartnerId2 = props.getString("platform.partner.id2");
accountNumber = props.getString("account.number");
}
I have tried placing the AppSDKExamples.properties file everywhere I can think of but I always get a java.util.MissingResourceException.
How do I make this property file available to the EJB code?
Currently the EJB ear looks like this:
lib/AppSDKExamples.properties
lib/AppSDKExamples_en_US.properties
lib/other jar files
META-INF/MANIFEST.MF (this does not contain a class path I can't figure out how to set it.)
EJB.jar
WebProject.war
The EJB.jar looks like this:
com/activant/web/services/examples/class files that look for the property file
com/activant/web/services/iaptest/class files for the web service
META-INF/MANIFEST.MF (this has the AppSDKExamples.properties and AppSDKExamples_en_US.properties in the classpath)
AppSDKExamples.properties
AppSDKExamples_en_US.properties
The war file looks like this:
lib contains same jar files as the EJB.jar files has
META-INF (Class-Path: /lib EJB.jar)
WEB-INF/classes this folder contains both the propertie files.
WEB-INF/lib this folder contains both the properties files.
WEB-INF/ibm-web-bnd.xml
WEB-INF/ibm-web-ext.xml
WEB-INF/web.xml
Any help on this would be greatly appreciated.
Thanks.
If the properties files are at the root of the EJB, then the EJB class should be able to find the properties files. If you're running with Java 2 security enabled, then you'll need to grant FilePermission; see PROFILE_HOME/config/cells/CELL/nodes/NODE/app.policy for ${webComponent} and ${ejbComponent}.
Simply placing the properties files in EAR/lib won't work because the EAR/lib/ directory is not on the classpath, only the .jar files within it are on the classpath. It might work to add Class-Path: lib/ to the EJB jar MANIFEST.MF, but directory class paths are not required by the JavaEE spec, so I do not know if they are supported by WebSphere Application Server.
Referencing the properties files directly in the MANIFEST.MF Class-Path also doesn't work because only JARs and directories are supported (see above for JavaEE caveat regarding directories).
In general, it's probably best to remove the leading slash from /lib. It's unclear from the JavaEE platform specification whether this should refer to the lib directory in the EAR or to a directory in the root of the machine file system.
This is for Struts 1.x (I'm using 1.3.10).
I've noticed that Struts is unable to pick up resource bundles in the ApplicationResources.properties file if it is not placed somewhere in the default classpath (e.g., com.abc.SomePackage).
For instance, if I put the ApplicationResources.properties file in a custom folder /WEB-INF/strutsResources and configure the struts-config.xml thus:
<message-resources parameter="/WEB-INF/strutsResources/ApplicationResources"/>
I've read that the resources need to be on the classpath so I've also tried adding the /WEB-INF/strutsResources folder to the classpath. It still does not pick up the resource keys.
I've double-checked that the strutsResources folder is actually deployed to the server (I'm using Glassfish v3), so the file is there, it's just not being parsed.
P.S.
If you're wondering why I'm trying to do this, I just wanted to organize my code a little better ("better," IMO). Since the ApplicationResources.properties file is not really a class, I wanted to place it in a resources folder by itself.
I've checked that placing the ApplicationResources file in a package in the src directory works just fine.
Ultimately, the answer is yes. You can play some interesting games by configuring a custom className and/or factory and get messages however you want (including from a database) and so on. This allows you to customize whatever you want*.
I agree the resources aren't a class, but putting them on the classpath is a common practice, and allows resources to be loaded as a resource, e.g., from inside a jar. I'm sympathetic, but I'd leave it as-is.
*Like reversing all the text; a fun prank to play on your co-workers and QA department.
Its best leave it on the classpath.
It's stadard practise to include properties files on the classpath, especially if you're planning on packaging it up in your WAR/EAR. You're keeping it under WEB-INF so you gain no benefit from moving it off the classpath, and you'll just confuse other developers who have to work on the project and you've had to put a hack in to make this work.
If you want to keep your files external to your deployable WAR/EAR then that's a valid reason for not using the classpath. Typically this will require some configuration as part of your deployment to specify where the file is to reside.
For example specify the location using
a JVM argument (e.g. -Dprops.file=/config/myapp.properites)
lookup from a JNDI resource
use a PropertiesFactoryBean if you're using the Spring framework (I
use Spring's ApplicationContext with Struts 1 MVC)
read properties from a database writing your own
ApplicationPropertiesDAO class that initialises itself durnig your
applications bootstrap process (e.g. Spring application contact,
Servlet in web.xml, Listener in web.xml, etc)