**while running solr 4.10.3 solr\examples i ran following command on cmd java -jar start.jar
after this when i go on http://localhost:8983/ i got this error
Error 404 - Not Found.
No context on this server matched or handled this request.
Contexts known to this server are:
/solr ---> o.e.j.w.WebAppContext{/solr,null},D:\solr-4.10.3\exampleD:/solr-4.10.3/example/webapps/solr.war
try http://localhost:8983/solr. By this you are provding the web application within which it might need to find index.* i.e. welcome file.
I'm currently having real problems trying to get the gem Nokogiri to work in my applet. I have the jruby-complete-1.7.3 jar and have attempted to install gems using the normal install line:
java -jar jruby-compelete-1.7.3.jar -S gem install nokogiri
And also I have tried the Gem-In-A-Jar method. At first it works fine, and allows me to eval ruby code and store the data returned. My problem arises when I add in the line:
require 'nokogiri'
While that line works fine in the irb, when trying to access it from the applet I get the following error:
classpath:/META-INF/jruby.home/lib/ruby/shared/rubygems.rb:396 warning: can't
canonicalize loaded names due to security restrictions; disabling
Message: (LoadError) no such file to load -- nokogiri
Stacktrace:
org.jruby.exceptions.RaiseException: (LoadError) no such file to load -- nokogiri
at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1027)
at RUBY.require(classpath:/META-INF/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:36)
at RUBY.(root)(<script>:2)
I simply can't figure out why this exception is occuring. I've tried:
moving the gems manually into the "META-INF/jruby.home/lib/ruby/gems/shared" folder
I've added "require 'rubygems'" above the the nokogiri call.
Accessing the gems via the Gems-in-a-jar method: http://blog.nicksieger.com/articles/2009/01/10/jruby-1-1-6-gems-in-a-jar/
If anyone has an idea where I've gone wrong, or a solution to this issue, I'd greatly appreciate it.
I am getting following exception while I am trying to get list of tasks, from services that I have written which are supporting hibernate 4, into web application which supports hibernate 3
java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: org.hibernate.collection.internal.PersistentBag (no security manager: RMI class loader disabled)
Services ------------------> WEB
(Hibernate 4) (Hibernate 3)
Web trying to get data from services through RMI and getting above excpetion
Apparently your client doesn't see the classes in your service. One of the methods to achieve this is to have a shared rmi code base. Consider following script that adds all jars in the lib folder and your primary jar in the dist folder to rmi codebase and make them visible to the client:
#!/bin/bash
lib_path=lib
artefact=name-of-your.jar
for file in $(ls $lib_path); do
lib=$lib:$lib_path/$file
rmicodebase="$rmicodebase file:$PWD/$lib_path/$file"
done
lib=$lib:dist/$artefact:etc
rmicodebase="$rmicodebase file:$PWD/dist/$artefact"
CLASSPATH=classes:etc:$lib
echo CLASSPATH: $CLASSPATH
echo rmicodebase=$rmicodebase
java -Xmx64M -Xms64M -classpath $CLASSPATH -Djava.rmi.server.codebase="$rmicodebase" $*
I assume that you have a shared rmi registry in the central process of your server. Another possibility to achieve the class visibility is to have a separate rmi registry running in the server process:
java.rmi.registry.LocateRegistry.createRegistry(port)
and have your client connect to this registry.
regards
Leon
Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.
If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.
I.E. the following won't work any more with 1.6.0_29:
-Djava.rmi.server.codebase="file:myproject/bin/ ..."
We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?
Note: No, we do not want to start a local webserver or ftp server.
Update:
On Naming.bind this exception is thrown:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: access to class loader denied
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.
Take running in windows as an example:
Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:
grant { permission java.security.AllPermission; };
Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly.
Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.
Step 2. Start rmiregistry:
C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/
(Please note codebase must ended with "/")
Step 3. Run your server and client program.
References:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html
It looks like there is no workaround because it is a bug, so wait for the fix
See details at
https://bugzilla.redhat.com/show_bug.cgi?id=751203
Code fix
http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734
If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:
Windows:
set CLASSPATH="path_to_jarfile"
Linux (batch):
CLASSPATH="path_to_jarfile"
export CLASSPATH
Best place to do it is in some script that invokes the RMI server.
Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!
If you start the rmiregistry in the working directory of your project, it works.
So essentially working directory of your project and current directory for rmiregistry should be same.
I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:
be started in the root of the directory containing the shared classes; or
set the classpath to point to the shared classes or shared class jar; or
use a protocol other than file:// (I set up ngnix and served the jar from that).
Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.
I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &
The latest update in the CCRC client triggered the following message:
CRVAP0087E (conflict): CCRC command 'Update' failed: Problems were encountered while retrieving view synchronization information and data.
ClearCase CM Server: Error: Unable to access "\rainwater\src": Permission denied.
ClearCase CM Server: Error: 1 config spec load rule problems encountered.
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.realException(StpExceptionImpl.java:493)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:572)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:538)
at com.ibm.rational.stp.client.internal.cc.Util.ccrcCmdStatusToWvcmException(Util.java:155)
at com.ibm.rational.stp.client.internal.cc.Util.runCommandAndCheckResults(Util.java:107)
at com.ibm.rational.stp.client.internal.cc.WebViewRefresh.run(WebViewRefresh.java:151)
at com.ibm.rational.stp.client.internal.cc.CcFileImpl.doRefresh(CcFileImpl.java:240)
at Refresh_View.main(Refresh_View.java:39)
What should I look for in order to troubleshoot this issue?
All web views in CCRC are snapshot views.
Check their config spec to see if said snapshot view refers to a directory which is no longer accessible (a bit like in technote swg21256715)
The question is: "what \rainwater\src represents for CCRC? A snapshot root directory? or the Vob rainwater and src subdirectory within that Vob?"
In the latter case, the main CLEARCASE group set in the CCRC preferences is probably wrong (it is the equivalent of the environment variable CLEARCASE_PRIMARY_GROUP when you are using a full ClearCase client): it must be part of the main group of the Vob (or one of its secondary groups)