I created a simple desktop application that uses embedded database(derby) from netbeans.After adding two entries into the table inside the ide and running it again works perfect.But when i double click the executable jar file outside the ide an empty database is shown what might be the reason? I would also like to know how to make this run on client machine.I tried adding the jar and lib files into a folder and converting it into a rar file but i don't find the jar file after extracting.I am new to this and any help would be appreciated.thanks in advance
There are two common reasons why you find that you are getting an empty database unexpectedly:
You are saying ';create=true' and using a relative database name, meaning that you are giving Derby permission to create the database fresh if it doesn't exist, and then your Derby system home directory is changing from run to run, so you are ending up creating new copies of the database each time, in different current directories.
You are using a different username when you connect to the database. Since the username with which you connect implicitly specifies the schema in which your tables reside, using a different username causes you to see a whole different set of tables, or, depending on how you look at it, an empty database.
Regarding jars and rars and such, the crucial thing is to manage your CLASSPATH properly. You need to have the Derby code in your CLASSPATH at runtime. There are a large variety of ways to make this happen, so you'll need to be quite explicit about the particulars of your situation in order for others to give you much help.
Related
I have a fully working JBoss 6.3.3.GA instance but one of my colleagues unwittingly connected to my Development server instead of his, and updated my Standalone.xml file.
He made a lot of changes and there's no way (at least I didn't find any one) to get my old file back.
Now I need to restart my server, and I'm afraid I'll loose my current configuration forever since his update will be taken into account.
My question is : Is there anyway I can find my current XML Standalone configuration in any temporary folder or something like that ?
Under your jboss directory go to : standalone/configuration/standalone_xml_history.
You should find different versions : standalone.boot.xml, standalone.initial.xml, standalone.last.xml ... etc
You will also find old configurations of your standalone stored in folders which names include the date when you made those configurations includig a folder containing your current configuration.
I'm trying the Play framework with Scala and Slick for data access.
I'm playing with the play-scala-intro example app. I'm trying to set up my own database instead of using the bundled in memory H2 database.
I can't figure out how to specify the path to the database file.
If the code in application.conf reads:
slick.dbs.default.db.url="jdbc:sqlite:/test.db"
slick.dbs.default.db.driver="org.sqlite.JDBC"
where should my test.db file be placed?
Does that mean the test.db file should be in the home directory of the web app, meaning the root play-scala-intro dir, or the app/assets dir?
I'd say storing your database in Java resources (and that's where assets will end up) doesn't sound like a good idea to me. I would be surprised if nothing went wrong during e.g. writing to DB.
It would be better to have it in the same directory as JAR, and even better set some defaults and let them be overridden:
database.location="test.db"
database.location=${?DBLOCATION}
slick.dbs.default.db.url="jdbc:sqlite:"${database.location}
This should assume that your database is names test.db and placed in your working directory (see: https://stackoverflow.com/a/21061029/1305121). It can be overridden using environment variable DBLOCATION like:
export DBLOCATION="/tmp/my/database.db"
# run Play application
Here's what I know:
When uploading files given by users, we should put them in a folder
outside the deployment folder. Let me call it D:\uploads.
We should (somehow) add that folder (D:\uploads) as a web app context.
Here's what I did:
I upload my files to the folder D:\uploads.
I tried adding the web app context as it's mentionned here by adding the following row to TOMCAT_DIR/conf/server.xml:
<Context docBase="D:\uploads" path="/uploads"/>
But that doesn't have any effect. When consulting http://localhost:8080/uploads/file.png or http://localhost:8080/uploads I get a HTTP Status 404 error.
So what I want to know:
What did I do wrong ? How can I add my upload folder to Tomcat?
Is there any better approach when it comes to uploading files ?
Because I'm wondering what should I change if I want to deploy my
application to another server where there's no D:\uploads.
Change the docBase attribute. Use D:/uploads (with slash) instead of D:\uploads (with backslash).
When dealing with files in Java, you can safely use / (slash, not backslash) on all platforms.
Regarding the differences you mentioned in the comments when starting the Tomcat from the IDE and from bin/startup.bat: It's very likely when you start the Tomcat from the IDE, it is not using the same context.xml your Tomcat is using. Just review the Tomcat settings in the IDE.
How to store uploaded files is a common topic at Stack Overflow. Just look around and you'll get surprised in how this topic is popular.
If you aren't happy enough in storing your files in D:/uploads or you'll have other servers accessing the files, you could consider storing them in some location in your network. Depending on your requirements, you can have one dedicated server to store your files or just share the folder which contains the files in your current server. The right decision will always depend on your requirements.
It is convenient when you have DEVELOPMENT version of application on your local machine and you may deploy it on STAGE server for testing (it's optional) and then deploy it on PRODUCTION server. You can do this relatively easily when there is a fine discretion of code and data in the project (for example, if we store all the code and settings in project files and data in database).
MODX stores templates, snippets, etc. in database. Yes, we can move this code to static files and then we can use version control system for tracking changes of these items. But these ones have representation rows in database too. It means we must update database as before if we added or removed some items.
Looks like we can also get some troubles if we just copied files of extensions instead of making installation by package manager (because extensions often have its own tables in DB).
Another problem is that applications on DEV and PROD have different settings stored in files (configs) and database (user accounts, e.g.).
I do not still see the clear way to organize iterative DEV-STAGE-PROD development cycle. So, my questions are:
Which files and database tables should (or must) I copy when deploying?
What is the mode (replace, ignore) I should do that in?
What is the easiest and fastest way to do that?
My biggest concern here is having to deal with database.
P.S. I'm talking about "Revolution" version of MODX if it matters.
The database should not store any path information at all, previous versions did in the modx_workspaces table, but that has since disappeared [as of 2.2.4 I believe].
If you are concerned about the url changes [dev.mysite.com / stage.mysite.com / production...] don't be - this is all in the .htaccess file [there used to be a site_url system setting, but it also seems to have disappeared.]
The only file you need to worry about is the core/config/config.inc.php ~ create 3 different files with the different paths or just replace them when you migrate.
my process for moving/updating/migrating modx sites is:
clear the cache!!
tar cvfz httpdocs.tar.gz httpdocs/
mysqldump -u -p the_database > export.sql
move the files, tar xvfz & import the database.
It's a good idea to check the modx_workspaves table and if you have used an older version of gallery, check that as well, but most plugins & developers seem to be used to NOT storing path information in code & DB tables.
Of course if you have hardened your installation there are a few more steps, but nothing major. [see the "hardening Modx article on rtfm.modx.com]
I think what you're looking for is this plugin (depending on your version of modx):
https://github.com/digitalbutter/MODX-Mirror
https://github.com/digitalbutter/FEM
All Chunks, Snippets etc. are located on disk. Any changes made to the files will trigger the appropriate database changes without the need to do a complete SQL Import/Reimport. This will allow for any Version Control System / Distributed Development Environment / Automated Deployment.
I store all SSIS packages in Subversion repository, their configuration files as well. Configuration file almost always stored in the same folder where package is.
Problem is - SSIS seems to always store path to configuration file (the one saved in the package itself) as an absolute path.
When someone else checks out folder with the package in the location different from where I had on my development PC the configuration file is not detected (because my absolute path is stored and it doesn't exist on the other developer PC). So another developer has to remove this configuration and add it again from where it is now on his local hard drive. Then changed package is saved which will cause new version to be committed. When I get that version from SVN it will no longer match local path on my PC.
On a related note: another developer may want to change values in configuration file as well. If I later get the latest version of everything from SVN package will no longer work on my PC.
How do you work around these inconveniences?
Another solution is to save your configuration in a database with an environment variable as the first configuration to tell it what database to look in, that's what we do. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable we are using.
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
#HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
I add a folder called "config" under my projects folder, add it to source control and mantain the config file in this folder. You can also add it to the SSIS project if you like.
I think its a good solution because everybody can have this folder and dowload the config file.
When the package is deployed it will read the config file from where you inform in the deployment manifest so this solution wont impact your development