I am using JBoss5.1.0.GA.
How to know whether is this a EAP version or normal? Actually I am stuck in this issue. So trying to solve it by seeing comments.
Assuming you have the required permissions to execute the command
$JBOSS_HOME/bin/jboss-cli.sh --connect
# next two lines to enter in the JBoss command line interface
/:read-attribute(name=product-name)
/:read-attribute(name=product-version)
Or you can use JConsole and explore the jboss.as:server MBean the attributes have the names
productName
productVersion
Or (might not work with 5.1.0 GA, was tested with a newer version)
cat $JBOSS_HOME/modules/system/layers/base/org/jboss/as/product/eap/dir/META-INF/MANIFEST.MF
The JBoss EAP 5.1 is provided as a bundle, which contains not only the application server but also other components:
jboss-eap-5.1/
jboss-as/
mod_cluster/
picketlink/
resteasy/
seam/
All JAR files are signed in the EAP. You can find the information about signatures in META-INF folder:
$ unzip -l jboss-eap-5.1/jboss-as/lib/concurrent.jar
Archive: jboss-eap-5.1/jboss-as/lib/concurrent.jar
Length Date Time Name
--------- ---------- ----- ----
25286 2010-05-04 17:19 META-INF/MANIFEST.MF
25376 2010-09-14 21:10 META-INF/JBOSSCOD.SF
2826 2010-09-14 21:10 META-INF/JBOSSCOD.RSA
....
The EAP contains production server profile:
$ ls jboss-eap-5.1/jboss-as/server/
all default minimal production standard web
Related
I am trying to connect JMSToolbox to an app that is driven by JMS queues running on OpenLiberty.
I am using Open liberty version 22. Specifically 22.0.0.11-202210101601
As far as I can tell, the correct documentation to follow is https://github.com/jmstoolbox/jmstoolbox/wiki/2.2-Setup-for-IBM-LibertyProfile
The installed features I have on the Open Liberty server from the documentation are as follows:
restConnector-2.0 (note restConnector-1.0 as specified in the
documentation does not seem to be available)
appSecurity-2.0
wasJmsClient-2.0
wasJmsServer-1.0
Note I was not able to install restConnector-1.0 from the documentation as I could only find restConnector-2.0.
For the extra jars, I was only able to find restConnector.jar
I could not find the other jars specified in the documentation:
com.ibm.ws.ejb.thinclient_x.y.z.jar (from <was_full_home>/runtimes)
com.ibm.ws.orb_x.y.z.jar (from <was_full_home>/runtimes)
com.ibm.ws.sib.client.thin.jms_x.y.z.jar (from
<was_full_home>/runtimes) (tested with x.z.y ==8.5.5.0+, 9.0.0.0)
Where do I get these jars from? I'm not sure what WAS Full Home means. Am I supposed to take them from a copy of WAS? Are these Jars proprietary?
Thanks,
John
"WAS full" refers to "traditional" WebSphere Application Server. You can download it following this page https://www.ibm.com/cloud/blog/websphere-trial-options-and-downloads
WAS full home is shorthand for WAS installation directory, typically /IBM/WebSphere/AppServer.
These jars are included in the /runtimes subdirectory after you installed the product.
So typical approach following above page would be:
download InstallationManager
install InstallationManager
install developers version either v9 (http://www.ibm.com/software/repositorymanager/com.ibm.websphere.ILAN.v90) or v8.5.5 (https://www.ibm.com/software/repositorymanager/com.ibm.websphere.DEVELOPERSILAN.v85)
copy required jars from the installation directory
... but that would take a while...
So alternatively you could (if you have docker), which should be much faster than whole mumbo-jumbo with installation:
pull WAS v8.5 or v9 version from here https://hub.docker.com/r/ibmcom/websphere-traditional
start container: docker run --name was-server -p 9043:9043 -p 9443:9443 -d ibmcom/websphere-traditional
locate required files:
$ cd opt/IBM/WebSphere/AppServer/runtimes/
$ ls -la
total 343540
com.ibm.jaxrs1.1.thinclient_9.0.jar
com.ibm.jaxrs2.0.thinclient_9.0.jar
com.ibm.jaxws.thinclient_9.0.jar
com.ibm.ws.admin.client.forJython21_9.0.jar
com.ibm.ws.admin.client_9.0.jar
com.ibm.ws.ejb.embeddableContainer_9.0.jar
com.ibm.ws.ejb.embeddableContainer_nls_9.0.jar
com.ibm.ws.ejb.portable_9.0.jar
com.ibm.ws.ejb.thinclient_9.0.jar
com.ibm.ws.jpa-2.0.thinclient_9.0.jar
com.ibm.ws.jpa-2.1.thinclient_9.0.jar
com.ibm.ws.messagingClient.jar
com.ibm.ws.orb_9.0.jar
com.ibm.ws.sib.client.thin.jms_9.0.jar
com.ibm.ws.sib.client_ExpeditorDRE_9.0.jar
com.ibm.ws.webservices.thinclient_9.0.jar
com.ibm.xml.thinclient_9.0.jar
endorsed
properties
sibc.jmsra.rar
sibc.nls.zip
copy required files from the container:
docker cp <containerID>:/opt/IBM/WebSphere/AppServer/runtimes/xyz.jar .
Trying to deploy a Play Framework based Application using an ELB container
Recently it seems that AWS made changes to the way ELB works as we've done this before without issue.
The error we currently get is:
2021/12/14 23:00:15.705423 [INFO] Executing instruction: CheckProcfileForJavaApplication
2021/12/14 23:00:15.705468 [ERROR] An error occurred during execution of command [app-deploy] - [CheckProcfileForJavaApplication]. Stop running the command. Error: there is no Procfile and no .jar file at root level of your source bundle
2021/12/14 23:00:15.705474 [INFO] Executing cleanup logic
2021/12/14 23:00:15.705598 [INFO] CommandService Response: {"status":"FAILURE","api_version":"1.0","results":[{"status":"FAILURE","msg":"Engine execution has encountered an error.","returncode":1,"events":[{"msg":"Instance deployment failed. For details, see 'eb-engine.log'.","timestamp":1639522815,"severity":"ERROR"}]}]}
Now of course I wouldn't be here if this was the actual problem
# cd /var/app/staging/server-xxxxxxxxxxx/
# ls -l
total 16
-rw-r--r-- 1 webapp webapp 135 Dec 14 20:39 Procfile
drwxr-xr-x 2 webapp webapp 82 Dec 14 22:21 bin
drwxr-xr-x 2 webapp webapp 113 Dec 14 22:21 conf
drwxr-xr-x 2 webapp webapp 8192 Dec 14 22:21 lib
drwxr-xr-x 3 webapp webapp 17 Dec 14 22:21 share
So Procfile exists
Hmmm is it valid however?
Let's check that out:
# cat Procfile
web: bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dhttp.port=5000 -Dhttps.port=8443 -Dconfig.resource=application.conf
Looks normal enough -- but does it actually work?
Short answer is yes -- if I copy and paste that command (minus the "web:" prefix of course) system comes up without any issues (ELB still fails to realize that though...)
I've tried a few variants of the command thinking that it might be related to yaml formatting of perhaps a tighter regex ^[A-Za-z0-9_-]+:\s*[^\s].*$ (source: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-linux-extend.html)
web: bin/server
web: ./bin/server
web: bin/server
web: ./bin/server
web:bin/server
web:./bin/server
No difference (both worked when manually started without or without the leading ./ btw)
Unsure how I move forward here?
How do we find what the real problem is so that we have fighting chance to fix it?
And yes -- the initial trace above is already the output of eb-engine.log
Using (in case this is relevant)
Coretto Java 11
Play 2.8.8
Scala 2.13.6
SBT 1.5.2
Will answer any relevant queries that help improve this question and any chance of resolving it. Most Google searches I've dug through are related to other environments and are simply a missing Procfile...
I have worked out the following work-around to be able to use a standard (well slightly modified) Play Framework dist directly in an AWS ELB Java container
We start with the typical sbt dist process to create a zip "distribution" file
That file won't work in the format it is currently in (I've been researching and I will be asking specific questions to see if making it work directly might be possible) however it only takes a few small tweaks to get it to work
First Step: Modify Procfile (a file that you manually create and place in the project's dist directory) as follows:
web: chmod 700 bin/server; bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dpidfile.path=/dev/null -Dhttp.port=5000 -Dconfig.resource=application.conf
Note the chmod 700 bin/server; that was the final secret sauce required to make this work! I was kinda shocked that it did work actually. I did not think that would get past the regex they use to parse the Procfile
As a zip file is permissions agnostic, once I finally got the elb install process to get past that first "missing jar" hurdle I noticed the permissions on bin/server were simply rw. The ec2 instance's /var/log/eb-engine.log did not quite spell that out too clearly, however I confirmed that whenever I manually modified those permissions (on the ec2 instance) and then ran the bin/server command (to verify it) the Play server would start right away (however the elb container still failed to see it as a legitimate process and continued to report it as Status of no data, nor did it allow the load balancer to send it traffic so this "fix" was a real shot in the dark!)
Second step: Unzip that zip file and cd into the directory it created/assigned
cd server-vxxxxxxxxxxxxxx
touch placeholder.jar
The second dab of secret sauce is that the placeholder.jar file is simply a means to satisfy the CheckProcfileForJavaApplication which simply looks for the existence of any file named *.jar in the root of the bundled directory. If that file does not exist then the elb install script stops dead in it's tracks.
Note: You could simply place this empty placeholder.jar file in the Play dist folder if you prefer
Third Step: Create a new zip file elb.zip
zip --exclude share/doc/api/\* -r elb.zip .
Now take elb.zip and upload it to an AWS ELB container and low and behold it (finally) springs to life!
I am trying to setup production redeployment on WebLogic 11 using WLST.
Applications, that I am using for that are standard oracle simple applications:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/14-Redeployment--4465/redeploy.htm
As first, I've deployed simple.war from /tmp/deployversion1/simple.war, and it was deployed successfully.
That simple.war has MANIFEST.MF:
Manifest-Version: 1.0
Class-Path:
Created-By: Bill Bell
Weblogic-Application-Version: v1
Then, I've tried to deploy simple.war with v2 version. It has manifest:
Manifest-Version: 1.0
Class-Path:
Created-By: Bill Bell
Weblogic-Application-Version: v2
From the Oracle documentation, if manifest has a version inside of it, I may not provide versionIdentifier parameter for deploy/redeploy.
And it works for WebLogic 12.
My WLST code, thar doing the redeployment is:
redeploy(appName = 'Simple', appPath = '/tmp/deployversion2/simple.war')
After it I found, that application wasn't deployed, and in weblogic log:
<Dec 21, 2016 3:11:07 PM PST> <Error> <Deployer> <BEA-149091> <An attempt was made to deploy application 'Simple' with specified archive version 'v1'. However, the application archive as specified in the source has version 'v2'.>
But if I doing redeploy this way(versionIdentifier provided), it works fine:
redeploy(appName = 'Simple', appPath = '/tmp/deployversion2/simple.war', versionIdentifier='v2')
Also, it works if I doing deploy again, even without version:
deploy(appName = 'Simple', appPath = '/tmp/deployversion2/simple.war')
And, finally, it works if application is being deployed with weblogic.Deployer:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password ******** -redeploy -source /tmp/deployversion2/simple.war -name Simple
So, I have few questions about it.
1) How can I do production redeployment using WLST for WebLogic 11 and WebLogic 12 with one script?
2) Why WLST redeploy fails, but weblogic.Deployer -redeploy works fine, if parameters are the same?
3) What the difference between deploy and redeploy, if deploy result for WebLogic 12 is exactly the same as redeploy result?
4) Can I use for WebLogic 11 deploy() instead of redeploy() to avoid BEA-149091 error?
Thanks.
I have an application which I took over recently. It is a web app running in Tomcat 7 in a Windows environment (Windows Server 2008 R2). The install unpacks to its own folder structure [appName][version number]\tomcat... and then I uninstall and re-install the service to point to the new version. This is how it was handed over to me and I am no expert on Tomcat.
Up until about a week or 2 ago when I did my last install on UAT all has been well. I ran java - jar [appname]-installer-[version].jar and the application installed to a new folder in the structure. Yesterday we put the latest version live and the war file did not unpack. The final message is a success message but although the new folder structure is created the E:[appname][version number]\tomcat\webapps folder contains an unpacked ROOT.war.
I am now convinced the problem is in the environment as it now happens on a test server which was fine before and also I tried it with a previous version of the app and this is also suffering the same issue.
I'm sure there have been no changes to the configuration of Tomcat, which makes me wonder if it may be a Windows update issue which has caused a problem ?
Does anyone have any ideas ? I've copied the output of the false success below in case it helps ... I will try and get details of what updates have been installed recently but I'm hoping someone may have had the same issue (or be able to point to the obvious missing ingredient, wave a magic want or ...!)
Many thanks if you can help
----
thisclass: Installer
installerFileName: /E:/Install/0.6.6/[appname]-installer-0.6.6.jar
Adding environment hostname: [SERVERNAME]
Reading installation manifest:
==============================
Manifest Key:Installation-Replacement-Files, value:tomcat/lib/app.properties
Manifest Key:Installation-Property-Order, value:java,env,file
Manifest Key:Installation-Name, value:[appcode]
Manifest Key:Build-Jdk, value:1.7.0_60
Manifest Key:Built-By, value:username
Manifest Key:Manifest-Version, value:1.0
Manifest Key:Installation-Version, value:0.6.6
Manifest Key:Created-By, value:Apache Maven
Manifest Key:Installation-Codebase-Files, value:
Manifest Key:Build-Date, value:20150309-1120
Manifest Key:Main-Class, value:Installer
Manifest Key:Archiver-Version, value:Plexus Archiver
Starting installation:
======================
Installation dir: E:\[appname]\0.6.6\
Installing: tomcat/webapps/ROOT.war
Installing: tomcat/lib/logback.xml
Installing: tomcat/lib/app.properties
Updating tomcat/lib/app.properties
+ Installation changed:
product.name=##product.name##
to:
product.name=[appname]
+ Installation changed:
product.version=##product.version##
to:
product.version=0.6.6
+ Installation changed:
install.date=##install.date##
to:
install.date=Fri Apr 10 09:45:51 BST 2015
Installing: service.bat
Installing: startup.bat
Installing: shutdown.bat
Installing: tomcat/conf/server.xml
Installing: tomcat/conf/web.xml
Congratulations, installation has been successful
tomcat needs the flag unpackWARs = true and also autoDeploy = true this is done in the server.xml.
That log file is that the output of the "installer" (not tomcat), which seems mighty overblown btw.
What do the tomcat logs say ? I don't think this is a windows conf issue, most likely the installer has changed.
I have a problem when I try to instantiate Hibernate and connect with a MySQL database (see error message below).
Curiously enough the connection works fine using the exact same hibernate.cfg.xml file when running Junit tests but it refuses to work when run from Tomcat...
I am starting to run out of ideas.
Any clues or tip where to look?
Caused by: org.hibernate.HibernateException: Unable to instantiate default tuplizer [org.hibernate.tuple.entity.DynamicMapEntityTuplizer]
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:110)
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructDefaultTuplizer(EntityTuplizerFactory.java:135)
at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.(EntityEntityModeToTuplizerMapping.java:69)
at org.hibernate.tuple.entity.EntityMetamodel.(EntityMetamodel.java:323)
at org.hibernate.persister.entity.AbstractEntityPersister.(AbstractEntityPersister.java:456)
at org.hibernate.persister.entity.SingleTableEntityPersister.(SingleTableEntityPersister.java:131)
at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:84)
at org.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:267)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1341)
at se.fmt.atlantism.util.HibernateUtil.buildSessionFactory(HibernateUtil.java:16)
... 38 more
Caused by: java.lang.NullPointerException
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:107)
... 47 more
I'm writing this for future Googlers and reference.
I've done some more research and the root source of the problem is still not known. However the following article throw me on the right track.
http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/
It seems like the Tomcat (version 6 at least) packages available in Ubuntu (and Debian) are not working correctly. Instead I installed Tomcat using the following guide:
http://www.ctrip.ufl.edu/tomcat6-debian-lenny-howto
While this might not be the premium choice of installation it seems necessary to get Tomcat version 6 running without problems on Ubuntu and/or Debian Lenny.
In my case, this error was resolved by switching the <dependency/> order in my pom.xml. When hibernate (3.2.7.ga) comes before hibernate-annotations (3.4.0.GA) this error occurs. The other way around, it works fine. This is the case even with scope=compile.
I would guess that you need to tweak your classpath, except that (assuming you've dropped both jars in WEB-INF/lib) it should alpha-sort in the correct order. But maybe this will give someone a hint on how to move forward.
In my case it was a simple mistake - the config file *.hbm.xml had a property that the mapped object didnt have! I also heard of cases of that error apearing when you misspell a get/set function - very similar to my case.
I was facing the same problem. It went away after I downloaded "javassist.jar" and put it in the classpath: http://www.java2s.com/Code/Jar/JKL/Downloadjavassistjar.htm
This is how the Tomcat daemon process looks:
root 2605 0.0 0.0 16584 376 ? Ss 15:39 0:00
/usr/bin/jsvc -user tomcat6
-cp /usr/share/java/commons-daemon.jar:/usr/share/tomcat6/bin/bootstrap.jar
-outfile SYSLOG -errfile SYSLOG -pidfile /var/run/tomcat6.pid
-Djava.awt.headless=true -Xmx128M
-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed
-Dcatalina.base=/var/lib/tomcat6 -Dcatalina.home=/usr/share/tomcat6
-Djava.io.tmpdir=/tmp/tomcat6-temp -Djava.security.manager
-Djava.security.policy=/var/lib/tomcat6/work/catalina.policy
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/var/lib/tomcat6/conf/logging.properties
org.apache.catalina.startup.Bootstrap
This is how the Tomcat process looks when run from within Eclipse using the Sysdeo Tomcat launcher plugin:
(this one actually works)
jzaruba 2655 19.7 4.5 358304 46152 ? Sl 15:43 0:01
/usr/lib/jvm/java-6-sun-1.6.0.15/bin/java
-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:37377
-Dcatalina.home=/usr/share/tomcat6
-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed
-Dcatalina.base=/var/lib/tomcat6 -Djava.io.tmpdir=/var/lib/tomcat6/temp
-Dfile.encoding=UTF-8 -classpath
/usr/share/tomcat6/bin/bootstrap.jar:/usr/lib/jvm/java-6-sun-1.6.0.15/lib/tools.jar
org.apache.catalina.startup.Bootstrap start
The working one (Eclipse launched) is run using java-6-sun-1.6.0.15, I'm Windows user so I don't know how to tell which JRE is used for /usr/lib/jsvc (looking at it though), but my guess would be it is some OpenJDK... Could this be the difference?
update: jsvc probably uses the same JRE Sysdeo Tomcat launcher does