I try to work with M2Eclipse, WTP and a Tomcat 5.5 server configuration.
Publication of classes + web resources in wtp.deploy directory seams very time consuming if your webapp contains many files. Furthermore publishing operation can be prone to error as I have many maven modules as dependencies. I try to find a biaised-but-faster way to use WTP.
With Java sources in
src/main/java
src/main/resources
with default maven output directory
target/classes
And web resources in
src/main/webapp
I want to make WTP work with a Tomcat server this way :
M2Eclipse is responsible of the
build (nothing to do)
No publication phase :
WTP points to maven classes build output (don't know how to do this ?)
WTP points directly to the web resources (possible tweaking the docbase)
WTP take into account any change I do either on classes or web resources (not sure it's possible for classes without restarting tomcat ?)
Is it possible or should I move to maven jetty plugin ?
Any help is apreciated :)
What you want is probably the "Serve modules without publishing" setting to let allow tomcat straight access to the eclipse-generated resources.
In the servers view, double click the server name, e.g. "Tomcat v6.0 ...", the setting is under the "Server Options" heading.
Starting tomcat in debug mode enables hot code replace.
Source: http://www.eclipse.org/forums/index.php?&t=msg&goto=523599
I don't think it is possible to make WTP work that way. The way WTP work with Tomcat is it creates a staging directory/project in workspace that it synchronizes with your project (I believe it is incremental). So, the WTP does all the copying files around and tracking modified resources and classes.
If you want to avoid this, there isn't much sense to use WTP and you can just stick to Jetty runner.
Related
I am having issue with the way tomcat deploys my files to the server.
I have installed Tomcat 7 to /opt/tomcat7.
In my eclipse i have specified this path as my tomcat server.
my workspace directory is /home/maciej/workspace/<projects here>
now if I edit a class file and i add simply log statement
log.info("blabla"); and then deploy 'NEW' version of the file via - run on server, i do not see this 'blabla' in my output. It seems like although i have modified the class file, it was not properly deployed into tomcat. Tomcat is reading god knows what but certainly not the file it should read.
EDIT: I have recofnigured my tomcat in eclipse and now:
Server Path = /opt/tomcat7
Deploy Path = /opt/tomcat7/webapps <- used to be .metadata/blablabla default
eclipse tomcat location
When I open 'Open Lunch Configuration' under arguments/working directory the default option is ticket with greyed out path /home/maciej/Desktop
Should this also be changed?
Isn't tomcat working directory /opt/tomcat7/work ?
Any suggestions / ideas? As this issue is slightly getting on my nerves as i can not develop the app.
The Server Path is the same as the Tomcat installation directory in the modal you see in Window > Preferences > Server > Runtime Environments after hitting Edit. That should be set to /opt/tomcat7 or wherever the root of your Tomcat installation lives.
The Deploy Path is relative to the Server Path. It should be webapps, unless you already have stuff there and you want a separate directory. You will not be able to edit this until you shut down Tomcat and remove all webapps underneath it through the Servers view.
Try unchecking Modules auto reload by default if you trust the JDK hot-swapping, which you should if you're using JDK 1.7 or 1.8 and just want to see a log statement inserted.
The working directory you mentioned is just the root directory that Tomcat uses to spit out thread dumps on crashes and the like. It has nothing to do with the Tomcat "work" directory.
Open server view: Window->Show view->Other->Servers. The select correct server, right click, select "Clean" and then restart tomcat. It should help.
If you change something in the project then Eclipse will build automatically and "deploy" the files to the location you have specified. By default, Eclipe's work stops there and the rest is up to tomcat.
Tomcat, like any Java web server, detects changes in JSPs and recompiles them. Nevertheless, changes in classes have no effect because of the way Java class loading works. For the new version of a class to be used by tomcat you need to:
Not have loaded the class before. For example, you start tomcat but then see an error before doing any request. If you change the class then that change will be used because the class was not yet loaded.
Reload the application. This means that all classes are discarded and everything starts fresh.
The easiest way to reload an application, by default, is to make a change to web.xml. If you look into tomcat's configuration conf/context.xml you can see that WEB-INF/web.xml is monitored. Any change will trigger a reload of the context. So you can either make an artificial change in the file or add a resource like WEB-INF/version.properties and generate a different version.properties with any build.
In any case, reloading a complex application takes time. That is why there are plugins like JRebel. But before you go down that path (which adds another moving piece to your setup) you can also try to use Eclipe's support for hot code replacement. You start tomcat in debug, connect to it with Eclipse, and then change some class. Eclipse will try to recompile the class and upload the new definition to tomcat. If it fails it will tell you. As a general rule it will fail when you change the structure of the program and succeed when you just change method's implementations.
I'm working with multiple Liferay Projects (different Portal, plugins, user and usergroups etc ) in the same time, and often have to switch between them. This switch requires lots of steps like
Editing the portal-ext.properties (to change the Liferay Database, and edit some custom project-specific properties), and edit 'portal-setup-wizard.properties'
Add/remove portlets themes and hooks from the Eclipse Server instance, sometimes clean the Tomcat's 'data' 'Webapps' and 'work' folder
Go to Liferay's Control-Panel/Server/Plugins Installation and re-index portlets like 'Users and Organizations' or 'Documents and Media'
So, I thought that creating a new Server Instance for each project, with a new tomcat and JRE, would be a nice idea. When I had to switch project, I could just stop the old server and start another. At first, I thought (was adviced actually) that using the same Liferay Plugins SDK (6.1.0), should be ok, as long as the Server instances are the same version.
Practically this doesn't work 100% perfectly. While most of the work is getting done, there are some problems here and there, like a theme not getting deployed propertly, hooks not beeing applied etc. As I understand, there is some [Liferay SDK] - [Liferay Server] binding, and that means that only 1 Server (the first one I created) will fully work.
For example, By investigating the [Liferay SDK folder]/bild.[user name].properties, I can see some properties that are referring to a specific Server/JRE location :
app.server.portal.dir
app.server.lib.global.dir
app.server.deploy.dir
app.server.type
app.server.dir
So, my question is, what should I do to work with multiple Liferay Projects ?
Is the multi-Server practice, a good approach to work with multiple-projects ?
If yes, should I create a different SDK for each Server? Maybe a different Eclipse workspace too ? Or is there some way to use the same SDK
What about working with Servers of different Liferay Version ?
Personally, I set up every project with its own source, tomcat, database, etc. even if it means duplication. These days storage is cheap and makes this possible. Of course your milage may very but I thought I'd share my setup with you.
I have a project directory with all my projects which looks like so:
/projects
/foo-project
/bar-project
/my-project
Inside a project I have
/my-project
/tomcat
/bin
/conf
...
/src
/portal
... my portal source ...
/plugins
... my plugin source ...
/portal-ext.properties
I then setup tomcat to use different ports (8080, 8081, 8082, etc...) so that I can just leave them all running if I have to or want to.
I setup Liferay to use different database for each Liferay instance.
I place the portal-ext.properties as a sibling to the tomcat directory and Liferay will read this file (assuming the default behavior). This offers quick and easy edits as well as figuring out how you've set each project up.
The advantages should be clear. You can just "walk away" from a project and into another without tearing down and setting up. And when you return everything will still be as you left it. Context switching is also quicker and helpful if you want to answer a question about a project you're not yet working on.
Depending on the complexity of each of your projects, multi-instance might not work for you. Hooks and EXTs may conflict with each other and it appears as if this is already the case with your projects.
If you can afford the space (which is not much) this has been the fastest way I have found as a Liferay developer.
If we start working on a new Liferay project in our company, we setup:
a new database schema,
a new, clean Liferay server connected with that schema and
a fresh Eclipse workspace, with
a clean SDK project
Only this way you're sure to have cleanly separate projects. To switch to another project, just shutdown the current Liferay server, startup the new one and switch to the right workspace in Eclipse. This all takes no more than 2 minutes, a lot less than to do all the cleanup actions you have to do if you share workspace and server.
In my opinion, this is the approach of most development teams.
Why mess with all these complications in a single computer? I use Oracle VirtualBox and set up a separate VM for each project. Even though I work on a laptop, it has 8 cores, and I've bumped my memory up to 16GB and set each machine up with 4GB of RAM.
I can have multiple VMs running at once and have set all active projects as home pages in Chrome. Using bridged networking each VM has its own IP address, and they all listen on 8080.
Another benefit is that, although my primary project is being developed using Eclipse Indigo and LR 6.1 CE GA1, I have another using Eclipse Juno, its specific IDE plugin and LR 6.1.1 CE GA2. So it also works as a new version tester.
VirtualBox is free. Memory is cheap. And remember that you can put a VM to sleep without shutting it down. That takes about 10-20 seconds and waking it up again takes 30-60 seconds.
The simplest solution would be :
Create 3 different users, the Liferay SDK's bundle.properties file is separate for each user. So, lets say, if you want to run 3 servers with the same sdk. Create 3 files like
bundle.user1.properties
bundle.user2.properties
bundle.user3.properties
Now, when you want to deploy something for server 1, log in the server using user1 and try to deploy the portlet, this will read bundle.user1.properties and it will deploy the portlet/hook to the specified location.
Hope this will resolve your deployment issue.
Also, when you have 3 users, you can run 3 different servers together in a different user accounts, in this way, they would be secure and apart from admin, nobody can shutdown the same.
Hope this helps!
I have a web application project in VS2012 which I'm publishing using a "Web Deploy Package". I want this package to include app-pool settings, specifically creating an IIS app-pool and assigning the newly created application to it.
I'm familiar with the option "Include application pool settings used by this Web project" available when the project is configured to use an IIS instance (not IIS Express), but IIS configuration is not part of the project file, and thus not source controlled. What happens when somebody builds a deployment package on a machine that hasn't had IIS meticulously configured? Not ideal.
How else then, can I go about getting AppPool settings into my web deploy package? I understand that the appPoolConfig provider is IIS7+ only, I'm fine with that limitation. I've banged my head against this issue in the past and never found a solution. 18 months later, we've got a new VisualStudio version, and a new web-publishing-pipeline, are there new options to address this? Or maybe something I missed when I first tackled this problem?
Edit
OK, I'm seeing the following as options:
Configure my project to sync settings from an IIS instance. As mentioned, I'm not a fan of this given that it puts settings outside of the project, meaning the environment has to be meticulously configured to build + publish. Plus it drags along other IIS settings I don't want included.
Inject something into the web-publishing-pipeline (WPP) to modify the archive.xml. I've toyed with this in the past and had limited success. One problem is the pipeline isn't exactly co-operative with working directly on the archive.xml file, another problem is some of the more cryptic attributes involved, like MSDeploy.MSDeployProviderOptions which appears to have some Base64 encoded binary? No idea what to put in there.
Find an existing "provider" that can do what I want. I might be out of luck here, the appPoolConfig provider only seems to want to read / write IIS, not, say, an XML file of settings. Does anybody know otherwise?
Write my own "provider" to produce manifest output entries. I'm not sure, is it possible to write a custom provider that writes to a manifest using the name of an existing provider? As in, MyCustomPoolProvider writes appPoolConfig sections into a manifest? This sounds like a potentially painful exercise that may or may not work. Would I still need to figure out the encoding of whatever is going into MSDeploy.MSDeployProviderOptions?
I get the feeling that the fundamental obstacle with Web Deploy for what I'm trying to accomplish, is how strictly it leans on "providers". The pre-existing providers are largely designed for IIS synchronisation, not primary development and publication. It so happens that some of these providers can be relatively easily hooked into via MSBuild, but the majority insist on pulling data from IIS, and that's that.
You are correct in your understanding of the appPoolConfig provider, in that it can only sync between App Pools and can't be provided with the configuration directly. What you could potentially do is keep a copy of the appPool in question in package form (ie. msdeploy -verb:sync -source:appPoolConfig=PoolName -dest:package=apppool.zip) and attempt to hijack the pipeline so that the MSDeploy call adds the application content into the package, leaving the existing content there.
Alternatively, you could always keep the packages separate and deploy them with different calls to MSDeploy.
FYI, MSDeploy.MSDeployProviderOptions is simply an encoded version of the parameters supplied to the provider when it was packaged. For example, -source:dirPath=c:\,ignoreErrors=0x10293847 -dest:package=package.zip would package the ignoreErrors value.
I have this strange problem at which I have spent stupid amount of time.
To build my portlet, I haven't used sdk and I am using my own ant script do the job. It works all well till this wierd situation.
I am basically using a lot class from portal-service.jar to change role settings etc. When I include it in my build path and deploy it again. It doesn't get deployed. On shell it shows the deployment, below is the log:
Copying 1 file to C:\liferay-portal\tomcat-6.0.29\webapps\ch1_HelloWorld
Deleting directory C:\liferay-portal\tomcat-6.0.29\temp\20121016060846753
06:08:47,887 INFO [PortletAutoDeployListener:81] Portlets for C:\liferay-portal\tomcat-6.0.29\deploy\ch1_HelloWorld.war copied successfully.
Deployment will start in a few seconds.
16 Oct, 2012 6:08:56 AM org.apache.catalina.startup.HostConfig checkResources
INFO: Reloading context [/ch1_HelloWorld]
That's it! Later it doesnt show (as it does normally) that the portlet is available to use. In browser, under the "add tab", the option is never shown. What can be the issue for this. The portlet is a simple hello world portlet that access role information
I am basically using a lot class from portal-service.jar to change role settings etc. When I include it in my build path and deploy it again. It doesn't get deployed. On shell it shows the deployment, below is the log:
Did you put portal-service.jar to WEB-INF/lib? If so remove it from there and add it to some other (my_project/lib) directory than add it to build path.
Also make sure that after deployment portal-service.jar is not in your deployed WEB-INF/lib.
Better yet, first undeploy than redeploy.
Is this properly set in your liferay-display.xml ?
<display>
<category name="yourCategoryUnderAddMenu">
<portlet id="yourPortletId"></portlet>
</category>
</display>
Late answer, but maybe it will help someone:
- just shutdown your server;
- delete the portlet from the "webapps" tomcat folder;
- you should delete "temp" and "work" folders content;
- restart your server and deploy your portlet.
Everything should be OK.
I do not know why this happens, but I encounter this problem many times and fix it with the same solution.
Bye!
This is normally the case when the auto.deploy.dest.dir is pointing to the wrong place. Firstly, i came to realise the common mistake is to make this point to liferay_home/deploy which is not correct. This property specifies the destination of exploded files. For tomcat, it would be the webapps directory e.g. /opt/liferay-portal-6.2-ce-ga2/tomcat-7.0.42/webapps
In other words, tomcat, on receiving the exploded files,carries on. In your case, tomcat was never realising any changes.
Delete the old war from the webapps, and put your new war manually in the Deploy folder.
It looks like you might be deploying by copying it to the webapps folder, instead of the deploy?
go to plugins-sdk folder.
open build.userName.properties (In my case name of file is build.asif.properties)
open it..
add the below line
auto.deploy.dir = D:\\nWorkSpace\\liferay-portal-6.2.0-ce-ga1\\deploy
"D:\nWorkSpace\liferay-portal-6.2.0-ce-ga1\deploy" is the path of my deploy direcotory.
where nWorkSpace is my workspace. My problem is resolve.
I tried all of the above solutions but my issue was not resolved on a Liferay 6.2 EE sp2 bundle.
I was finally able to resolve portlet deployment issue by cleaning all the portlet xml files except the ROOT.xml from the Tomcat home/conf/Catalina/localhost folder.
This tip above was provided on the following post - how ever the blog post no longer exits and had to find in the archives below with google search in case someone is interested. It saved me hours of effort.
https://www.liferay.com/community/forums/-/message_boards/message/2124111
http://archive-ro.com/page/754918/2012-11-26/http://blog.ropardo.ro/2010/08/09/liferay-deployment-will-start-in-a-few-seconds-and-how-to-realy-start/
I am seeking advice: Ideally, I would like to give an Administrator (of the web server) one file (.exe, .msi, .bat, whatever you suggest), so that when they execute the package, it will setup my application (contains .aspx, .xap silverlight, web service .svc, etc.) on IIS. This will include and certainly not be limited to such things in the IIS Manager, like creating a virtual directory, path, default document, security, and all of the IIS settings one finds via inetmgr and properties. I would also maybe like to run a .bat file (not sure if this correct), but to check for certain settings and pinging other servers for status.
Many years ago, I used to automate everything and used concepts like .bat files - got the job done and it was amazing what I could do. Fast forward a couple of years now and am approaching the automation process again. I wanted to know if there is anything new out there.
Any and all advice will be greatly appreciated!
It's quite a bit of a learning curve but yes, WiX / InstallShield / MSI can do this. I've done installers for n-Tier / SOA systems including single tenant SaaS where you could run the application layer installer dozens of times creating new instances running on different host headers or ports pointed to different data layers and different configuration settings. You could then do the same for the WebUI pointing to which ever application layer you want.
Basically whether it's instaling .NET, setting up vDir / AppPools / WebSites / Extensions, reading and writing XML config files, executing SQL scripts, creating services and so on it can all be done... if you take the time to learn it all. Deployment Engineering is a bigger domain then it first appears to be.
As for .BAT, that's bad form. First you work to leverage native capabilities before writing custom actions. Then when you do have to write one, you design it to be declarative and transactional ( install, uninstall, rollback, commit ). WiX has a really nice framework called DTF that allows you to encapsulate C# classes as if they were C++ from MSI's perspective and provides a nice interop library needed to talk to MSI during the install.
Visual Studio has a Web Setup Package project you can use for this.