How to control glassfish module startup order - module

I have several web modules. There are dependency between them, say during startup, module B will use MBean exposed by module A. How to configure glassfish to enable it start them by specific order? Or is it possible to configure it to load them concurrently.
I searched quite a lot via google, but not result.
BTW, I'm using glassfish-2

This post indicates that initial deployment order defines the startup order. I have found (on Glassfish 3) that the order is stored in domain.xml so you can swap entries in there.

If they're part of the same EAR and you're willing to move to Java EE 6 and thus GlassFish 3, here's a solution for you : http://blogs.oracle.com/alexismp/entry/module_initialization_order_in_java

GF 3.1 seems to reset the order after editing the domain.xml.

Related

Mule startup order for applications

So, i have three mule applications where one needs to be started before the other two. And I start mule as a windows service. I found this site and follow the example by putting
wrapper.app.parameter.1=-app
wrapper.app.parameter.2=%MULE_STARTUP_ORDER%
in wrapper.conf. where MULE_STARTUP_ORDER is an system variable containing App1:App2:App3
But when i look in my mule.log after staring the service app2 starts first followed by app3 and app1 is last.
And I use mule standalone 3.7.0.
Anyone have any idea what I am doing wrong/missing?
Try setting the list of applications directly in wrapper.conf in case the service has no access to the system environment variable from Windows. Also try using higher numbers for the parameters like the example in the KB article you referenced. Low numbers might be get overridden by other parameters.
Example:
wrapper.app.parameter.10=-app
wrapper.app.parameter.20=app1:app2:app3

Cannot install Glassfish update tool

Firstly, there are related posts:
GlassFish Server update center installation times out
Java EE 7 updatetool installation fails
I got my Java EE 7 SDK (Update 3) from here: http://www.oracle.com/technetwork/java/javaee/downloads/index.html
I have tried each of the solutions in the above posts and here: https://blogs.oracle.com/dipol/troubleshooting-glassfish-update-center
Including:
In the cmd prompt running set PKG_CLIENT_CONNECT_TIMEOUT=300 and set PKG_CLIENT_READ_TIMEOUT=300 before updatetool in C:\glassfish4\bin\updatetool.bat (c:\glassfish4 in my install directory - all settings were default, including install update tool...).
Set above mentioned timeout to much larger values - doesn't appear to make a difference at all, the process basically bombs immediately.
Running C:\glassfish4\bin\updatetool.bat many times.
Triple checking that I didn't somehow configure a proxy server in my sleep.
Use the update tool via the Glassfish admin console at http://localhost:4848 (seems to show no available update or add-ons, which seems odd..)
I get the following screenshot when I run C:\glassfish4\bin\updatetool.bat
I have no idea why the error would be proxy related, unless it happened to be something on their end. Interestingly, If I go directly to the URL mentioned (via Chrome) I get the following page:
What could possibly be going wrong here?
The updatetool was a commercial feature of Oracle GlassFish. Any update functionality relied on Oracle providing a site where updates could be hosted. Since Oracle GlassFish is no longer supported, this site no longer exists so the updatetool won't work any more.
Rather than downloading GlassFish from Oracle, you should download it from the official open source site, hosted on GitHub. Alternatively, if you really do need support, you could try Payara Server which is open source, and derived from GlassFish, but has support available (disclaimer: I work for Payara)

Integration of log4j v2 into JBoss 7.1.1

I am curious how should I force jboss 7.1.1 to use Apaches Log4j 2 instead of org.jboss.as.logging, because I would like to do some performance comparison of log4j2 and jboss.as.logging (I have given up on log4j because it seems to have similar performance as jboss.as.logging).
Log4j2 Official website: http://logging.apache.org/log4j/2.x/
I suppose I need to create a new module for the log4j2 library in jboss modules.
Then what? Do I need any changes in standalone.xml? Any changes for jboss-deployment-structure.xml?
How can I tell jboss where to search for the log4j2 library?
Thanks for any suggestions. I am a bit stuck here.
JBoss Logging is just a logging facade similar to slf4j. JBoss AS 7 uses JBoss Log Manager for it's log manager.
Without changing some code you and removing the logging subsystem you cannot use another log manager like log4j2 for the server wide log manager. You'd have to make some changes here and remove the STDIO stuff. It's probably not worth the effort TBH.
JBoss Log Manager is fairly fast. You could try using an async-handler to see if that helps performance at all. It probably won't make a significant difference though if you're just using a standard console-handler and file-handler of some sort.
Some ruff measuring results between JBoss Default Logging and Log4J 2 (by configuring it native and therefore skipping the LogManager), by logging with 10 Threads at the same time:
JBoss Default Log Async Rolling File Appender -> 200.000 Logs/minute
Log4j 2 ASync File Appender -> 5.000.000 Logs/minute
These are really only ruff results, the second case uses a different logger and does not use the Log Manager, these things must be measured independently ... maybe I will do that too. Nevertheless, the bottom line is that default logging is damn slow.

Deploy EJB2 on Weblogic 10.3

I try to deploy ejb2 on weblogic 10.3 but I face a problem the deployed ear can't see new methods added to any ejb session bean. I added the method to remote interface and I added the implementation to bean class. I hope anyone can help. Thanks
I believe WebLogic 10.3 supports EJB3, so you'll have to do some modification. You already have the evidence to prove it.
As you say the old EJBs are working, but it's not reflecting updated methods - I think this is cached.
Drill down on your server to the following path or a similar one
DefaultDomain\servers\DefaultServer\cache\EJBCompilerCache
There will be many folders in there with random names like ff7i19ot3cg6 and l443b5vws35h
Clear out all these folders and redeploy the app

Connecting a remote JMS client to GlassFish 3

I am trying to connect to GlassFish 3's JMS service from a standalone remote client. However I am getting a java.lang.ClassNotFoundException: com.sun.messaging.jms.ra.ResourceAdapter. Any ideas on how to fix this?
Here's my setup so far:
Glassfish 3 JMS Service in LOCAL mode (I am assuming that EMBEDED mode will not work in this case because it bypasses the network stack)
JNDI properties are specified as follows:
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs=com.sun.enterprise.naming
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
gf-client-module.jar (in GLASSFISH_HOME/modules) added to the standalone application's classpath. Also tried adding other jars present in the modules directory (such as jms-core.jar), but still getting the same ClassNotFoundException.
Any help would be much appreciated.
Instead of using all of the individual Glassfish jar files that you might need (such as gf-client-module.jar, imqjmsra.jar, and imqbroker.jar), the preferred method is to use the gf-client.jar file. It can be found at $GLASSFISH_HOME/lib.
There is more information at http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB. That document pertains to using EJBs in standalone clients, but the solution is the same for using JMS.
Ok. I found a solution. See here for details, but the short answer is that I needed to add two jars to the classpath: imqjmsra.jar and imqbroker.jar. These were available inside a rar called imqjmsra.rar which can be found under glassfish's mq directory. I had to extract the two jars from this rar!
This is the complete list of client jars for glassfish 3 :
auto-depends.jar
deployment-common.jar
glassfish-corba-internal-api.jar
internal-api.jar
management-api.jar
bean-validator.jar
dol.jar
glassfish-corba-newtimer.jar
javax.ejb.jar
orb-connector.jar
common-util.jar
ejb-container.jar
glassfish-corba-omgapi.jar
javax.jms.jar
orb-iiop.jar
config-api.jar
ejb.security.jar
glassfish-corba-orb.jar
javax.resource.jar
security.jar
config-types.jar
glassfish-api.jar
glassfish-corba-orbgeneric.jar
javax.servlet.jar
ssl-impl.jar
config.jar
glassfish-corba-asm.jar
glassfish-naming.jar
javax.transaction.jar
transaction-internal-api.jar
connectors-internal-api.jar
glassfish-corba-codegen.jar
gmbal.jar
jta.jar
container-common.jar
glassfish-corba-csiv2-idl.jar
hk2-core.jar
kernel.jar
As mentioned in the Ivan A Krizsan's notes for the EJB certification, and depending on the Glassfish version, this should be enough:
GlassFish 3 (and GlassFish 4 too, I've just tested it): $GLASSFISH_HOME/lib/gf-client.jar
GlassFish 2: $GLASSFISH_HOME/lib/appserv-rt.jar and $APS_HOME/lib/javaee.jar