In our team, we use a common database server. When running the Orchard Setup, I point the connection string to an existing Orchard Database and got this error message:
Setup failed: The requested service 'Orchard.IWorkContextAccessor' has not been registered. To avoid this exception, either register a component to provide the service, check for service registration using IsRegistered(), or use the ResolveOptional() method to resolve an optional dependency.
The only way that can make setup successful for me is to point to an empty database. I attempted a workaround by doing so first, and then edit connection string in App_Data\Sites\Default\Settings.txt, but then I got the same error.
I had this problem as well, also tried copying the settings.txt file which did not work. This time I copied all the contents of the App_data directory over and it worked for me. Also, this latest time I was using the latest commit from codeplex.
I deleted cache.dat and restarted the website in IIS, this fixed it for me
Related
I am using play framework 1.2.7, gae module 1.6.0 and siena module 2.0.7 (also tested 2.0.6). This is a simple project that should run in play deployed on App Engine and connect to a MySQL database in Google Cloud SQL. My project runs fine locally but fails to connect to the database in production. Looking at the logs it looks like it is using the postgresql driver instead of the mysql one.
Application.conf
# db=mem
db.url=jdbc:google:mysql://PROJECT_ID:sienatest/sienatest
db.driver=com.mysql.jdbc.GoogleDriver
db.user=root
db.pass=root
This is the crash stack trace
play.Logger niceThrowable: Cannot connected to the database : null
java.lang.NullPointerException
at com.google.appengine.runtime.Request.process-a3b6145d1dbbd04d(Request.java)
at java.util.Hashtable.put(Hashtable.java:432)
at java.util.Properties.setProperty(Properties.java:161)
at org.postgresql.Driver.loadDefaultProperties(Driver.java:121)
at org.postgresql.Driver.access$000(Driver.java:47)
at org.postgresql.Driver$1.run(Driver.java:88)
at java.security.AccessController.doPrivileged(AccessController.java:63)
at org.postgresql.Driver.getDefaultProperties(Driver.java:85)
at org.postgresql.Driver.connect(Driver.java:231)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:215)
at play.modules.siena.GoogleSqlDBPlugin.onApplicationStart(GoogleSqlDBPlugin.java:103)
at play.plugins.PluginCollection.onApplicationStart(PluginCollection.java:525)
at play.Play.start(Play.java:533)
at play.Play.init(Play.java:305)
What is going on here? I am specifying the correct driver and url schema and it's using postgresql driver. Google Cloud SQL API access is enabled, the app is allowed to connect to the mysql instance, I am not using db=mem, ... I am stuck and can't figure out how to move forward! :-((
UPDATE: I thought I found the solution, but that was not the case. If I keep the %prod. prefix and create a war normally (or just don't define any DB properties), then the application will use Google DataStore instead of the Cloud SQL. If I create the war file adding --%prod at the end (or just delete the %prod. prefix in the application.conf), then it will keep failing to connect to the database showing the same initial error.
Any ideas please?
After being stuck for so long on this I just found the solution in no time after posting the question. Quite stupid actually.
The production environment properties in the application.conf file must be preceded by %prod. so the database config should read
%prod.db.url=jdbc:google:mysql://PROJECT_ID:sienatest/sienatest
%prod.db.driver=com.mysql.jdbc.GoogleDriver
%prod.db.user=root
%prod.db.pass=root
And everything runs fine.
EDIT: This is NOT the solution. The problem went away, but the app is using the DataStore instead of the Cloud SQL
At the end I ended doing a slight modification in play siena module source code and recompiling it.
In case anyone is interested, you will need to remove/comment/catch exception in this code around line 97 in GoogleSqlDBPlugin class:
// Try the connection
Connection fake = null;
try {
if (p.getProperty("db.user") == null) {
fake = DriverManager.getConnection(p.getProperty("db.url"));
} else {
fake = DriverManager.getConnection(p.getProperty("db.url"), p.getProperty("db.user"), p.getProperty("db.pass"));
}
} finally {
if (fake != null) {
fake.close();
}
}
For some reason the connection fails when initiated with DriverManager.getConnection() but it works when initiated with basicDatasource.getConnection(); which apparently is the way used by the module in the rest of the code. So if you delete the above block, and recompile the module everything will work as expected. If you are compiling with JDK 7, you will also need to implement public Logger getParentLogger() throws SQLFeatureNotSupportedException in the ProxyDriver inner class at the end of GoogleSqlDBPlugin file.
Strangely, I digged into the DriverManager.getConnection() and it looked like some postgresql driver is registered somehow, because otherwise I can't see why DriverManager.getConnection() would call to org.postgresql.Driver.connect().
I added a DataContract to my service and tried updating the service reference to get access to that DataContract. But it never showed up in the intellisense. I cleaned and built the project and then updated the service reference, but it still didn't work.
I then published it to the server and updated the service reference so it would point to the server, but I get the same thing. I browsed the service through IIS and opened my service in the browser.
I clicked the top link that had Service.svc?wsdl to see if my DataContract was there. An old MessageContract was there, but the DataContract was not.
Any ideas on what I'm doing wrong here?
Delete the currently deployed service binaries and verify that the service is inaccessible. Then deploy the new service binaries. This is to verify you're actually deploying to the correct location.
It is also possible that the service binaries aren't being rebuilt. To verify this, delete your bin folder (located next to your project file generally) and issue a rebuild, then follow the first steps.
I got my answer from here.
Only the types actually used by the service will be reflected in the metadata.
I didn't have an operation contract that used the DataContract. I didn't need to have one at the time, so I didn't make it. But apparently, unless you have one that uses it, the metadata won't be generated for that DataContract.
i am looking into upgrading my magento community from 1.6.2 to 1.7.0.2.
First i will do this on my test server, but there are some errors during updating in magento connect, so i have to upload some files my self ...
but when i going to put these data into the live environment, can i just simply copy my data from the ftp to the live website?
Or are there also some new/changed settings in the database?
And if yes on the last question, which lines are changed?
I was able to successfully upgrade Magento from 1.6.1 to 1.7.using Connect Manager.
Here are the steps I had foung and followed
Go to yourdomain. com/magento/downloader/ (of course, make this
match your installation’s path.
Because I had installed Magento using tar.gz package provided with a skin I wanted to use, Magento Connect didn’t have all the
extensions listed for upgrading. I had to type
“connect20.magentocommerce.com/community/Mage_All_Latest” in the
“Install New Extensions / Paste extension key to install”
If you run into an error along the lines of “CONNECT ERROR: Package ‘Mage_All_Latest’ is invalid” repeated several times, once
for each package, it is because the files already exist, and you
have to remove a line of code in order for it to over-write data.
After everything has updated, you will probably have some errors. Make sure you clean the cache and session directories (delete
everything in /var/cache and /var/session)
If you receive a “500 Internal Server Error” it is more than likely because of file and folder permissions. It took .5 sec to
reset all of the permissions to what they needed to be.
If you receive a “Service Temporarily Unavailable The server is temporarily unable to service your request” error on a Magento
formatted header, it is probably because the store is set to offline
mode to prevent visitors from screwing up the installation process.
To fix this, delete the“maintenance.flag” file found in the root of
your magento installation directory.
Everything should be ready!
Avoid upload core library changes via ftp.
The fastest and more secure way is to patch your application using the diff files
patch -p0 -f < 1.6.2.0-1.7.0.0.diff
Then when you first visit your site Magento will automatically upgrade your db
best way to update is get a fresh mage zip 1.7.1 or whatever, and connect it to your current DB. When you go to index - the new install will update your DB to the latest MAge DB. This way you dont have to use connect etc. The mage zip has its own sql updates.
Make sure you put your current theme into the new install etc, and test it 1st on localhost etc.
I was given a dotnetnuke v4.9.5.5 database (sql-express about 300MB) and I am trying to get it up and running on a different server. I have tried:
Installing the 4.9 version and
loading the database into the app_data folder
loading the database through the SQL page under the host login (forwards to 404 page...)
installing the 5.x version and
loading the database into the app_data folder
loading the database through the SQL page under the host login (forwards to 404 page... again..)
All of which fail. I cannot find any support on this topic at all. What is the correct way to go about this?
EDIT: wrong info please close..
Here is a good blog on the topic HOW TO: Move a DotNetNuke installation .
The basics are:
Copy all the files and the database, the two are closely tied together.
Update the connection string in the web.config.
Update the portal alias' in the PortalAlias table.
If you don't have the rest of the site files, it may be very difficult. While the database will contain most of the site content, you may be missing some important pieces like skin files, module files, and content files.
So, the first thing you should do is see if you can get the files zipped up and sent to you. If so, it should be fairly easy to get the site up and running. You may have to update the ConnectionStrings in the web.config but otherwise it should run as it.
If you can't get the original files, you could try installing version 4.9.5 of DotNetNuke and replacing the supplied database with the database you were given. You'll need to post the error messages you get if it doesn't work out or consult someone with solid DotNetNuke experience.
So I've installed an extension in my Magento Enterprise.
I've been able to configure new options in the admin interface after installing the module.
However in the frontend it complains "table not found". Checking the database that is indeed true. Seems the mysql4-*.php scripts have not been run or failed.
Is there a log or something I can look at to see what goes wrong? From what I've read (difficult to find documentation on this) the modules db should've been initialized on the first request after it was installed and activated.
Any other suggestions to what I can check to find out why it's not initialized properly?
First step is to check the core_resource table. If there's a row for your module, then zap it. This will retrigger the setup resource process.