I was trying to install Apache Solr 4.0.0 with apache Tomcat, but it is giving an error like this:
SolrCore Initialization Failures
collection1: java.io.IOException:java.io.IOException: Can't find resource 'solrconfig.xml' in classpath or 'solr\collection1\conf/', cwd=C:\apps\tomcat-solr\apache-tomcat-7.0.35\bin
There are no SolrCores running.
Using the Solr Admin UI currently requires at least one SolrCore.
After this I have installed apache solr 3.6.2 and it working perfectly well. I still cannot understand why i am not able to use solr 4.0.0 with the same server configuration.
I hope you will be able to tell me the mistake i have committed.
The directory structure changed in Solr 4.0. Have a look at the one in the example/solr directory. You will see that Solr 4 now has collection1 directory inside that and conf directory is now one level lower inside that. That's basically what the error message said.
If you don't like that, I think you can change it by putting solr.xml with the single core definition in it and directory paths setup the way you like it.
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.
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'm getting a wired error when loading Apache (Win 2016 STD, Apache/2.4.29 x86, OpenSSL/1.0.2n SVN/1.9.2)
i.e.
"Syntax error on line ... of .../conf/httpd.conf:
Cannot load ...modules/mod_dav_svn.so into server: (...) The specified module could not be found:"
The file is in the conf file properly: "LoadModule dav_svn_module modules/mod_dav_svn.so"
The file exists in the "modules" folder.
Although Apache reports a syntax error, it is not because other modules are loaded just fine with the same syntax.
Other file also has this problem: "mod_authz_svn.so".
Prerequisites are loaded before this module successfully (mod_dav.so, mod_dav_fs.so).
The best part: in my lab it is working just fine but in the customer's machine (same OS mentioned), something is not working properly.
I really need any help you can give me here...
mod_dav_svn.so is from subversion server - so it does not come with apache and has to be added. If you have - then to problem might be that a visual c++ runtime of another version is required. To find out you could try a tool like dependecy walker.
When all missing dependencies are installed on the system your apache should start.
I am trying to connect the PHP with Java with the PHP/Java Bridge library. But I am facing an error as given below.
Please check below screenshot.
By default, the phpjavabridge servlet try to connect to a php-cgi daemon. It can be easily fixed, either by starting one of the bundled php-cgi (found in WEB_INF/cgi, follow the error message) or modify the configuration in the web.xml (see an example here) to provide your system php-cgi path. Repackage and redeploy your war file.
That said, if you want to use Java from PHP (and not PHP from Java), you don't need a php-cgi daemon. My recommendation, have a look to the following project: http://docs.soluble.io/soluble-japha/. This is a reworked version focusing on PHP -> Java integration.
Feel free to open issues on https://github.com/belgattitude/soluble-japha
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)