I am not sure how to phrase my question correctly.
Below is the background.
I have an EAR proejct which contains a Web project and an ejb project. The EJB project contains multiple MDBs and I have to add one more MDB to it for a new queue. All of the project code has been added to source control, so I will be retrieving the code from source control to create my RAD 9.0 project to add the new MDB.
When I add the application to the WAS 8.5 server, it complains about the Queue / ActSpec JNDI not being defined for existing MDBs, because it is processing the ibm-ejb-jar-bnd.xml and also processing the #MessageDriven annotations from the existing MDBs.
So my question is - Is it possible to suspend or disable the processing for existing MDBs without making temporary code changes to comment out the #MessageDriven annotation in all existing MDBs and / or commenting out the activation spec definition from ibm-ejb-jar-bnd.xml or on the other side without having to define all the Queues and Activation spec defintions for the other MDBs?
I am using Websphere 8.5 with RAD 9.0 and MDB 3.1.
Please let me know, if I need to clarify anything more.
Related
Similar to What to put into jta-data-source of persistence.xml? and How to map jpa datasources in WildFly?
However, I am asking for something that would work on all vendors or at least WildFly, Glassfish/Payara, WebSphere Application Server classic, WebSphere Application Server Liberty, TomEE. I am not looking for something that works in a Java SE Unit test.
So far I found that java:comp/env/jdbc/xxx works in WebSphere Application Server and TomEE. There's a mapping exercise (which is expected) to get it working but I cannot get the same to work on GlassFish/Payara and JBoss/WildFly.
More specifically I do not wish to use default data source because for my scenario I am actually working on two different data sources. E.g. for reference data and another for transactional.
If all of the app servers you work with are Java EE 7 compliant, you can use the default data source, which is required per EE7 spec to be available at:
java:comp/DefaultDataSource
The app server you run on ought to let you customize the configuration of the DefaultDataSource.
Since I'm familiar with WebSphere Liberty, I can point you to this doc for default data sources on Liberty:
Configuring a default data source
If you are using WebSphere traditional, as of v9.0 it supports Java EE 7, and has a default data source available out of the box (under the spec mandated JNDI name).
If you want to use the same JNDI name that works on all servers, it's best to use resource references, as explained in What is resource-ref in web.xml used for?
Basically, you would define an arbitrary JNDI name (ideally without any java:comp prefix or similar, just something like "myDatasource") and then map it to the concrete JNDI name provided by the target server.You would need to define a server-specific descriptor for each server with the mapping the if the server cannot use the JNDI directly (e.g. glassfish-web.xml for GlassFish/Payara, jboss-web.xml for WildFly, ibm-web-bnd.xml for WebSphere Classic and Liberty). TomEE seems to support references without any prefix, so it should be able to configure a datasource without any additional mapping if you choose a name without a prefix.
In JBoss, how is the sequence of the deployment phase? What is the order of object being instantiated and available to use?
Considering an enterprise application (*.ear), inspecting all deployment log (server.log) the deployment phase looks like:
All libs are deployed - .class files are loaded and available;
All *.jar modules are deployed - .class files are loaded and available;
If some *.jar is an EJB Jar, through the configuration files (Ex. ejb-jar.xml) or annotations, the JNDI tree is created;
If some *.jar has a persistence.xml file configuration, all entity and link to datasources are loaded;
All *.war modules start the deploy phase;
Through configuration files (web.xml), listeners and context-root are loaded and eventually security aspects.
Ear deployed successful.
Questions:
What about the resource adapters modules, the PersistenceContext and the EJB Pool?
When a persistence.xml is found, does a connection to the data-source and so to the DB pool start?
Since the datasource (DB) is configured in the standalone.xml or domain.xml, when happens the first connection to the DB pool? When I inject the PersistenceContext and use the EntityManager?
When the EJB pool is loaded and available to use?
Is correct to say that during the EJB jar deploy, the JNDI tree is created and then available?
When an EJB is discovered, it's loaded inside the pool (as reference to inject/lookup)?
When a .war module is deployed and ready, even if the full deploy of the .ear is not completed yet, possibly servlet or listener are started from the container.
What happens if some of this objects (listener, servlet) try to use EJBs or PersistenceContext or other objects? Are those objects available?
Is it possible to have deadlock problem and hang the deployment thread/phase?
It is possible to control the deployment order of jars and wars in application.xml using <initialize-in-order>true</initialize-in-order>
The lifecycle of the resource adapters is controlled by the connector architecture
The lifecycle of Container-Managed Entity Managers are managed by JBoss. Assuming you are injecting into an EJB using #PersistenceContext, this happens prior to #PostConstruct.
Singleton EJB initialization order can be defined using #DependsOn("OtherBean")
You can ensure the EJB endpoints are available using the deployment order in the first bullet
Not sure if it is possible to dead lock - it is far more likely that you will see a JNDI exception
I will try to address the rest of your questions:
When a persistence.xml is found, does a connection to the data-source
and so to the DB pool start?
Yes, that must happen (if no connection already is made), otherwise no table structure (DDL) could be validated or be created.
Since the datasource (DB) is configured in the standalone.xml or
domain.xml, when happens the first connection to the DB pool? When I
inject the PersistenceContext and use the EntityManager?
The answer to this question is: it depends. If your JDBC Datasource is configured with a minimum pool size MIN_POOL_SIZE>0 and has the prefill flag set to true, then WildFly will create MIN_POOL_SIZE connections to the DB server, without any deployments at all that use that datasource (after changing that flag you will need to disable/enable the datasource). Otherwise on deployment: it is created as many connections as needed (depending on what you do on deployment, but for simple applications a single one), except you have a MIN_POOL_SIZE>0 defined and the strict minimum flag is set to true, in which case AT LEAST MIN_POOL_SIZE connections will be created.
When is the EJB pool loaded and available for use?
It is available for use after deploying the EJB submodule, with all its dependencies.
Is correct to say that during the EJB jar deploy, the JNDI tree is created and then available?
I would formulate that in the following way: After (not during) it is checked that all EJBs can be deployed (e.g all their dependencies could be solved), then JNDI entries are created (in the JNDI tree). According to what I noticed, if a single EJB fails, nothing is deployed, which makes me think I am right here.
[When a .war module is deployed] What happens if some of this objects (listener, servlet) try to use EJBs or PersistenceContext or other objects? Are those objects available?
Yes, definitely. We use that feature to execute some init code from a servlet, when the WAR file is deployed (e.g to create some entities with some default values).
Is it possible to have deadlock problem and hang the deployment thread/phase?
Theoretically yes, practically no (I doubt the guys at RedHat did not think about this).
Some tips: if you use MySQL, you can check what connections are made to the server with show processlist. Otherwise if you use Linux/Unix, you can check all made connections to your DB server with netstat.
My goal is to listen on incoming datagram packets, processing them, saving the information in memory and allowing access to it via web. I'm a beginning Java EE developer. I decided to use a servlet (web access), singleton (memory storage) and message-driven bean with resource adapter (to tap into a UDP socket).
I'm trying to execute this example in Eclipse 4.2: http://www.apprigger.com/2011/06/javaee-udp-resource-adapter-example/, but am stuck with the development of the MDB.
So far, I have created a Connector Project, Dynamic Web Project and an EAR project that references them both. I'm trying to run this on GlassFish 3.x.
I'm stuck with creating a MDB inside the Dynamic Web Project. Eclipse asks for a Message listener interface, but I cannot point to the UDPMessageListener (not in classpath), even though the dynamic Web project references the connector project. Do I need to export the connector project classes as a JAR and put it inside WEB-INF/lib folder? But then my EAR would be loading these UDP classes twice - once from the connector project itself, second from inside the jar. I'm really confused how to deploy this properly.
Any help would be greatly appreciated.
We have ".sar"(Service Archive file) used in jboss. Currently we are planning to migrate the code to Weblogic.
Is there a way to deploy .sar files into weblogic.
If not directly possible, is there a work around where we can deploy the services on web logic.
In order to get the custom mbeans that are in the .sar you will need to repackage the contents as an .ear as a .sar is not standard Java EE deployment mechanism - that is a JBoss proprietary archive.
Here are some instructions on how to create, package and deploy your own service MBeans (JMX Beans) along with an example of how to use it.
https://blogs.oracle.com/WebLogicServer/entry/developing_custom_mbeans_to_ma
One thing you could do is to "substitute" or "emulate" the SAR Deployer, by creating, configuring and registering MBeans. That, AFAIK, could be done in two ways:
1) Using Standard Java EE components: that means on web tier you can use the init() method of a servlet (make sure that it is preloaded on startup) or, better, a ServletContextListener
2) Using WebLogic specific components. I'm talking about Startup classes. Simply register a startup class that creates, configures and registers your MBeans.
If you are using a web module, the first approach has the obvious advantage that you are using pure Java EE components. Although you are not using that, you can add a "dummy" web module only for doing that
Concerning what you have to do in those classes, you can choose a "from scratch" approach, by parsing the xml files that describe services and therefore manually create, configure and register MBeans or, if I remember well, the XMBeans from JBoss is something that can be reused outside JBoss but you need to check because I'm not sure
I've created a Dynamic Web Project in Eclipse. I have 2 beans, 1 #Entity and the other #Stateless. I've deployed the war to Geronimo 2.2.1 with Tomcat 6 with a warning:
Unresolved ejb reference "com.myconnection.servlet.AddServlet/srvc" in bean
"GeronimoEnc". Will attempt resolution again at runtime.
I have a form on a .jsp with an action to a servlet (AddServlet). The servlet is trying to reference my #Stateless bean (via interface). However, once I hit submit on my form to go to the servlet, I get this error:
java.lang.InstantiationException: Some objects to be injected were not found in jndi:
[javax.naming.NameNotFoundException: No EJB found for reference "com.
I also have my persistence.xml file in src/META-INF, I'm not positive if that's where it should be.
What could I be doing wrong? Thanks
Support for deploying WAR files with EJBs is fixed (but possibly not available; see the following text) in Geronimo 3.0, going by bug report 5117. Going by this report, dependency injection in 2.2.1 is likely to fail.
There is one report on the mailing list, suggesting that Geronimo 3.0 M1 might be used for validating whether dependency injection works for EJBs deployed in a web-application; this is however against a query raised with respect to a failure on the same topic. Reproducing the salient contents of the mail:
Łukasz:
Geronimo is not able to inject #EJB
into a servlet. Both SLSB and my
serlvet are packaged in war. ... By
looking at the release notes I know
that EJB 3.1 is supported only
partially. I take it that the part
that is not yet implemented in
deploying EJBs inside war package?
Ivan:
Hmm, IIRC, the EJB injection should
work in the M1 release, although it
have some bugs in EJB 3.1
integration. I would suggest to use
the latest trunk codes (just update
some codes to try to work around the
address binding issue on the building
machine, hopefully a snapshot build
could be generated in the next round),
as we got a much better TCK result
comparing with M1 release. JCDI
related packages are definitely
included in the latest trunk build.
Going all of the above, 3.0 M1 would be the release to attempt this at the moment, but there is surely some possibility of this feature being absent (given that bug 5117 does not appeared to be in the list of fixed bugs in the release notes).