I was needing to use JPA in standalone application, so I've found the example http://tomee.apache.org/latest/examples/jpa-hibernate.html as starter.
They create EJB Context via
final Context context = EJBContainer.createEJBContainer(p).getContext();
Then there's a log line:
INFO - Enterprise application "/Users/dblevins/examples/jpa-hibernate" loaded
You need to know that application name to wizard out the search string for lookup:
context.lookup("java:global/jpa-hibernate/Movies");
What makes me worry that I've found out no information on where those 'jpa-hibernate' part comes from. It either comes from artifact id, or, even worse, from the current directory name, which makes the code using it terribly dependend on context, that the developer doesn't control.
I've totally find to google out how to specify that application name so that I could use lookup that will work no matter who invokes my code and where it is copied.
How can I configure this application name?
The Embedded EJB container used in this unit test example allows to run EJBs outside a Java EE container. A good introduction/tutorial can be found here: https://docs.oracle.com/javaee/7/tutorial/ejb-embedded002.htm
It supports the same configuration files as regular EJB-jars, namely it supports the ejb-jar.xml configuration file (the module deployment descriptor). It is possible to configure the module name there, e.g.
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
version="3.1">
<module-name>myapp</module-name>
</ejb-jar>
This file needs to go into the jar's META-INF directory.
Related
There's a web application and a number of environments in which it works. In each environment it has different settings like DB connection and SOAP ends-points that in their turn are defined in properties-files and accessed in the following way:
config.load(AppProp.class.getClassLoader().getResourceAsStream(
PROPERTIES_FILE_PATH + PROPERTIES_FILE_NAME));
Thus the WAR-files are different for every environment.
What we need is to build a unified WAR-file that doesn't contain any configuration and works in any environment (for now, Tomcat instance) getting its configuration from outside its WAR-file.
The answer Java Web Application Configuration Patterns, to my mind, gives the full set of common approaches but with just few examples. The most attractive way is configuring JNDI lookup mechanism. As I can guess it allows to separately configure web-applications by their context paths. But couldn't find a simple (step-by-step) instructions in both the Internet and the Tomcat's docs. Unfortunately cannot spend much time on studying this complicated stuff in order to just meet so seemingly simple and natural demand :(
Would appreciate your links at the relevant descriptions or any alternative suggestion on the problem.
If its a case of simply deploying your WAR on different environment (executed by different OS user), then you can put all your config files in the user's home folder and load them as:
config.load(new FileInputStream(System.getProperty("user.home") + PROPERTIES_FILE_NAME));
This gives you the isolation and security and makes your WAR completely portable. Ideally though, you should still provide built-in default configuration if that makes sense in your case.
The approach we've taken is based on our existing deployment method, namely to put the WAR files in the filesystem next to the Tomcat, and deploy a context.xml pointing to the WAR file to Tomcat.
The context descriptor allows for providing init parameters which is easily accessible in a servlet. We've also done some work on making this work with CDI (for Glassfish and TomEE dependency injection).
If you only have a single WAR file deployed to this Tomcat instance, you can also add init parameters to the default global context XML. These will be global and you can then deploy the WAR file directly. This is very useful during development.
I’m developing Java EE application which has many integrations with other services. All integrations are done over remote EJB beans. So currently I have 3 or 4 EJB projects which are deployed as EARs on WebSphere to serve as mocks (since I don’t have access to real services in my development environment). What I want to do is to combine all of those mocks into one EAR package so I can have a single configuration page for mocks (return values, exceptions, etc.). So I made generalMock.ear application. The problem is now that EJB binding name is different than before.
For example the real application uses following binding name:
binding-name="java:global/company-app-calculator-ear/company-app-calculator-ejb/CalculatorSb!com.company.beans.app.calculator.CalculatorSbRemote"
But now the binding name looks like this:
binding-name="java:global/general-mock-ear/company-app-calculator-ejb/CalculatorSb!com.company.beans.app.calculator.CalculatorSbRemote"
Is there a way to change the global binding name? I have tried to create file “ibm-ejb-jar-bnd.xml” and add it to EJB mock’s META-INF folder where I wanted to change the binding name but I’s not working.
Here is the content of my “ibm-ejb-jar-bnd.xml” configuration file:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd"
version="1.0">
<session name="CalculatorSb">
<interface
binding-name="java:global/company-app-calculator-ear/company-app-calculator-ejb/CalculatorSb!com.company.beans.app.calculator.CalculatorSbRemote"
class="com.company.beans.app.calculator.CalculatorSbRemote"/>
</sescomon>
</ejb-jar-bnd>
I'm using IBM WebSphere 8.5 running on Java 1.6 EE.
The format of the java: names are defined by the Java EE and EJB specifications for portability across providers. In general, the specification does not provide a way to override these names, nor does WebSphere.
The <interface> element in the ibm-ejb-jar-bnd.xml file may be used in traditional WebSphere to define where an EJB is bound in the server context root (not a java: location), in addition to the java: location. The binding-name value must not start with java:.
Basically, you would need to change the name of your mock EAR, or set the application name in application.xml, but it seems that would only solve the problem for one of the EJB modules in your mock application.
Perhaps consider using EJB references instead of performing direct lookups in java:global. This would allow your application to always lookup the EJB reference name, which would never change. You would just need to bind the EJB reference name to either the real name or mock name depending on the environment.
Have you tried using the simple-binding-name for EJB by adding a file META-INF/ibm-ejb-jar-bnd.xml? It will look something like this for:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd
xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd"
version="1.0">
<session simple-binding-name="ejb/session/myEJBBean" name="myEJBBean">
</ejb-jar-bnd>
Now client can connect to above EJB by mapping ejb rerference to the simple binding name.
<ejb-ref name="myRef" binding-name="ejb/session/myEJBBean"/>
I have a portal server. There are number of portlets installed. I have environment configs file which is same for all portlets installed on that app server. I am using apache commons-configuration for managing from the configuration files.
Right now, each portlet/component build their own EnvConfiguration bean from these files. Obviously this is eating up more memory. I want to separate out the creation of EnvConfiguration bean and share it across all the portlets. Basically, I want to create only one bean per app server.
What are the best possible ways to do this? And how will this common beans(s) injected into the needed components?
Edit: This is a liferay application and non EAR model
Thanks
Sundar
You can use the parentContextKey web.xml param.
Here is a blog post explaining how : http://spring.io/blog/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
The idea is to package and declare the beans you want to share in a common jar (if you use Tomcat, you can put it in the server lib folder). The beans are declared in a file called beanRefContext.xml (default name, can be changed), with an id. Then you add the param "parentContextKey" in the web.xml of your webapps with the id previously mentionned.
I've just started working with Spring/java web. I'm wondering how to accomplish following scenario:
Let's say that I'm creating an application which supports file upload, uses a database connection and maybe a web service. This is an off-the-shelf system, so all the settings are customer specific and should be configured by customer's IT people on the deployment time.
More general in the web.xml file I would like to point the application working directory containing uploaded files, license key file, configuration files, other customer specific resources and maybe even fragments of spring context.
<context-param>
<param-name>workdir</param-name>
<param-value>/var/r2/</param-value>
</context-param>
In my application I would like use the workdir value in order to include configuration files ...
<import resource="wordir_param_value/settings.properties" />
context config fragments
<import resource="wordir_param_value/security.xml"/>
And how may I later use these values in the java code? What is "the best" approach in case like this anyway (off-the-shelf application config)?
Best Regards,
Alek
You can use Spring's property support for that. This allowed two different approaches:
Having a property file outside the application (at a fixed location), the admin can edit it, and the application loads it
In a Tomcat you can write properties in the application specific context.XML file
In the code use #value annotation to inject the properties in a variable.
In the spring XML file you use it with ${name}
Of course you need to configure the proprtyPlaceholderConfigurer
I just learned that I could retrieve parameters and other stuff from "ServletContext" (i.e. by overriding contextInitialized).
Reading tomcats context doc reveals that I could set parameters via web.xml (used as default values) and then overwrite them with an [context].xml file.
First question: is this a good way to set default properties and let server administrators overwrite them?
First is there an overview that shows all kinds of attributes/parameters that are available with it's tag used in tomcats context xml, the tag used in web xml, how the retrieve it from within java and a use case / example for what kind of stuff a parameter should be used?
By toying around with it I am facing the following problem: If I deploy the web app via tomcats web interface the [context].xml is completly ignored (console states that it is deployed but 2nd is null)
To cut a long story short: how to properly use web.xml and [context].xml - the link below isn't much help.
Well first off, declaring (servlet/application) context attributes via web.xml is better, as this is the official Java EE supported way, so if you declare them like this they will work when you deploy your app in other App Servers other than Tomcat.
Second, I believe the Tomcat rule for overriding param values is:
if you have a $CATALINA_BASE/conf/context.xml and you have the same attribute declared in it and in web.xml, the one in web.xml will have priority
if you have a $CATALINA_BASE/conf/context.xml as well as a context.xml file inside your application (in the META-INF directory) both with the same parameter, the one in the META-INF/context.xml will have priority.
Finally, if you have all three files decalring the same parameter, the one in the web.xml will have priority.