After recent migration from HBase 0.94.13 to HBase 0.98.12 my code is failing to execute.
I am simply trying to connect to a table via dependent jar file developed by another team who uses Spring HbaseTemplate. I have manually placed all the required jar files for executing the code including hbase-client-0.98.12-mapr-1506.jar (we have MapR distribution).
I am receiving the following error:
Caused by: java.lang.NoClassDefFoundError: org/apache/hadoop/hbase/filter/WritableByteArrayComparable
It seems to be occuring because HBase 0.96.x WritableByteArrayComparable has been renamed to ByteArrayComparable.
How can I make the old code work again?
I was able to make it work by keeping the old jar hbase-0.94.9-mapr-1308 in the classpath. It was a dirty fix but it did the job.
The other team whose dependent jar I was using to connect to M7, finally updated their code and now things are back to normal again. Thanks.
Related
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.
I am having hard time understanding how Liquibase works with jhipster. I am using Boxfuse to deploy jar file to AWS. Now , since my application is evolving continuously I need to add/drop columns/tables every week.
Application works fine for the first time when I deploy it for the first time , Also it works fine when there is no change in the Database schema only the change in code. Now , I need to add column to database. I used mvn liquibase:update command wit the changesets containing the respective changes in the master.xml. Even the changes are applied to the database. I confirmed them.
Now, when I deploy the updated jar with the changes , It gives error and is unable to deploy. Also, boxfuse console does not show any specific error . It just says that failed to upload.
Can someone help me with this? Thanks.
Strange event is happening in a Mule project. I have the application xml which is JPC.xml. This normally appears in the mule-deploy.properties as follows
redeployment.enabled=true
encoding=UTF-8
config.resources=JPC.xml
domain=default
When I choose Run As, Mule Application Which kicks off the build in the background prior to the deploy and run. During that time the mule-deploy.properties becomes:
redeployment.enabled=true
encoding=UTF-8
config.resources=
domain=default
And when the application runs it says it is missing the mule-config.xml
What is erasing it?
I think I may have found the root of this issue.
It seems to be a bug related to jdk_1.7.0_45 having to do with xml parsing. see: What's causing these ParseError exceptions when reading off an AWS SQS queue in my Storm cluster
I noticed several errors logged in eclipse/anypoint as:
!ENTRY org.mule.tooling.core 4 0 2014-11-19 14:16:41.081
!MESSAGE Error opening resource measurement_scheduler.xml
!STACK 0
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK.
I also noticed that after restarting Anypoint, I would be able to build with maven successfully and my mule-deploy.properties file would again have content. Until...at some point after several edits to things in Anypoint, I would again get mvn build that wiped out the contents of mule-deploy.properties.
I further noticed that once this problem started to happen in one project in Anypoint, it would ALSO start happening in ANY project I built in Anypoint...until restart of Anypoint.
It seems this bug in jdk 1.7.0_45 mistakenly applies this limit in the xml parser to all opened files cumulatively, instead of per file. I suspect this causes Anypoint to not finish parsing all of the xml docs that make up my app and therefore couldnt re-create the mule-deploy.properties...leaving it blank.
Upgrading to newer jdk would fix this.
Another way to work around it is to override this limit for xml parser by adding the following to ${JAVA_HOME}/jre/lib/jaxp.properties:
jdk.xml.entityExpansionLimit=0
jdk.xml.maxGeneralEntitySizeLimit=0
I am not certain that both limits need set to work-around this. Possibly only entityExpansionLimit is needed.
After making this change I am now happily able to use Anypoint again. Beware that using this work-around possibly opens you up to a denial-of-service attack through the xml parser if your same jre is used for other not-so-trusted processes.
I am working on an Oracle OSB Build job using Jenkins.
The issue I am facing is: In the sbconfig.jar that's gets crated is not having the full service name.
Ex. If my OSB service name is EmployeeRecordDetailReturnsStorageBOService but in the sbconfig.jar its getting created as EmployeeRecordDetailReturnsStorageBOSer only.
I need the full service name in the sbconfig.jar for my further processing of this jar.
I am using the eclipse based jar <java dir="${eclipse.home}" jar="${eclipse.home}/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar" ...> in my ant build file.
But what I have observed is the java command that we are using has a folder length limit. It could not created the full service name in the sbconfig.jar because the ant build file is in a deep location under the folders like abcd/efgh/ijkl/mnop/qrst/xyz/build.xml so thats why its not able to create the full service name in the sbconfig.jar file. Its seems to be an character length issue in java/JVM.
Can anybody pls let me know how to to over some this problem.
It will not cause any issue when you will be importing the sbconfig.jar back into the sbconsole. So, do not worry about name getting shortened in sbconfig.jar.
If you are facing any issue while importing then let us know.
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)