I want to use JavaMelody to monitor the SQL requested by a Glassfish Application Server. There are step-by-step instructions on https://github.com/javamelody/javamelody/wiki/UserGuideAdvanced#monitoring-of-sql-requests-and-of-jdbc-connections-in-glassfish-v3
I followed the instructions (I didn't download javamelody-objectfactory.jar but used javamelody-core-1.54.0.jar instead) and I get this error when clicking on the refresh button (javamelody web page) :
server.log :
exception while collecting data
java.lang.NoClassDefFoundError: org/jrobin/core/RrdException
at net.bull.javamelody.Collector.getCounterJRobin(Collector.java:836)
at net.bull.javamelody.Collector.collectJRobinValues(Collector.java:489)
...
any idea how to resolve this ?
jrobin-1.5.9.1.jar is installed in the lib folder of glassfish (and in my ear project).
thanks !
javamelody-objectfactory.jar (java source included in the jar) and javamelody-core jar file are absolutely different things. The first is to make the datasource monitorable in Glassfish and the second is the monitoring tool itself.
First fix the exception. You should probably put javamelody-core jar and jrobin jar files in your ear project (and not one in lib folder of Glassfish and one in ear).
Then if the monitoring reports don't include SQL monitoring for the datasource declared in Glassfish, use the javamelody-objectfactory.jar including all steps as said in the doc.
Related
I followed this tutorial but at the end I got an 404 Not Found.
http://localhost:8080/TomEE_war_exploded/
The requested resource [/TomEE_war_exploded/] is not available
In Intellij I don't see a mistake. The Apache Tomee runs under windows in ~/software/apache-tomee-plume-8.0.11 and the code in ~/playground/TomEE
Unfortuately I'm not able to understand how the war file will be copied to the ~/software/apache-tomee-plume-8.0.11/webapps directory or where the configuration error exists.
From the log file I'm not really sure that the deployment happend correct:
30-May-2022 16:49:53.486 WARNING [http-nio-8080-exec-4] org.apache.batchee.container.services.ServicesManager.init You didn't specify org.apache.batchee.jmx.application and JMX is already registered, skipping
30-May-2022 16:49:53.486 INFO [http-nio-8080-exec-4] org.apache.openejb.assembler.classic.Assembler.createApplication Deployed Application(path=/home/maggus/playground/TomEE/target/TomEE-1.0-SNAPSHOT)
30-May-2022 16:49:53.664 INFO [http-nio-8080-exec-4] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
[2022-05-30 04:49:53,804] Artifact TomEE:war exploded: Artifact is deployed successfully
[2022-05-30 04:49:53,804] Artifact TomEE:war exploded: Deploy took 823 milliseconds
Does anybody see the mistake?
Thanks,
Markus
I ran into somewhat similar problem today and after sometime I was able to figure it out that it does not deploy at the following Application Context that is configured under Deployment tab in Run/Debug Configurations.
/TomEE_war_exploded
If you try to access http://localhost:8080/TomEE_war_exploded/, it gives 404.
Instead, (in my case) it is accessible at http://localhost:8080/TomEE-1.0-SNAPSHOT/
Where 1.0-SNAPSHOT is the version number defined in pom.xml.
Now in order to find the exact path where it is deployed, you need to go to Tomcat Web Application Manager at the following address:
http://localhost:8080/manager/html
Replace 8080 with the port number on which TomEE is running on your machine.
Default user & password is tomee.
Look under Path and you'll find it. Just click on it, it will be accessible.
I hope it helps.
EDIT: The Workaround
In order to define your own path, you need to update the path in the Artifact Output Directory. See the attached photo.
Hello worklight team and devs!
We are done working on our development project and everything works fine in the local dev server (Tomcat).
Now we are trying to build the project to be deployed to a testing WAS ND 8.0.3 server.
We've been following the manual in the infocenter and modified each required file as needed (worklight.properties and application-descriptor.xml)
We made this changes to the worklight.properties file:
publicWorkLightHostname=working.hostname.com
# http or https
publicWorkLightProtocol=http
# For default port leave empty
publicWorkLightPort=ourport
publicWorkLightContext=/worklight
wl.db.jndi.name=jdbc/WorklightDS
wl.db.type=DB2
wl.db.url=jdbc:db2:Worklight
wl.db.username=wluser
wl.db.password=passwd
We tested the jdbc source in the WAS console and it works perfectly.
We proceed to build the war, adapter and wlapp (ALL) and we get this error:
[2013-05-21 12:48:44] FWLSE4001W: Failed to resolve JNDI name: "jdbc/WorklightDS".
Application may fail to access the database in runtime. If building for remote server - ignore this warning.
[2013-05-21 12:48:44] FWLST0011E: ====== Worklight Project BPMWorklight-project-customization failed to start: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
[2013-05-21 12:48:44] Activation failed. Bundle didn't start:C:pathto\BPMWorklight-customization.jar
This happens in the developer workstation and if we install Studio in the server, where the jdbc source is created, the same happens.
I guess that Worklight is trying to "obtain" a JDBC source in TOMCAT not WAS, but we are building for WAS, so the build fails and NO files are changed after the error. NO BUILD is executed.
We also tried to execute the build.xml with ANT in studio but we get this error:
Buildfile: C:\Users\Primary User\IBM\Worklight\LIS_SampleCollection\BPMWorklight\build.xml
BUILD FAILED
C:\Pathtofile\BPMWorklight\build.xml:3: Cannot find ../../common.xml imported from
C:\Pathtofile\BPMWorklight\build.xml
Total time: 62 milliseconds
You're help is greatly appreciated!
Thanks a lot!!
Best,
Nicolas E.
If all you require is to deploy the updated-for-WAS .war file in WebSphere, you don't need to do any build operation in Worklight. After updating any file under the server\ folder in Worklight Studio (the Eclipse plug-in), the .war file is automatically being re-created.
The build operation is mainly for creating the binaries and deploying to Worklight Server (database) (again, when using the Eclipse plug-in).
So what I suggest is to:
First update application-descriptor.xml with your context root value in worklightServerRootURL, and keep your .wlapps on the side
Update worklight.properties and save them.
Now you have your app ready to deploy and the .war file ready to deploy.
Move to WAS, deploy the .war file
Hopefully things will work now, so you can load Worklight Console and deploy the .wlapp and .adapter files.
I don't know what you've read in the IBM Information Center, but you can also try going over the following training module from IBM Worklight Getting Started.
Moving from development environment to stand-alone QA and production servers
Notes:
The above is not so convenient, but it is A way to move from your
development environment to another staging environment, or
application server...
The issue might also happen even after following my steps above, and this will indicate that the real issue is in your DB2 declaration in worklight.properties.
I will update this answer tomorrow with some insight regarding the possible DB2 declaration issue.
i have a problem in creating a data source in weblogic application server 10.3, i'm making a JDBC connection for MySql database , i placed the mysql driver in the lib folder of weblogic \wlserver_10.3\server\lib and in the mysql folder wlserver_10.3\server\ext\jdbc\mysql independently and the error message still arises
Note: there was a two jar files in this folder wlserver_10.3\server\ext\jdbc\mysql and i removed them to avoid any conflict, how i can solve these problem??
Are you using or need a different driver than the one that comes with the weblogic install? If you are you will need to add it to the CLASSPATH in setDomainEnv.sh. Otherwise it will default to using:
\wlserver_10.3\server\lib\mysql-connector-java-commercial-5.x.x-bin.jar
We had to add additional Oracle jars to our CLASSPATH recently for secure connections. You can check into it more here: http://docs.oracle.com/cd/E13222_01/wls/docs100/jdbc_admin/third_party_drivers.html
If somebody looks for a solution how to add JDBC driver (in my case PostgreSQL) to a Weblogic 14c installation attached to IntelliJ IDEA:
The location of jar-file doesn't matter. It is not needed to put it into the server's lib directory.
I have a Maven project which generates a 413.06 KB jar file. I have to deploy it on Apache Archiva based managed repository. I have tried to deploy different versions, and it created required layout and structure, uploaded some files, even it uploaded that jar with 200~ KB. every time the jar file size changes but always it fails to upload 413.06 KB jar file.
Information:-
I am running standalone Archiva
I have given guest account to Global Repository Manager & "Repository Manager - MYREPO"
I have also tried a separate account in Archiva with "Repository Manager - MYREPO" rights and configured it in maven's settings.xml file to set custom timeout.
I am getting following error
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project SharedshelfRepository: Error deploying artifact: Transfer error:
The server did not respond within the configured timeout. -> [Help 1]
that might be maven-deploy-plugin issue, resources plugin itself needs several dependencies,try manually jar nad p
What version of Maven are you using? You might try 3.0.4 as it has a different HTTP library. I'm also not sure if there's more context for what was happening when it timed out (it seems more request oriented rather than deploy oriented, and deploy does request some metadata).
I can't see that you'd need to alter the timeout, as none of the defaults should apply to such a small file. How long does it take to fail?
I have a few EJBs compiled with Weblogic's EJBC complient with Weblogic 9.2.1.
Our customer uses Weblogic 9.2.3.
During server start Weblogic gives the following message:
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
Consequently, server start takes 1.5 hours instead of 20 min. The next server start takes exactly the same time, meaning Weblogic does not cache the products of the recompilation. Needless to say, we cannot recompile all our EJBs to 9.2.3 just for this specific customer, so we need an on-site solution.
My questions are:
1. Is there any way of telling Weblogic to leave those EJB jars as they are and avoid the re-compilation during server start?
2. Can I tell Weblogic to cache the recompiled EJBs to avoid prolonged restarts?
Our current workaround was to write a script that does this recompilation manually before the EAR's creation and deployment (by simply running java weblogic.appc <jar-name>), but we would rather avoid this solution being used in production.
I FIXED this problem by spending a great deal of time researching
and decompiling some classes.I encountered this when migrating from weblogic8 to 10
by this time you might have understood the pain in dealing with oracle weblogic tech support.
unfortunately they did not have a server configuration setting to disable this
You need to do 2 things
Step 1.You if you open the EJB jar files you can see
ejb-jar.xml=3435671213
com.mycompany.myejbs.ejb.DummyEJBService=2691629828
weblogic-ejb-jar.xml=3309609440
WLS_RELEASE_BUILD_VERSION_24=10.0.0.0
you see these hascodes for each of your ejb names.Make these hadcodes zero.
pack the jar file and deploy it on server.
com.mycompany.myejbs.ejb.DummyEJBService=0
weblogic-ejb-jar.xml=0
This is just a Marker file that weblogic.appc keeps in each ejb jar to trigger the recompilation
during server boot up.i automated this process of making these hadcodes to zero.
This hashcodes remain the same for each ejb even if you execute appc for more than once
if you add a new EJB class or delete a class those entries are added to this marker file
Note 1:
how to get this file?
if you open domains/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX
you will see this file for each ejb.weblogic makes the hashcodes to zero after it recompiles
Note 2:
When you generate EJB using appc.generate them to a exploded directory using -output C:\myejb
instead of C:\myejb.jar.This way you can play around with the marker file
Step2.
Also you need a PATCH from weblogic.When you install the patch you see some message like this
"PATH CRXXXXXX installed successfully.Eliminate EJB recomilation for appc".
i dont remember the patch number but you can request weblogic for that.
You need to use both steps to fix the problem.The patch fixes only part of the problem
Goodluck!!
cheers
raj
the Marker file in EJBs is WL_GENERATED
Just to update the solution we went with - eventually we opted to recompile the EJBs once at the Customer's site instead of messing with the EJBs' internal markers (we don't want Oracle saying they cannot support problems derived from this scenario).
We created two KSH scripts - the first iterates over all the EJB jars, copies them to a temp dir and then re-compiles them in parallel by running several instances of the 2nd script which does only one thing: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (With error handling of course :))
This solution reduced compilation time from 70min to 15min. After this we re-create the EAR file and redeploy it with the new EJBs. We do this once per several UAT environment creations, so we save quite a lot of time here (55min X num of envs per drop X num of drops)