We are inserting documents in mongo through spring-mongodb and the mongo-java-driver everything seems to work fine on the program. Accessing the data back through the java driver works fine but doing the same through mongo console breaks the console.
> db.item.find()
error:non ascii character detected
>
I saw there was a JIRA ticket with a similar error but I'm not sure if this problem is just a console proble or there is really something going on the server.
You'll need to make sure that you are running on a UTF-8 enabled build of MongoDB. A common problem apparently is doing a custom build (or running an older build) of MongoDB without UTF-8 support. The 10gen supplied binaries should have this enabled by default. If they do not, this is often the issue.
Related
I'm working on a gem locally, referenced it using bundle config local.GEMNAME (this is confirmed by the printout of bundle install). However, unless I bump the version on the gem, I can't use the most up-to-date code. When errors occur in the old code, it references the file in the right place, where I have fixed the error. I temporarily had bundler-cache-all switched on, but have turned that to false (and deleted .bundle/config).
Where is this cache living (I'm on OSX, using RBenv and ruby 2.1.2), and how can I turn it off?
Have you tried running spring stop and restarting your server (assuming this is a Rails app)?
If it's referencing the file in the right place but executing the wrong code, that indicates that the old code is still loaded into memory. Often, this is because of the Spring pre-loader, which is used by default with Rails 4.1+.
I have been writing grails applications on Windows, and when I am editing the .groovy files and save they are automatically compiled while the application is running and the changes are available without restarting the app. On OSX this is not happening, in neither interactive mode or by starting the application with grails run-app.
Looking up online I couldn't find a reason for this, and also I know other people working on OSX where this feature works.
Any suggestions as to what might cause this?
Grails 2.3.7
OSX 10.9.4
Java 1.7.0_55
If you are not running in forked mode, you will need to specify the -reloading explicitly.
Starting at some point, the initial JVM has reloading disabled and forks a new JVM with options specified in the grails.project.fork = [...] in BuildConfig.groovy.
As an alternative to passing -reloading each time, you can also modify the startGrails script included with the distribution and change the following option to false:
DISABLE_RELOADING=false
For me, the startGrails script is found in the GVM directory at ~/.gvm/grails/2.3.11/bin/startGrails.
I have a working instance of Orbeon Forms 4.3, which I setup to connect to Oracle. After upgrading to Orbeon Forms 4.4, connections to Oracle fail with different exceptions depending on the case, for instance:
org.orbeon.oxf.xforms.submission.XFormsSubmissionException
org.orbeon.oxf.common.ValidationException
org.orbeon.oxf.webapp.HttpStatusCodeException
What could be causing this?
Checking the source of the errors
Those exceptions are most likely only the symptom of the real cause. To be sure, change the your log4j.xml and properties-local.xml per the development configuration, reproduce the problem, and check again your orbeon.log. Check if in the log you see now see an java.lang.NoClassDefFoundError: oracle/xdb/XMLType exception.
Solution
If you see that NoClassDefFoundError, you need to add the xdb.jar and xmlparserv2.jar to the directory where you currently have Oracle driver. Those two files are part of the Oracle driver, and come along the other "main jar", i.e. ojdbc6_g.jar. On Tomcat, you typically place those files in Tomcat's lib directory. Restart Tomcat, and your problem should be solved.
Why this is happening
This is happening because Orbeon Forms 4.4 started sending XML "as XML" to Oracle, instead of "as CLOB". Because of this, the driver uses classes from xdb.jar and xmlparserv2.jar. In retrospect, this might not have been the best approach; it was done because it looked like the "right thing", but it isn't clear this has any performance or other benefit, and makes installation and upgrade harder, requiring additional jars.
Update
This issue is fixed in Orbeon Forms 4.5.
I'm running Jetty on OSX on my dev environment. Currently character encoding seems to be faulti (probably mac-roman), overriding Jetty default. How can I force the encoding to be UTF-8? This problem seems to appear only on OSX, linux/windows works fine.
I'm running Jetty from terminal so eclipse-specific solutions aren't of help.
Apparently I was wrong in blaming Jetty for this problem. The reason was maven and how maven brings in the default encoding java-settings.
Setting this env-variable seemed to solve the problem:
export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8
Answer found from here.
No problem here however we start Jetty from the javaWrapper (and which should not make a difference).
The only parameter I can see making an impact is setting the file.encoding System Property e.g. -Dfile.encoding=UTF-8
EDIT
( our macs locale are set to utf-8 )
To set the default character encoding for jetty you can set the system property 'org.eclipse.jetty.util.UrlEncoding.charset' to whatever you like. This will affect the encoding and decoding for either the query string of a URL or the content of a POST HTTP request.
Also, for a long time (maybe early 6.1.x timeframe) now this has been utf-8 by default so I am not certain this is the issue your are seeing.
So it is clear, jetty has been an eclipse project for a number of years now so that above system settings isn't an eclipse specific setting, it is just an artifact of our being at eclipse naming wise. :)
cheers
I refer this to enable the debugger in the PostgreSQL server in order to debugging the plpgsql function by stepping through the code using pgadmin.
I have already set shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' in the postgresql.conf, run pldbgapi.sql , and restarted the server.
These steps should have been run successfully and plugin_debugger.dll should be loaded successfully as can be verified by using the command show shared_preload_libraries, and I can see the debugging option in the context menu with a right click on a function in pgAdmin.
When choosing "Debugging" --> Debug, a window pops up to allow me to enter the values for the input parameters. But after that, when I press OK, it does not respond at all.
Any ideas or did I miss something in the setup of the debugger on the server?
I am using PostgreSQL 8.3 and pgAdmin 1.14
You have to enable debugging in two places. On PGAdmin and on the database itself. That article you referenced does a wonderful job explaining it but there were some nuances.
PGAdmin
When updating your postgresql.conf file to load the debugging library, I was running PGAdmin on Windows so the file was here:
C:\Program Files\PostgreSQL\9.4\data\postgresql.conf
And the path to the plugin_debugger.dll was actually
$libdir/plugin_debugger.dll
not
$libdir/plugins/plugin_debugger.dll
as specified in the article. So your postgresql.conf would need a line like this
shared_preload_libraries = '$libdir/plugin_debugger.dll'
Search for the actual .dll if you're in doubt. If you're on Linux the file you'll be looking for is plugin_debugger.so. Don't forget that changing the postgresql.conf file will require a restart for the change to take effect.
PostgreSQL Database
Assuming you're running your PostgreSQL database on a Linux server this gist does an excellent job at explaining how to download the dependencies for enabling debugging. Make sure you're running as root when you install.
The part that's easy to miss is issuing the command against the actual database you want to debug. For newer versions on PostgreSQL all you'll need to do is this:
CREATE EXTENSION IF NOT EXISTS pldbgapi;
If that doesn't return an error, you should be good to go.
Some additional things of note:
As mentioned above, you can only debug when running as a super user account
From their docs you can only debug pl/pgsql functions. So if your function says something like LANGUAGE c PGAdmin won't even show a right-click Debug menu option when you select the function. Look for something that has LANGUAGE plpgsql and the Debug menu should show.
Ken,
Have you tried pgAdmin 1.8 to rule out issue with PgAdmin 1.14/ PostgreSQL 8.3 interaction. It's been a while since I've used 8.3 and for the article I wrote -- which you are referring to, I was testing with 1.14/ PostgreSQL 9.1 so it could very well be an issue with the interaction with older version. Unfortunately I don't have a 8.3 anymore to test with.
I vaguely remember having the issue you had once, but it was when I had another shared library in my postgresql.conf in addition to the pldebugger. Can't remember which one that was, but removing the other shared library fixed my issue.
Hope some of these suggestions help,
Regina
I had the same problem.
Make sure the only shared lib you´re loading in the postgres.conf is the debugger.
Nothing else. Not even the profiler.
If you get a SSL error when trying to debug a function, reconnect to the server.