Trying to get SQLite working with grails...stuff I've found on the web seems a little dated - references to ivy and plugins and such, but based on these:
http://stackoverflow.com/questions/1199512/grails-sqlite
http://bigohno.blogspot.com/2010/01/groovy-on-grails-sqlite.html
http://maven-repository.com/artifact/org.xerial/sqlite-jdbc/3.6.17
I've been able to get it working in a test environment...oddly, when I "prod war" my grails app and deploy to tomcat it fails with:
Dialect class not found: hibernate.SQLiteDialect
Here's my setup:
in conf/hibernate added a class for the SQLiteDialect. This .java was taken from here http://code.google.com/p/hibernate-sqlite/
Then in my DataSource.groovy I have:
hibernate {
cache.use_second_level_cache = true
cache.use_query_cache = false
cache.region.factory_class = 'net.sf.ehcache.hibernate.EhCacheRegionFactory'
}
// environment specific settings
environments {
development {
dataSource {
// SQLite
// !!!see also BuildConfig for Dependancies!!!
dbCreate="update"
url='jdbc:sqlite:C:\\sqlite-shell-win32-x86-3080100\\rss_1.db'
logSql="true"
dialect="hibernate.SQLiteDialect"
driverClassName="org.sqlite.JDBC"
readOnly="true"
}
}
production {
dataSource {
// SQLite
dbCreate="update"
url="jdbc:sqlite:/opt/sqlite/dbs/rss/1/rss_1.db"
logSql="true"
dialect="hibernate.SQLiteDialect"
driverClassName="org.sqlite.JDBC"
readOnly="true"
showsql="false"
}
}
}
and in BuildConfig.groovy I have:
dependencies {
runtime 'org.xerial:sqlite-jdbc:3.6.17'
}
I also jar'd up the .java dialect class and put in in lib - some posts said this helped. I also put sqlite-jdbc-3.7.15-M1.jar in lib.
Now when I run-app in my dev environment it runs fine...but when I deploy to tomcat I get the dialect error.
Is there something special I need to do to the prod environment for the dialect?
Here's how to setup SQLite with Grails:
Download SQLite from http://www.sqlite.org/download.html , extract and save to a directory. You may also want to create directories for your databases.
Download SQLite JDBC jar from https://bitbucket.org/xerial/sqlite-jdbc and put the jar in your grails lib directory.
Download a SQLIte dialect...google search as there are many, but you may reference https://github.com/gwenn/sqlite-dialect or https://gist.github.com/virasak/54436
In grails, create a class in src/java and put your dialect code in.
I also jar'd this class up and put the jar in lib.
Setup your grails datasource, e.g.,:
dataSource {
// SQLite
dbCreate="update"
url="jdbc:sqlite:/opt/sqlite/dbs/rss/1/rss_1.db"
logSql="true"
dialect="SQLiteDialect"
driverClassName="org.sqlite.JDBC"
}
NOTE: Depending on whether your sqlite dialect class is in a package, you may need to prefix the package name to the dialect above (mine was not).
In BuildConfig.groovy, add a dependency to sqlite jdbc, like so:
dependencies {
runtime 'org.xerial:sqlite-jdbc:3.6.17'
}
That's what worked for me!
Related
I'm trying to create app based on Jetty 9.4.20 (embedded) and Vaadin Flow 14.0.12.
It based on very nice project vaadin14-embedded-jetty.
I want to package app with one main-jar and all dependency libs must be in folder 'libs' near main-jar.
I remove maven-assembly-plugin, instead use maven-dependency-plugin and maven-jar-plugin. In maven-dependency-plugin i add section <execution>get-dependencies</execution> where i unpack directories META-INF/resources/,META-INF/services/ from Vaadin Flow libs to the result JAR.
In this case app work fine. But if i comment section <execution>get-dependencies</execution> then result package didn't contain that directories and app didn't work.
It just cannot give some static files from Vaadin Flow libs.
This error occurs only if i launch packaged app with ...
$ java -jar vaadin14-embedded-jetty-1.0-SNAPSHOT.jar
... but from Intellij Idea it launch correctly.
There was an opinion that is Jetty staring with wrong ClassLoader and cannot maintain requests to static files in Jar-libs.
The META-INF/services/ files MUST be maintained from the Jetty libs.
That's important for Jetty to use java.util.ServiceLoader.
If you are merging contents of JAR files into a single JAR file, that's called a "uber jar".
There are many techniques to do this, but if you are using maven-assembly-plugin or maven-dependency-plugin to build this "uber jar" then you will not be merging critical files that have the same name across multiple JAR files.
Consider using maven-shade-plugin and it's associated Resource Transformers to properly merge these files.
http://maven.apache.org/plugins/maven-shade-plugin/
http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html
The ServicesResourceTransformer is the one that merges META-INF/services/ files, use it.
As for static content, that works fine, but you have to setup your Base Resource properly.
Looking at your source, you do the following ...
final URI webRootUri = ManualJetty.class.getResource("/webapp/").toURI();
final WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));
That won't work reliably in 100% of cases (as you have noticed when running in the IDE vs command line).
The Class.getResource(String) is only reliable if you lookup a file (not a directory).
Consider that the Jetty Project Embedded Cookbook recipes have techniques for this.
See:
WebAppContextFromClasspath.java
ResourceHandlerFromClasspath.java
DefaultServletFileServer.java
DefaultServletMultipleBases.java
XmlEnhancedServer.java
MultipartMimeUploadExample.java
Example:
// Figure out what path to serve content from
ClassLoader cl = ManualJetty.class.getClassLoader();
// We look for a file, as ClassLoader.getResource() is not
// designed to look for directories (we resolve the directory later)
URL f = cl.getResource("webapp/index.html");
if (f == null)
{
throw new RuntimeException("Unable to find resource directory");
}
// Resolve file to directory
URI webRootUri = f.toURI().resolve("./").normalize();
System.err.println("WebRoot is " + webRootUri);
WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));
I have experienced certain problems when using libraries in premake4 scripts.
1) When creating a shared library (.dll) on Windows 10 using a premake4 script, it creates the dll fine, but it also creates a static library of small size (2K).
In my case, I was creating a shared library named MathLib.dll using a premake4 script. It did that correctly, but it also created a file named libMathLib.a of size 2K. (It may be empty.)
I don't see why there was a need for the Makefile generated by premake4 to create libMathLib.a, when in fact the objective was to create a .dll file. I think this may be a premake4 bug and I have raised it on the premake4 Issue tracker on github.
The premake4 lua script is as follows:
-- Dir : Files > C > SW > Applications > Samples >
-- premakeSamples > premake-sharedlib-create
--#!lua
-- A solution contains projects,
-- and defines the available configurations
solution "MathLib"
configurations { "Debug", "Release" }
-- A project defines one build target
project "MathLib"
kind "SharedLib"
language "C++"
files { "**.h", "**.cpp" }
includedirs {"../../../ProgramLibraries/Headers/"}
-- Create target library in Files > C > SW >
-- Applications > ProgramLibraries
targetdir "../../../ProgramLibraries/"
configuration "Debug"
defines { "DEBUG" }
flags { "Symbols" }
configuration "Release"
defines { "NDEBUG" }
flags { "Optimize" }
-- Register the "runmakefile" action.
newaction
{
trigger = "runmakefile",
description = "run the generated makefile to create the executable using the default ('debug' config)",
execute = function()
os.execute("make")
end
}
-- Register the "runmakefilerelease" action.
newaction
{
trigger = "runmakefilerelease",
description = "run the generated makefile to create the executable using the 'release' config)",
execute = function()
os.execute("make config=release")
end
}
2) The above problem is more serious than it sounds. Supposing I had already created a genuine static library named libMathLib.a in the Libraries dir, using a separate premake4 script. Subsequently, if I also create a shared library named MathLib.dll in the same directory as the static library, a dummy static library (possibly empty) would be created and replace the earlier genuine static library.
3) -- EDIT -- : I had reported this point (use of a static library) as a problem, but it has started working now. I don't know the reason, but the only difference, as far as I am aware, is that I had shut down and restarted my PC (and therefore my MSYS session on Windows 10). Therefore I am deleting this point.
How can I solve the above 2 problems?
That's the import library. You can turn it off with Premake's NoImportLib flag.
flags { "NoImportLib" }
We are trying to update the schema of an Sqlite database during continuous integration. Here is a simplified version of our scenario.
The deployment script publishes the project.
cd App
App> dotnet publish <args>
That creates the following directory structure.
artifacts/
App.dll
Database.sqlite
The-rest-of-the-publish-output
web.config
App/
Migrations/
Program.cs
project.json
Startup.cs
The deployment script then runts the migrations.
App> dotnet ef
--assembly ..\artifacts\App.dll
--startup-assembly ..\artifacts\App.dll
database update
The issue is that we receive the following message:
Unexpected value '..\artifacts\App.dll' for option 'assembly'
We have also tried other ways to run dotnet ef database update on the compiled project but have not been able to determine how to update the database in the artifacts directory.
In our current scenario, we do it like this on Startup.cs:
if (migrateDb)
{
try
{
using (var serviceScope = app.ApplicationServices.GetService<IServiceScopeFactory>()
.CreateScope())
{
serviceScope.ServiceProvider.GetService<ApplicationDbContext>()
.Database.Migrate();
}
}
catch { }
}
while on development migrateDb resolves to false so we can add/remove and apply migrations as desired. On production that will resolve to true for convenience.
There may be well more valid/appropiate options, usually depends on the context and/or project needs. This is just one way of many.
I'm attempting to minify my .JSX files with ASP.NET Minification and Optimization via System.Web.Optimization.React. I've installed the MVC4 React Package as well as the Optimization package, but whenever I try to include a bundle I get the following:
React.TinyIoC.TinyIoCResolutionException: Unable to resolve type: React.IReactEnvironment
The InnerException is always null
My bundles are setup as follows:
bundles.Add(new ScriptBundle("~/Bundle/Scripts/ReactJS").Include(
"~/Scripts/React/react-0.12.2.js",
"~/Scripts/React/react-with-addons-0.12.2.js",
"~/Scripts/React/JSXTransformer-0.12.2.js"
));
bundles.Add(new JsxBundle("~/Bundle/Scripts/ReactCalendar").Include(
"~/Scripts/React/Calendar/Main.react.jsx",
"~/Scripts/React/Calendar/Components/Calendar.react.jsx",
"~/Scripts/React/Calendar/Components/CalendarEvent.react.jsx",
"~/Scripts/React/Calendar/Components/CalendarControls.react.jsx",
"~/Scripts/React/Calendar/Components/CalendarTimeSlots.react.jsx"
));
And included in the view as:
#section scripts{
#Scripts.Render("~/Bundle/Scripts/ReactJS");
#Scripts.Render("~/Bundle/Scripts/ReactCalendar");
}
The error is always thrown on line:
#Scripts.Render("~/Bundle/Scripts/ReactCalendar");
Anyone got any ideas on how to solve / debug this one? Let me know if more info is needed.
I'm not sure if this is the same issue I was facing, but I googled the exact same error, found this SO topic as the first hit, with no definitive answer, so I thought I'd offer my solution.
I'm using .NET 4.5 in an MVC app, and React.Web.Mvc4 v3.0.0.
I managed to work around this issue with the help of this comment on Github.
Here's my entire ReactConfig.cs:
using React;
using React.TinyIoC;
using React.Web.TinyIoC;
namespace NS.Project
{
public static class ReactConfig
{
public static void Configure()
{
Initializer.Initialize(AsPerRequestSingleton);
ReactSiteConfiguration.Configuration
.SetLoadBabel(false)
.AddScriptWithoutTransform("~/React/dist/server.bundle.js");
}
private static TinyIoCContainer.RegisterOptions AsPerRequestSingleton(
TinyIoCContainer.RegisterOptions registerOptions)
{
return TinyIoCContainer.RegisterOptions.ToCustomLifetimeManager(
registerOptions,
new HttpContextLifetimeProvider(),
"per request singleton"
);
}
}
}
Then, I'm callingReactConfig.Configure explicitly from Application_Start.
"Unable to resolve type: React.IReactEnvironment" with no InnerException generally means ReactJS.NET is not initialising properly for some reason. In web apps, ReactJS.NET handles initialisation through the use of WebActivator. Make sure your project is referencing React.Web, React.Web.Mvc4 and WebActivatorEx, and all the corresponding .dll files are ending up in your app's bin directory.
Also, you do not need to (and should not) include JSXTransformer in your JavaScript bundles, as ReactJS.NET does all the JSX compilation server-side.
Something looks like changed from React.Web.MVc4 version 4.0.0. versions before didnt have that problem.
as stated here
Install the React.Web.Mvc4 package through NuGet. You will also need to install a JS engine to use (either V8 or ChakraCore are recommended). See the JSEngineSwitcher docs for more information.
To use V8, add the following packages:
JavaScriptEngineSwitcher.V8
JavaScriptEngineSwitcher.V8.Native.win-x64
ReactConfig.cs will be automatically generated for you. Update it to register a JS engine and your JSX files:
using JavaScriptEngineSwitcher.Core;
using JavaScriptEngineSwitcher.V8;
[assembly: WebActivatorEx.PreApplicationStartMethod(typeof(React.Sample.Mvc4.ReactConfig), "Configure")]
namespace React.Sample.Mvc4
{
public static class ReactConfig
{
public static void Configure()
{
ReactSiteConfiguration.Configuration
.AddScript("~/Content/Sample.jsx");
JsEngineSwitcher.Current.DefaultEngineName = V8JsEngine.EngineName;
JsEngineSwitcher.Current.EngineFactories.AddV8();
}
}
}
If anyone needs this, just install this nuget and it will resolve this issue.
System.Web.Optimization.React
So I have a Q_OBJECT tagged class, which requires pregenerated .moc to be usable.
In my .qbs file, I have a CppApplication item; this seems to be the wrong type of project, as qbs does not call moc ClassName.cpp to generate moc's for me. What should be used instead/tweaked?
-
So I knew about Qt.core dependency, but it wasn't working on my crippled install of Qt; while I was trying to fix it, these facts came up:
It was required to detect Qt toolchain (qbs-setup-qt) and call qbs-config-ui
Qbs indeed stores the build rules in core.qbs, linked in via Qt/core dependency.
it's possible to copy/paste the build rules into my own .qbs file and avoid external dependencies; I'm considering this as a dirty hack for deploying the code on really crippled build systems (now I have a word for Qt support on Gentoo).
I think you might be missing the dependency of the application on the Qt-modules.
The rule for generation of the moc files is part of the Qt.core module.
You might add this dependency with:
CppApplication {
name: "MyApp"
files: "path_to_source/**"
Depends { name: "Qt.core" } // Optional
Depends { name: "Qt.widgets" }
}
As all other Qt modules have an implicit dependency on Qt.core the explicit dependency could on Qt.core could be skipped if there is a dependency on a different Qt-module (Qt.widgets in this example).
More details could be found at http://doc.qt.io/qbs/qt-modules.html