Setup Jetty default webapp folder - scala

Apologies for the newbie question, I am trying to start using Jetty servlet container for a Scala/Ajax application.
I want to change the default webapp directory to a custom one, say /home/myuser/project/ and let jetty serve the index of that page.
a doctype, head and body is literally all I need as all the layout will be controlled via Ajax/REST/Scala with DOM generated entirely in JavaScript.
How can I get jetty to serve a custom index.html file from a specified folder?
I am using Jetty 9 Debian Distribution on a 64 bit Ubuntu 12.10, if that makes a difference in any way.

I believe you should be able to add a file called root.xml to your $JETTY_HOME/contexts directory with the content:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://\
jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="contextPath">/</Set>
<Set name="resourceBase">
/home/myuser/project/
</Set>
</Configure>
You may also need to remove any existing wars in $JETTY_HOME/webapps that respond to the same context.

Related

WSDL service location base URL will be different in each environment and how to not build the same jar over and over again

I have a wsdl file, which contains service-tag and partial view of it:
<service name="EXFlowers">
<port binding="getflowers:EXFlowersGetflowers" name="EXFlowersGetflowersService">
<soap:address location="http://dev.example.com:67857/EXFlowers/getflowers" />
</port>
</service>
My problem is in this part:
<soap:address location="http://dev.example.com:67857/EXFlowers/getflowers" />
I am using wsdl2java which creates .java files from the wsdl file (then I compile the generated files and make a jar file out of it for using it in WebSpehere).
As it is now I can't promote a .jar file from one environment to another (for example: development -> test -> staging -> production), because the location in each environment has different base url. I hate to run wsdl2java for each environment (basically create the same jar 5 times with just different string values in some of the class files). I want "build once, run anywhere" workflow and I found this from IBM's support page https://www.ibm.com/support/pages/accommodating-different-wsdl-urls-between-environments which explains how it could be done.
So my question is:
Can a kindly soul explain me with syntax examples how option 2 can be done:
Use a file:// based WSDL URL. Store the WSDL file itself in the same file path in each environment, but use different contents with
custom hostnames and/or endpoint URLs therein.
I don't understand it, how will it look like:
<soap:address location="file://tmp/myendpointfile.txt and what about this part -> /EXFlowers/getflowers" />
and how will the content of the file be ?
cat /tmp/myendpointfile.txt
http://dev.example.com:67857
I would appreciate any help or if you guys know a better way of accomplishing this task.

Make a sub directory public on .Net core webAPI

I have a Restful API project with .Net Core 1 that has a directory that contains some public files (ex: images). I created a controller that retrieved files by file name, but I think it uses CPU and it had has much delay.
for example:
wwwroot
- refs
- runtimes
+ public
- logo.png
+ subdir
- icon1.png
- icon2.png
I want to access this directory publicly from a url like this
https://MyAPIDomain.com/public/logo.png
https://MyAPIDomain.com/public/subdir/icon1.png
I want to IIS directly handles these files and no need to process with dot net. Also they should be resumable on download and browsers could be able to cache theme. How can I do that?
web.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!--
Configure your application settings in appsettings.json. Learn more at http://go.microsoft.com/fwlink/?LinkId=786380
-->
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
</system.webServer>
</configuration>
ASP.NET Core uses IIS as a reverse-proxy. What this means is that all requests are forwarded to your ASP.NET Core app. Period. There's no way around that. The only way you can get IIS to directly serve a file is to host it in a virtual directory in your IIS site. Then, because that particular path is now handled by IIS, it will not forward to your ASP.NET Core app. However, that means then that your ASP.NET Core app can no longer work with that path. In other words, you can't create a virtual directory like "public" and also serve files separately under wwwroot/public.
That said, the static files middleware runs relatively early in the pipeline and is also pretty lightweight. I honestly doubt you'd see much, if any, performance decline over directly hosting static files in IIS. It's also much easier with the static files middleware to handle things like setting cache headers. I'd suggest you simply leave things as they are.

AEM (CQ5.6.1) local maven deployment only works sometimes

I've gotten some weird effects lately, where sometimes when I deploy my CQ application via Maven to my local AEM Server, it would't update correctly.
E.g. when changing something in a dialog of a component, I have to delete the /app/myapp folder in CRX and deploy again to get changes to appear.
I'm also having a hard time reproducing the effect. It happens seemingly in random intervals.
Please check your filter.xml file. This descriptor should contain all the root paths for your application so most probably: /app/myapp, /etc/designs/myapp and maybe couple others.
For more information please check vault documentation (section using filters). This file is used by CQ package manager to install the content.
In previous CQ versions there was a behaviour that filters were almost ignored. Starting from CQ 5.6 if any content path does not match filter.xml regexps it won't be installed. This does not match exactly your issue but kindly check if updating filter.xml file helps.
Here is what I use for our project and has worked flawlessly on AEM6 but should also work perfectly on CQ 5.6. Replace "ourProject" with whatever is appropriate and let me know if you still have issues.
<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
<filter root="/apps/ourProject">
<exclude pattern=".*install" />
</filter>
<filter root="/etc/ourProject"/>
<filter root="/etc/designs/ourProject" />
<filter root="/etc/widgets" />
<filter root="/etc/workflows" mode="update"/>
</workspaceFilter>

Flash swf file accessing error in maven-scala-thymeleaf web project

im creating a scala -maven web project for kindergarten kids..
But the problem is when i accessing a image from resource-image folder i does not show image
But when i read page with browser it will show the image ..
So is there any solution for showing image while running from jboss
In your spring configuration context for the application (in my case its usually a app-context.xml), have you defined the resource mapping? For example, to serve all static content from a root "static" folder:
<!-- Handles HTTP GET requests by efficiently serving up static resources in the ${webappRoot}/static directory -->
<resources mapping="/static/**" location="/static/"/>
If you are also using spring security (security-context.xml), you'll want to make sure you have excluded "static" similar to:
<security:http pattern="/static/**" security="none"/>
This should allow you to resolve an image in the application like so:
http://www.somedomain.com/myApp/static/img/uglymug.jpg
http://www.somedomain.com/myApp/static/style/uglymug.css
http://www.somedomain.com/myApp/static/script/uglymug.js

MsDeploy Virtual Directory gets converted to Virtual Application on deploy

For my CMS to work properly it needs to be deployed to a virtual directory underneath the www root so it can access (via reflection) the website to manage (note: CMS = N2CMS). When using Visual Studio 'Publish To Web' all is fine. But when I generate the package via msbuild commandline and publish that version my virtual directory is converted to a virtual application.
I configured my remote server to have a virtual directory '/n2' underneath my IIS web application ('exampleapp') and configured this path in the Package/Publish Web settings (IIS Website/Application name to use on the destination server) within my project in Visual Studio.
To generate the deploy package:
msbuild.exe myproject.csproj /T:Package
This generates the zipped package of my code together with MsDeploy commandline batch files to execute (standard msbuild/msdeploy target).
The generated SetParameters.xml contains the following:
<?xml version="1.0" encoding="utf-8"?>
<parameters>
<setParameter name="IIS Web Application Name" value="exampleapp/n2" />
</parameters>
The generated SourceManifest.xml contains the following
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<IisApp path="C:\...shortened-path...\PackageTmp" managedRuntimeVersion="v4.0" />
<setAcl path="C:\...shortened-path...\PackageTmp" setAclResourceType="Directory" />
<setAcl path="C:\...shortened-path...\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>
Anybody got a clue why the virtual directory gets converted to virtual application?
In the Microsoft.Web.Publishing.targets file, DeployAsIisApp defaults to true:
<DeployAsIisApp Condition="'$(DeployAsIisApp)'==''">true</DeployAsIisApp>
You should be able to override it to false by adding it to the appropriate PropertyGroup element in the project file or in a .wpp.targets file in the project folder; on editing the project file, see
http://msdn.microsoft.com/en-us/library/ff398069.aspx
I've got success with the following combination of deployment parameters (in csproj) when publish web application project (WAP) to the virtual directory without marking it as IIS application:
<DeployOnBuild>True</DeployOnBuild>
<DeployAsIisApp>False</DeployAsIisApp>
<DeployIisAppPhysicalPath>MyWebSite/MyVirtualDirectory</DeployIisAppPhysicalPath>