I'am just starting with magnolia and at the very beginning it surprised me that Magnolia needs to be installed after each .war deploy to tomcat. I do some changes in my project, deploy it with mvn tomcat7:deploy/redeploy. Tomcat automatically recognise that ROOT.war has changed so it unpack it automatically and after that when I'm entering localhost:8080 it wants me to install Magnolia modules again. Is it really necessary to install all modules again and again after every single changes in my project and deploy? Maybe the way how I'm making changes in my project and deploying it is wrong? If I'am not mistaken in that way my content changes also will be overwritten/deleted?
You have to re-install Magnolia every time because I think that you delete your repository (database) every time that you deploy a new version. Probably you are saving your data in a folder inside webapps and every time that you deploy a new .war it is deleted.
If you want to keep your website and modules between deployments, I need to change the repository location to a different folder in the file system, or set a db connection.
You can do that by modifying the repositories.xml file or adding a custom jackrabbit conf file, in this article you will find a lot of useful info, and I suggest you to have a look into the paragraph 'Custom Jackrabbit configuration file'
Have a look at documentation on how to configure your Magnolia for details, but in essence it's enough if you open /WEB-INF/config/default/magnolia.properties and change magnolia.home= to point to the directory OUTSIDE of your webapp. By default it is set to be inside of the war file so you can wipe and reinstall Magnolia easily. In your case you want your data to be permanent, so you set it out. You should still read the article linked by Daniele about how to setup your devenv and you might still want to configure different database than derby for your production use, but you should keep all your data outside of the webapp too.
HTH,
Jan
Related
I'm trying to develop an application using Google App-Engine and Maven using Eclipse. I am facing a problem where by whenever you change a CSS or JSP file, a restart of the application is required. This makes working quite difficult, since a reload takes a lot of time.
For example when you develop on tomcat no need for restart is required when such a change is made, only Java or xml file require restart of the server.
Is there a solution that mimics the tomcat behavior on GAE SDK when developing on localhost?
If you've built using the standard app engine maven archetype, when you run mvn appengine:devserver from you -ear directory, the exploded war working directory is located here:
<yourapp>/<yourapp>-ear/target/<yourapp>-ear-1.0-SNAPSHOT/<yourapp>-war-1.0-SNAPSHOT.war
If you change any JSPs in this directory, they will get reloaded without needing to restart the devserver.
Thus, you can set up a simple script or command that copies all your JSPs and static files from /-war/src/main/webapp to that deploy directory whenever you want your files to be refreshed. I saw on some threads where people set up their IDE (in this case IntelliJ) to automatically do that copy whenever the IDE loses focuses, which makes it trivial to get pages reloaded.
Building application with appengine in eclipse using maven is not very effective and time consuming because on every change on jsp/css/js with a traditional approach there is a need to restart appengine or mvn appengine:devserver.
#adevine make me thought about a solution, and I found this link: http://andrei.gmxhome.de/filesync/index.html wich installs a plugin in eclipse, then I activate the project to sync files from myapp/src/main/webapp to a target folder generated by maven myapp/target/myapp-snapshot-0.0.1.
It's working!!!
Whenever a change is done in webapp the files are transfered automtically(no need to run anything else, just save the file) to the target folder and are reloaded successfully.
Hope this could help people because its frustrating working with appengine(restarts takes a lot).
The last Java project I was on used Tomcat as the server my new Java project is using JBOSS.
I am a front-end designer that needs to make frequent and rapid changes to JSP, HTML, CSS and JS files. Here is a rundown of what is happening...
In Tomcat, when an app is deployed into the webapps directory, it is automatically exploded. From there I can stop the server, create symbolic links pointing from the webapps/myapp directory to my GIT repository, ~/somedir/myapp and then restart tomcat. This way I am always working on my local repository and when I make a change in my IDE then go to the browser and refresh, the changes are there instantly.
In JBOSS, things are a bit different. When an app is deployed into the standalone/deployments directory, it remains compressed as a .war file.
I have tried expanding the .war file manually and renaming the folder to myapp.war and that seemed to work, however, JBOSS still re-deployed the app once it noticed there was a change to one of the files, which kinda defeats the purpose.
I have been searching for a couple of days now before asking this question as a last resort.
Does anyone happen to know of a way to accomplish in JBOSS what I was able to accomplish in Tomcat?
Thank you in advance!
I use Eclipse Indigo (EE) to build applications in Java framework Vaadin,
using Tomcat 7.0 server. After changes in code I wont see result in a browser,
so I need to click option "Clean Tomcat Work Directory.." and wait until
Tomcat stop and start a server.
Otherwise, when I refresh app page, I don't see any changes.
Even when I restart server (and when eclipse automatically restart it when I save changes), without cleaning tomcat directory.
Option "Automatically publish when resources change" is enabled.
Is any faster way to do that? or can I automate that process?
Additionally to the answer of Kowser, it is possible do hot code changes when running tomcat in debug mode.
Otherwise you could investigate in JRebel
In your "Modules" tab of your Tomcat, you hace to clic on 'Edit' and uncheck the 'Auto reloading enables' option.
With that, several changes won't need a restart (as long as you start your server in debug mode).
If you setup your project to use ant for building and deploying, you can simply add Ant builder to your project Builders to run your ant build and deploy targets every time after you have saved a file. Then provided that tomcat is configured to support auto-deploy, this should achieve what you want, with two caveats:
If your project takes more than a few seconds to build, building after every save is not practical.
You may run out of memory for the tomcat instance if the same app is deployed to it repeatedly for a number of times. This can happen if tomcat is somehow unable to recover all the memory from undeployed resources.
It might be possible. But your setup is a bit different from what I use. I am just using tomcat+eclipse to do Servlet development using Velocity and Torque.
The following works for me where changes are visible in the browser as soon as I save in eclipse.
I assume that you have a project directory such as
apache-tomcat-7.0.11/webapps/$YOU_PROJECT/WEB-INF/classes/
Create a symbolic link with ln -s from your eclipse project directory and to the classes directory in WEB-INF.
Then configure eclipse to write all .class files to this directory. (Done by right clicking on the project in Eclipse and choosing Properties and then Java build path.
In your $tomcat/conf/context.xml config file first tag should be:
<Context allowLinking="true" reloadable="true">
Also add the following as a child to if it is not already there.
<WatchedResource>WEB-INF/web.xml</WatchedResource>
That is what I have done, but I am not sure it works with your EE tools.
ps: This solution assumes that you are using linux/unix. I don't know if it works with windows. The major problem is that eclipse can't write class files outside the project directory (Which is why that symlink is required).
btw: Tomcat may(Depending on class loader, used .jar files and other complicated details) leak a lot of memory when automatic reload is enabled so you may want to increase the allowed memory(Mostly permgen) to prevent out of memmory exceptions from tomcat.
I know this has been asked and answered very long ago. But use this info if it is helpful to anyone of you. I use Eclipse Kepler and configured Tomcat 7 server inside eclipse. I don't have to do any other configuration but to just uncheck Update context paths check box. That is all. Leave other setting as default.
In this way, changes to the resources files (xhtml pages, css files etc.) as well as the java source code files show up in the browser. Only for class files the web application would be redeployed (no server restart auto as well as manual required).
Location of Update context paths: Double click on the tomcat server under Server tab. Under Publishing tab you would find this Update context paths check box.
Absolutely no other change needs to be done for the auto publishing. This works both in normal and debug mode of tomcat.
Screen shot from my eclipse below:
No, there is no other way.
You will notice immediate changes only while updating a JSP/HTML/etc.... Classes will not be loaded/refreshed automatically. It will be contradictory to change a loaded/instantiated class when server is live, isn't it? At least it should not be possible.
It's better to perform Unit Test while developing something. It can help you to reduce the amount of annoying server restarts.
I am relatively new Java developer that's been thrown in the deep end, my usual skillset lies in Microsoft products and C#.
However I have managed to write a nice web service using Restlet and incorporating Toplink and doing some database CRUD stuff, etc etc.
I developed this in Eclipse against Tomcat 5.5. I followed tutorials and examples and managed to throw something together that works.
I had all my jar files in WebContent/WEB-INF/lib directory of my project - I soon realised that when I export this as a WAR file and deploy in Tomcat, it takes these jar files with it and stores them local to the application.
Fine, but then when you try to undeploy the app, it only does it partially as Tomcat "holds on" to some of the jars it was using i.e. the Oracle JDBC, and Toplink ones. This makes sense as the web service was using these jars as there was a live Oracle connnection going on.
So then I thought I should have all these jars in a common place where all deployed apps can access them, that folder I believe is:
C:\Program Files\Apache Software Foundation\Tomcat 5.5\common\lib
(in my case). This made total sense, it's logical as you don't want loads of apps on Tomcat all referencing the same jars. So I removed all the jars out of my projects lib folder and put them in the common\lib directory.
Now my app will not work properly - it can't find my source code in src, the custom bespoke code that I have programmed against these jars. It will only work if I jar up my source code and put in the directory stated above. Odd.
I am obviously very confused with class paths and build paths and all of that stuff, and must have got this sort of stuff all wrong as I am no Java expert, as I readily admit I have pretty much hacked this together - so can anyone explain to me in laymans terms how I should structure my project to get it working with jars held in a common folder in Tomcat. Or are there any good resoureces on the web to help explain to me what I should do.
Hope this all makes sense...
Here is a pic of my current project:
Sounds like you are not using WTP web project.
If you've installed 'Eclipse IDE for Java EE Developers' flavor of Eclipse, the WTP is already bundled in there. Otherwise here its update site -> http://download.eclipse.org/webtools/updates
Once you've installed WTP you should create 'Dynamic Web Project'.
In general I would recomment to put only your presentation layer here ( JSPs, CSS, HTML ) and put all pure java projects into standard 'Java' project that you later add as a dependency to 'Dynamic Web Project'.
WTP can run your web application under a number of containers, fortunately Tomcat is supported.
You will need to configure it through Window->Preferences->Server->Runtime Environments.
Once runtime envirnonment is configured, you can create your server runtime:
Right click in 'Servers' view.
Choose New->Server
Select server type: 'Tomcat v.5.5 Server'
(Optional) Change server name to whatever makes sense for you
Select server runtime environment: This is the Runtime Environemtn that you have configured previously
Hit 'Next' button
Add your 'Dynamic Web Project' project to 'Configured projects:' panel
Hit 'Finish' button
After the server is configured you can just run it, or you can put it in Debug mode. All source code referenced by dependent projects will be available for debugging.
NOTE:
From personal experience, I would not recommend using common/lib. Put all the jars that your web application relies upon into its WAR file. If you are worried about dependency tracking then start looking into Maven and m2eclipse.
Usually I put my jars in $CATALINA_BASE/shared/lib/
Please read this documentation for more clarification and specially Class Loader Definitions section.
Also restart the server after you copied the jars.
Go to Window > Show View > Other > Server > Servers, a servers tab will appear below with console tab. Click on your server and then F3, this will open server configuration.
Check Server Locations, and make sure you checked Use tomcat installation(takes control of tomcat installation) then click Modules tab below and it will show your installed modules, make sure the module is present or add it.
I've finally managed to create a Netbeans project out of an old standalone (not Web-) Java application which consisted only out of single .java sources. Now I have basically two questions regarding Netbeans Subversion interaction and application deployment:
Do you check in all the Netbeans project files into the repository, normally?
If I build the project using Netbeans (or ant) I get a .jar file and some additional jar libraries. In order for the app to run properly on the server, some additional config files and directories (log/ for example) are needed. The application itself is a J2SE application (no frameworks) which runs from the command line on a Linux platform. How would you deploy and install such an application? It would also be nice if I could see what version of app is currently installed (maybe by appending the version number to the installed app path).
Thanks for any tips.
No, not usually. Anything specific to NetBeans (or Eclipse, IntteliJ, etc), I don't check in; try to make it build from the command line with your ant script and produce exactly what you want. The build.xml is something that can be used for other IDEs, or in use with Anthill or CruiseControl for automated builds/continuous integration, so that should be checked in. Check in what is needed to produce/create your artifacts.
You don't specify what type of server, or what exact type of application. Some apps are deployed via JNLP/WebStart to be downloaded by multiple users, and have different rules than something deployed standalone for one user on a server to run with no GUI as a monitoring application. I cannot help you more with that unless you can give some more details about your application, the server environment, etc.
Regarding the config files, how do you access those? Are they static and never going to change (something you can load using a ResourceBundle)? ? You can add them to the jar file to look them up in the ResourceBundle, but it all depends on what you are doing there. If they have to be outside the jar file for modification without recompiling, have them copied with an installer script.
As for directories, must they already exist? Or does the application check for their existence, and create them if necessary? If the app can create them if absent, you have no need to create them. If they need to be there, you could make it part of the install script to create those folders before the jar files are installed.
Version number could be as simple as adding an about box somewhere in the app, and looking up the version string in a config/properties file. It has to be maintained, but at least you would be able to access something that would let you know you have deployed build 9876.5.4.321 (or whatever version numbering scheme you use).
Ideally, you should not tie down your application sources and config to a particular IDE.
Questionwise,
I suggest you do not. Keep you repository structure independent of the IDE
You might have to change your application so that it's structure is very generic and can be edited in any IDE.
Is this a web app? A standalone Java app? If you clarify these, it would be easier to answer your query.
We don't check in the /build or the /dist directories.
We tend to use this structure for our Netbeans projects in SVN:
/project1/
/trunk
/tags/
/1.0
/1.1
/binaries/
/1.0
/1.1
When a change is need we check out the netbeans project from trunk/ and make changes to it and check it back in. Once a release of the project is needed we do an SVN copy of the netbeans project files to the next tag version. We also take a copy of the deployable (JAR or WAR) and place it in the version directory under binaries along with any dependencies and config files.
By doing this we have a clean, versioned deployable that is separate from the source. Are deployables are version in the name - project1-1.0.jar, project1-1.1jar and so on.
I disagree with talonx about keeping your source non-IDE specific - by not storing IDE files in SVN along with you source you are adding extra complication to the checkout, change, checkin, deploy cycle. If you store the IDE project files in SVN you can simply check out the project, fire up the IDE and hit build. You don't have to go through the steps of setting up a new project in the IDE, including the files you SVNed, setting up dependencies etc. It saves time and means all developers are working with the same setup, which reduces errors and discrepancies. The last thing you want is for a developer to check out a project to make a small bug fix and have to spend time having to find dependencies and set stuff up.
To answer question #2 -- who's your consumer for this app?
If it's an internal app and only you (or other developers) are going to be deploying it, then what you have is perfectly all right. Throw in a README file explaining the required directories.
If you're sending it out to a client to install, that's a different question, and you should use an installer. There are a few installers out there that wrap an ant script and your resources, which is a nice approach particularly if you don't need the GUI... just write a simple ant script to put everything in the right place.
Version number is up to you -- naming the JARs isn't a bad idea. I also have a habit of printing out the version number on startup, which can come in handy.