Can anyone explain me what are ibm-ejb-jar-bnd.xmi , ejb-jar.xml ,ibm-ejb-jar-ext.xmi and ibm_ejbext.properties. What are these files and what is configured in these files. What is the need of all these files in ejb project.
What does ibm-ejb-jar-bnd.xmi do and how it should be configured for message driven bean? Please let me know
ejb-jar.xml is the standard EJB deployment descriptor. It is where you declare which EJBs exist in your module.
ibm-ejb-jar-bnd.xmi is a file specific to WebSphere Application Server that contains binding information (where in JNDI should the EJB be bound, and where in JNDI should the EJB find the resources it uses). The ".xmi" file format is specific to EJB 2.1 and lower modules and has been replaced by the ibm-ejb-jar-bnd.xml file in EJB 3.0 and higher modules. The ".xmi" file format is in the XMI file format as generated by EMF and is barely documented (there is some basic information in the WAS_HOME/web directory of an installation, but you have to have some familiar with EMF to use it). Typically, the file is edited using RAD or modified during application deployment.
ibm-ejb-jar-ext.xmi is another file specific to WebSphere Application Server that contains various extensions to the specific (e.g., eager EJB initialization, stateful session timeouts, etc.). It is also only used for EJB 2.1 modules and lower and has been replaced by ibm-ejb-jar-ext.xml.
ibm_ejbext.properties is another file specific to WebSphere Application Server that is generated by EJB deploy and is not intended to be used by developers.
To manually configure ibm-ejb-jar-bnd.xmi, it's easiest to deploy the application, specify binding information, and then look at the result in PROFILE_HOME/config/cells/cell/applications/APP.ear/deployments/APP/META-INF/ibm-ejb-jar-bnd.xmi.
Related
I am using ActiveMQ Artemis, and I want to create a broker in war file to later deploy it on a Jetty server. However, I don't know how to configure Artemis to generate a war file.
ActiveMQ Artemis doesn't have any ability to generate a war file.
If you want to embed an instance of ActiveMQ Artemis in your web application you need to create your own war file and then add your class that creates the embedded broker instance.
For what it's worth, the broker ships with 2 examples of how to embed a broker instance using simple POJO configuration and also XML configuration. Those are in the examples/features/standard/embedded & examples/features/standard/embedded-simple respectively.
I am deploying a Spring Boot application to AWS Elastic Beanstalk using AWSCLI. I want to put an external application.properties file containing customer specification configurations (database credentials, etc.) in the same directory of the application. The application should pick up this properties file. How can I accomplish that? Are there any alternatives?
Spring Cloud Config
This project allows you to use an external, centralized configuration repository for one or more applications. You don't need to rebuild your application if a property changes. You can simply change the property in your configuration repository and even push the changes to all of your applications.
See this Getting Started Guide.
This above approach is what I would recommend for the scenario you described. I would not bother with having a separate directory on the application server for your configuration files. Spring Cloud Config is a great approach as it solves the problem you described and a few more.
You can alternatively specify them in an application-prod property like
server.port=5000
spring.datasource.url=jdbc:mysql://${RDS_HOSTNAME}:${RDS_PORT}/${RDS_DB_NAME}
spring.datasource.username=${RDS_USERNAME}
spring.datasource.password=${RDS_PASSWORD}
spring.jpa.hibernate.ddl-auto=create
and specify an environment variable called SPRING_PROFILES_ACTIVE with the value prod making the beanstalk smart enough to pick values from out there.
I have built a server api that consists aith 3 projects:
Api(an api project) that calles BL(class library) that calls Dal(class library).
Very standard.
It works perfectly locally.
Now when I publish it, the app.config of the BL disappears.
Why is it? Where can I store my configurable parameters?
Thank you very much. Tal
On your main project ASP.NET, use the Web.Config instead of App.Config to make it work.
app.config is only the name during development, once the project is built the app.config is copied to .config and this is what is used by the application when running
An asp.net application reads config from web.config so if you have an app.config it implies that your project is not a web project but a standard library or executable.
if it is a library (.dll) then you should place your config in the web.config (if the library is used by asp.net) or in the .config if its a standard executable.
Ideally your libraries should not read settings as this creates a hidden coupling between the library and config files, and it would be better to provide those configuration parameters to the classes that need them in the library externally, this then leaves the application using the library free to store them where ever is most appropriate.
How is the consumer of your library going to know that they need to add SettingX to the appsettings of their configuration file? Better for the library to require the setting value directly. So if your DAL needs a connection string then the class which wants a connection string should ask for it in their constructor. Then the application using it can get it from settings (or whereever) and pass it to the library., and the consumers have visibility of the dependency on the connection string. If the library reads it from config the consumer has no way to know that this is something they need add to the settings
So in a web app the startup would read the settings from web.config and pass them to your library but some other app using the same library could store them in a database if they wanted.
Initially we had the application server as a separate one. The communication to the Application Server from worklight servers using adapters. But currently we are moving the Application Server code to the Worklight's Server folder. We are able to call the java class (Simple java class not servlets) using HTTPAdapter. But it is difficult to communicate with the servlet (which is included in the server folder) using HTTPAdapter. Plese provide any solution?
If I understand correctly, you have put some servlet classes in your Worklight server folder. As they are Java classes they are now visible to your adapters. However servlets to be true servlets must be deployed to a JEE servlet engine, with appropriate configuration. You can deploy Servlets (in a WAR file of their own) as a separate JEE application on the same server as Worklight, but you cannot package them inside Worklight itself.
edited in response to your clarification:
You want to consolidate your servlet application, which is providing data accessed via the worklight adapter onto the same server instance as the worklight server. The Worklight Server is actually a JEE application deployed to one of the supported JEE servers, usually WebSphere Liberty which is supplied with Worklight, and the Worklight Server is in fact packaged as a WAR file. Your Data Provider servlet will also be packaged as a WAR file, all you need to do is deploy that WAR to the Liberty server you are currently using for worklight.
If you are doing this is development in Worklight Studio you can find the relevent folders by looking under "Worklight Development Server". You can drop the WAR into the apps folder and if necessary edit the server.xml to add any extra configuration:
WorklightServerConfig/servers/worklight/server.xml
See: http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websphere.wlp.nd.doc/ae/twlp_dep_war.html
a second edit to try to explain again.
The Worklight Project represents your application, when you deploy to the Worklight Server a WAR file is created let's call this MyApp.WAR, that can be deployed to a WebSphere Application Server, inside Worklight Studio you are automatically given a WebSphere Liberty Profile. That Liberty Profile's configuration can be seen in the Project Worklight Development Server. Key Idea here you have one App Server that Liberty Profile, and you deploy the MyApp.WAR file to create what we usually call the Worklight server, it's the MyApp.WaR that is serving your Worklight console. That WAR file is derived from the contents of your project's server folder, this folder's name is a little misleading it's not the "server" itself it's your project-specific WAR information.
Now in addition you want to run a Servlet you already have packaged as a WAR file, let's call this Data.WAR. The key point is that you need to run Data.WAR on the Worklight Developmennt Server, the Liberty Profile. You are not including this DATA.WAR file into your project's server folder, that would effectively put DATA.war inside MyApp.WAR. Instead all you need to do is put Data.WAR in the Worklight Developmennt Server's apps folder and adjust the server.xml.
So: Step 1. Get Data.WAR running in the Development Server. Verify that from a browser you can call your expected servlet. Note the URL that works. Do not make any attempt to use your adapter until you have verified this.
Step 2. Adjust you adapter to call that URL.
Could not find endpoint element with name 'wsHttp' and contract 'Tridion.ContentManager.CoreService.Client.ISessionAwareCoreService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element
while accessing:
ISessionAwareCoreService client = new ChannelFactory("wsHttp").CreateChannel();
When you write software using the Tridion core service, you need to do one of two things:
Create a configuration file for your application that contains the correct WCF configuration
Set up the WCF settings in your software by writing code.
If you are creating a config file, then you can start by copying the default one provided by Tridion. On my system this is at C:\Program Files (x86)\Tridion\bin\client\Tridion.ContentManager.CoreService.Client.dll.config
If your core service client is running on the Tridion server itself, that will probably be sufficient. If you are "off the box" then you'll need to edit it appropriately.
If you want to set things up from code, a good place to start is this recipe in the Tridion Cookbook. (There's also a recipe for the non-code approach.)