Can't set up ISAPI filter for tomcat on IIS - isapi-redirect

Windows XP SP3: try to set ISAPI filter isapi_redirect.dll in following way:
1. Create folder jakarta to point to the folder with the file isapi_redirect.dll. Set right permission on this folder.
2. Create virtual directo to point above folder
3. Set filter at localhost Level.
When it's done, restart IIS. And check the filter. it said not loaded with red arrow.
Same files were set on another XP computer and works fine.
How to resolve this problem?

You may want to follow the directions here, but it sounds like you may have an incorrect property file, perhaps, or you may have downloaded an intel-based dll and used it on an amd machine.
Here are some directions to follow
http://tomcat.apache.org/connectors-doc-archive/jk2/jk/iishowto.html
It would help if you look in the event log, on XP, and see what error may be present.

Related

Maven reads user configuration from wrong location

I just discovered why Maven doesn't work properly on my machine. For some reason it reads the user configuration from the completely wrong location. And I don't understand why. When I run maven with the -X switch I get the following output in the beginning:
[DEBUG] Reading global settings from D:\dev\maven\active\conf\settings.xml
[DEBUG] Reading user settings from D:\.m2\settings.xml
[DEBUG] Using local repository at D:\dev\maven_repo
Why is it reading user settings from D:\.m2 and not my actual user directory like it normally should? It worked fine on my old computer. Does it have something to do with me having installed maven on a different drive this time? On my old computer it was installed on the C drive.
Where does it get this D:\.m2 from? How can I make it read the user settings file from the actual default location, %userprofile%\.m2?
Finally figured it out. Found the solution in this blog post. To find the home directory in Java you do this:
System.getProperty("user.home");
Problem is, for some dumb reason, Java isn't using Windows environment variables or anything like that to find this path. It actually uses the parent directory of the Desktop directory. Since I like to keep certain main folders in my user directory on a separate drive (documents, downloads, music, desktop, etc) I had moved the desktop directory to D:\Desktop. Java then takes that directory, goes one level up and makes Maven and other java applications think D:\ is my home directory.
Gotta say the more I use Java the more i hate it... anyways, hopefully this might help save some hours of head scratching for someone else too.
Update
The original blog post is gone, but found on the WaybackMachine (the URL has been updated), but here's the gist from that post in case that goes too...
The issue: So how does Java play into all of this? Well, Java
developers sometimes want to store settings for their applications in
a folder within the user’s profile directory. It’s the Linux way, and
Java tends to do things the Linux way. (As mentioned earlier, Windows’
“AppData” folder servers the same purpose, with some extra separation
for data dependent on whether or not it should roam with the user’s
profile.) For some reason, Java does not use the Windows environment
variable to determine the location of the user’s profile, but instead
access a registry key that references the user’s desktop folder. It
then takes the parent directory of the desktop and assumes that is the
user’s profile folder (assuming the user makes use of the default
setup Windows chooses).
Essentially, when a programmer calls the Java command:
System.getProperty("user.home");
Java uses the following idea to determine where my user profile folder
is:
PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"
This breaks down when the desktop folder has been modified.
So, with my setup, instead of saving settings at:
c:\users\tim\
Java apps tend to save data to:
t:\tim\
In reality, Java apps should save settings to:
c:\users\tim\AppData\Roaming\
or something like that.
To add insult to injury, the Java apps continue to follow the Linux
way and use a period at the beginning of the folder name in an attempt
to “hide” the folder (as is done on Linux). For Windows users, this
simply ensures these folders are listed first in directory listings.
(Hiding a folder on Windows is achieved through setting the hidden
attribute for the file.)
It looks like NetBeans has addressed the issue for their application,
but the root issue remains an unresolved, low priority bug. Somehow
I’d bet it would get fixed a lot faster if the mechanism for
determining the user’s home path on Linux was wrong.

classic asp on iis 7 - getting things to work without adding a foldername/ to all includes and paths in an application

I recently got this huge application written in classic asp that came to me in a zip file called ivx. I'm on IIS 7 running on Windows 7 64 home premium on my laptop.
What I've now done is unzipped ivx to inetpub/wwwroot. So it's now c:/inetpub/wwwroot/ivx/
The problem is, the entire application contains includes and other things pointing to the root (my guess is this was pulled down directly from the server).
<!--#include virtual = "/main/indexfunctions.asp" -->
<!--#include virtual = "/common/adminverify.asp" -->
To get things working, I'll have to add /ivx to each and every path in the application. I know I can get thing going if I unzip all files to the root directory, but I cannot do that since there are other files there.
How can I make this whole thing work without having to add the current folder name to all the paths in the application? Is there a setting somewhere in IIS or elsewhere that'll let me do this?
If I'm not horribly misunderstanding, aren't the folders just pointing to the site root? It's a relative path, so <!--#include virtual = "/main/indexfunctions.asp" --> will look for indexfunctions.asp in the ivx/main folder. Am I totally mistaken? I don't really get the question.
What you want here is a virtual website, where you access the website either via a custom hostname (like ivx.yourmachine.local -- add that to your hosts file) or via a port number (like localhost:8080). read Understanding Sites, Applications, and Virtual Directories on IIS 7 and then look at How to: Create and Configure Virtual Directories in IIS 7.0

Windows Azure - The current service model is out of sync

When I run a Windows Azure web role on my local developer fabric, I get the following error:
The current service model is out of sync. Make sure both the service configuration and definition files are valid.
One of my colleagues hit this issue and after a bit of playing about, the problem was that the two service configuration files (cloud and local) had a different number of Settings.
When he updated the configuration files so that they were in sync it all worked.
A tip would be to use the GUI in Visual Studio to add new settings to both at the same time. The GUI can be accessed by right clicking the web role and selection properties. This should open up a window. Click the Settings tab on the left.
For me, this was caused by my azure project having been copied from one PC to another (going from Win 7 to Win 8.1 in the process). I am using VS 2013 Community edition on both, but I had upgraded from Azure 2.4 on Win7 to Azure 2.5 on the Win 8.1 machine.
If you unload the azure project and edit the csproj file, you just need to make a small edit (e.g. adding a comment) and save it, so it re-writes itself. This fixed it in my case (where I'd spent ages checking for errors in the CSDEF and CSCFG files). Once I re-saved the csproj file, it worked fine.
This happened to me because one of my cloud configuration files (.cscfg) was missing some key-value pairs that were defined in ServiceDefinition.csdef.
Going over the files manually was a pain. There's an easy way to discover the descrepancies:
In the Solution Explorer, right-click one of the Roles that make up
your Cloud Service and click 'Properties' in the context menu.
The Role properties window will open up grey with an error message saying:
"Invalid Service Definition or service configuration. Please see the
Error List for more details".
Open the Error List window and in some cases you
should be able to see a list of the specific discrepancies, complete with file
and property names.
I followed all the answers here and it still didn't work
eventually I restarted Visual Studio and it worked.
I believe the solution was the combination of one or more of the answers here + restarting VS.
What worked for me was to:
Make sure the Cloud Services .cscfg and .Local.cscfg files were identical (unless you need your Local.cscfg to have some differences for debugging purposes),
Make sure the .csdef file had definitions that matched the .cscfg files, and then
Close the project and delete its Cloud Services .ccproj.user file.
After reloading the project, all was well.
The error can occour when there is no actual fault in the service configurations.
If it occours and everything seems to be correct, instead of restarting visual studio, simply unload the azurecloud project (rightclick: unload proecjt
Please cross check your ServiceConfiguration.Cloud.cscfg and ServiceConfiguration.Local.cscfg files. My problem was, I added a configuration to Local.cscfg but forgot to add the same to Cloud.cscfg
Had this issue - no errors though. I have found that for some bizarre reason the if the setting:
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
was commented out, then the workerrole would not launch.
For me, the issue turned out to be an inconsistency between the vmName value I had assigned to one of my roles in my various environments. I have a *.cscfg files for my development, test, and production environments. Each of these had a role definition that was supposed to be along the lines of
<Role name="HardWorker" vmName="SomeName">...</Role>
but one had an entry like
<Role name="HardWorker" vmName="SomeOtherName">...</Role>
and that, apparently, was enough to trigger the error.
My problem was incorrect certificate definition in csdef file.
For me the problem was that the Wifi I was using blocked the PORT Azure is using, changing Wifi solved that problem.

Path too long error when building a windows azure service

I have been trying to publish my service to windows azure. The service consists of a single webRole, however I have added remote login functionality published it and built it a few times, and now all the sudden it will not build. The reason it gives is that
Details below:
"Error 56 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets 202 5 FileSystemCreator"
I have gone on all the forums, I have used CSPack command line for packaging the service which is fine but I'm having a really hard time configuring the certificate for remote desktop connect and I would like to take advantage of this feature as I am creating some websites in the onStart event and I would like to peek into IIS. Some microsoft employees do agree that this is a bug and the have promised a fix this issue, refer to post . I am using VS2010 and I do not know how to fix this bug.
Can anyone please help, or point me to a place where I can get any help.
I ran into the same problem with a new solution.
Note that, unlike Eugenio Pace's response suggests, the error occurs only when deploying to Azure (and not when running the project in the Azure Compute Emulator).
Try adding the following line to the first property group of your Windows Azure Visual Studio Project file (*.ccproj):
<ServiceOutputDirectory>C:\Azure\</ServiceOutputDirectory>
The trailing slash (for whatever path you select) appears to be required. This folder will be deleted each time you create a package if it exists.
This setting seems to redirect the working folder for the package to a shorter base path, preventing the path too long error.
Credit goes to: http://govada.blogspot.com/2011/12/windows-azure-package-build-error.html
Perhaps the local folder used to store temporary development fabric is too long. See Windows Azure - Resolving "The Path is too long after being fully qualified" Error Message.
I was having this problem as well when deploying a Node.js project to Azure.
To fix it, I had to change my "TEMP" and "TMP" user environment variables to something shorter than their default values.
In my case, they were pointing by default to %USERPROFILE%\AppData\Local\Temp, changing them to C:\Temp solved it.
Make sure you restart Windows after.
The better solution may be to create a symbolic link to your project folder. This doesn't require moving files or changing system variables. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
Same problem happened to me when I try Packaging an Umbraco project for Azure (https://github.com/WindowsAzure-Accelerators/wa-accelerator-umbraco/wiki/Deployment), I found the solution is to: Copy and rename the long-name path and folder to "C:\someshortname".
(solution was suggested by this: link)
I tried all the above 2 approaches:
-change TEMP and TMP enviromental variables
-<ServiceOutputDirectory> path
and didn't work.
In my case, I had to move the whole project to a shorter path C:\ and worked.
I'm using W7 and VS12.
When you run a cloud service on the development fabric, the development fabric uses a temporary folder to store a number of files including local storage locations, cached binaries, configuration, diagnostics information and cached compiled web site content.
By default this location is: C:\Users\\AppData\Local\dftmp
Credit goes to Jim Nakashima of Microsoft :
https://blogs.msdn.microsoft.com/jnak/2010/01/14/windows-azure-resolving-the-path-is-too-long-after-being-fully-qualified-error-message/
In order to change the temporary folder, a user environment variable has to be created :
It is named _CSRUN_STATE_DIRECTORY
Give it a value of short named directory like :
c:\AzureTemp
Don't forget to restart Visual Studio in order to have the environmennt variables to be read again
It fixed many compilations problem !

Eloquera with ASP.NET MVC. Error

I am curious about using an object db so thought i'd give Eloquera a go.
I am having problems getting it running unfortunately. (running in "desktop mode")
I have done these steps as directed:
1) Copy the following assemblies and a configuration file from the %ProgramFiles%\Eloquera folder into a project folder:
Eloquera.config
Eloquera.Client.dll
Eloquera.Common.dll
Eloquera.Server.exe
You can copy the reference files into a separate folder for your convenience.
2) Uninstall the Eloquera DB (sounds awful, but we have copies all files we will need) - (I never installed it)
3) Add Eloquera.config into your project via “Add an existing item…”, and set its "Copy to Output Directory" property to "Copy Always". Done
4) Add the project references to these files:
Eloquera.Client.dll yep
Eloquera.Server.exe yep
5) Rebuild your project and check that Debug\ and/or Release\ folders contain the following files along with your application:
Eloquera.config
Eloquera.Client.dll
Eloquera.Common.dll
Eloquera.Server.exe
It does
6) You may change a physical path to the database files in the Eloquera.config file by setting DatabasePath value:
DatabasePath="c:\dev\db" I did this also
The error i get is this:
The connection to the server (local) on the port 43962 cannot be established.
The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
Weirdly, changing ServerPort to something else in the config does not change this error.
Any ideas?
I think this mode is not supported.
You are meant to use Client / Server mode, which is a shame cause i was hoping i could use this desktop method to deploy into a shared host.
No dice.
You can download from Eloquera website desktop project that is already configured and working and can be used as a base.
Kohan,
Desktop mode is supported in Eloquera, otherwise my application would not work. :-) There is a good start-up project for the desktop application on the Eloquera web site, have a look at that.
I get this issue with VS2010 and 64 bit Windows 7 - if you are using the 32 bit dlls (as we are as our app needs to work on 32/64) then make sure your target build (in VS) is set to 32 bit rather than AnyCPU.
I still cannot get the Database browser working but the code is working now.
Also - obvious things like make sure your firewall is turned off etc. make sure you can telnet onto the port

Resources