I’ve just installed ColdFusion2016, using its built-in websever. I have a project, foo, I’ve imported to wwwroot. It has the structure /wwwroot/foo/src/index.cfm. I want to be able to browse to http://localhost/foo/. I have added in the sever.xml an alias:
<Context path="/" docBase="<cf_home>\wwwroot" WorkDir="<cf_home>\runtime\conf\Catalina\localhost\tmp" aliases="/foo=<cf_home>\wwwroot\foo\src"></Context>
When I goto http://localhost/foo/ I get a directory listing for foo. I can see the page from http://localhost/foo/src. How do I configure the server for http://localhost/foo/ to point to src?
ColdFusion 2016 uses Tomcat 8 which deprecated and removed the method of using the aliases attribute. You now want to use <Resources> and <PreResources> to do the equivalent.
Below is the conversion of your example code:
<Context path="/" docBase="cf_home\wwwroot" workDir="cf_home\runtime\conf\Catalina\localhost\tmp">
<Resources>
<PreResources className="org.apache.catalina.webresources.DirResourceSet" base="cf_home\wwwroot\foo\src" webAppMount="/foo" />
</Resources>
</Context>
On a similar note: I wrote a blog article about a semi-related scenario, that uses the same feature for "aliasing", when CF2016 was released - Changing the Location of the ColdFusion 2016 Webroot
Related
How do you remove the ability to find content under language identifiers in Sitecore?
Content here:
/about
Is also available at:
/en/about
Weirder yet, any attempt to find content under a different language identifier results in an error about not being able to find Views.
/es/about
/pt-br/about
/aa/about (this is invented..)
I don't want content available under any language identifier -- the URLs above should simply be 404s.
I can't find where this language identifier is isolated and processed. I removed the LanguageResolver from the httpRequestBegin pipeline, but this didn't change the behavior.
There are many blog posts about turning off language embedding in the LinkManager, which I've done, but that's not enough -- I do not want content being produced under any language code. The firs segment of the URL should be treated like any other segment. Requests for /en/[whatever] should 404.
As well as setting the LinkManager to never embed, you also need to set the Languages.AlwaysStripLanguage setting to false.
Source: http://www.sitecore.net/learn/blogs/technical-blogs/john-west-sitecore-blog/posts/2015/03/prevent-the-sitecore-aspnet-cms-from-interpreting-url-path-prefixes-as-language-names.aspx
Assuming you already have a custom 404 resolver in place, you just need to change the Sitecore setting Languages.AlwaysStripLanguage from true to false like so:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<settings>
<setting name="Languages.AlwaysStripLanguage" value="false" />
</settings>
</sitecore>
</configuration>
when we implement SitecoreApiController, for each action method we make using Sitecore.Services.Core.ServicesController("namespace") attribute, we get a url like this:
/sitecore/api/ssc/{namespace}/{controller}/{id}/{action}
I wonder if we could change this default pattern, somehow in config files. I particularly interested in /sitecore/api/ part, because sometimes in the sense of security concerns, certain clients don't like to reveal that much about CMS platform behind the scene. Sometimes they even ask us to hide anything in HTTP header that tells about Microsoft ASP.NET explicitly.
Is this possible here?
Edit
this link shows a way to customize it using pipelines but I wonder if we could change the base url just through config files without needing a custom pipeline
I had a look at it, and I think I found out how - although I haven't tested it.
It looks for a setting named Sitecore.Services.RouteBase and if it can't find it, it uses sitecore/api/ssc/ as the default value.
You should be able to change it with a config patch like this in the App_Config/Include folder:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<settings>
<setting name="Sitecore.Services.RouteBase" value="custom/api/" />
</settings>
</sitecore>
</configuration>
I have a clean install of Sitecore 6.5, DMS 2.0, and the E-Commerce Module and Sample Site (v1.2). When I have the sample site installed, most of the images appear to be broken. The HTML that is rendered includes img src attributes that contain a path that start with /~/. Example:
http://~/media/Images/Ecommerce/Examples/Products/Digital%20SLR/D200.ashx?w=250&as=1
Now, I'm assuming this is either because the sample site hasn't been updated in a while to stay current with Sitecore changes, or there is a configuration for media paths that get returned from it. Here's an example of the XSLT rendering used to write the image:
<img id="product_shot" class="fix" alt="{sc:fld('alt',.)}" title="{sc:fld('alt',.)}" src="/{sc:GetMediaUrl(.)}?w={$ImageWidth}&as=1" />
Does anyone know of a way to prevent the image url from being rendered with a ~ when using XSLT? Did I do something wrong with my initial setup and configuration?
John West gives a great breakdown here: http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2012/12/Sitecore-Idiosyncrasies-Media-URLs.aspx
The important info being a configuration of "Media.MediaLinkPrefix". You can create a patch file, or modify your Web.config to change it to something else. The places I've read have people changing it to a single dash "-/media"
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<settings>
<setting name="Media.RequestExtension">
<patch:attribute name="value"></patch:attribute>
</setting>
<setting name="Media.MediaLinkPrefix">
<patch:attribute name="value">-/media</patch:attribute>
</setting>
</settings>
<customHandlers>
<handler trigger="-/media/" handler="sitecore_media.ashx"/>
</customHandlers>
</sitecore>
</configuration>
Another solution which I can think of is to change your web.config like this:
InvalidItemNameChars: Add “~“
But this will work not only for images but for any content items out there in your Sitecore content tree.
This is more of a workaround than a solution. Since I'm setting this up for demo purposes, it'll do just fine.
In web.config, I changed the value of Media.MediaLinkPrefix to include the hostname and media prefix. Since the Sitecore E-Commerce Example Site XSLT renderings start all calls to sc:GetMediaUrl(.) with a / character and sc:GetMediaUrl(.) itself returns its first character as a /, this causes the src attribute value to be written with the full host name and then correctly resolves:
<img src="//sitecore.local/~/media/Images/Ecommerce/Examples/Products/Digital%20SLR/D200.jpg />
Far from ideal, but for these purposes, this workaround did the trick.
Here's my situation : in the webapp, I use an interceptor to set the language(Locale).
If a user is logged, I used the language property of this user.
Else if a cookie is set, I use the value of this cookie.
Else, I use the setting of the browser.
It works well when I navigate into the app and when I am logged.
The problem is at the welcome page, since it calls mydomain.com/index.jsp, it don't go through the interceptors so the language isn't set(it's always using the browser setting).
Is there a way to go through the interceptors on the index page or to set the Locale value in the index.jsp page ?
Thank you!
The solution :
I removed the .jsp from the index.jsp in the web.xml file :
<welcome-file-list>
<welcome-file>index</welcome-file>
</welcome-file-list>
I added the index action to my struts.xml file :
<default-action-ref name="index" />
<action name="index">
<interceptor-ref name="appStack" />
<result name="success">index.jsp</result>
</action>
The language interceptor is part of the appStack.
Thank you guys for your helps!
I recommend that you do one of two things: (your choice)
(1) Implement your logic in a web filter and have your container configured with this filter so you can set the language (if not already set). This is easy to do, just look at any example of a HelloWorld filter.
or...
(2) Make sure that your home page is only reachable as a Struts2 action (you can define a default action in your Struts2 config file) and ensure that your interceptor is part of the default stack.
Hope that helps!
I would just add the conventions plugin (struts2-conventions-plugin-x.x.x.jar) where x.x.x is the version you are using.
Then I would move all the public jsp's under /WEB-INF/content and be done.
In your web.xml I don't mention any welcome files... but if you would like to be explicit:
<welcome-file-list>
<welcome-file>index</welcome-file>
</welcome-file-list>
If using Struts 2.2.1 your web.xml should minimally look like...
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<filter>
<filter-name>action</filter-name>
<filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>action</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
If you want to do it the struts.xml way then just move the index.jsp under /WEB-INF and create an action mapping for it... something like:
<action name="index">
<result>/WEB-INF/index.jsp</result>
</action>
which would be in a package with namespace "/" or "".
On the other hand I haven't looked at the Local stuff in a while but are you sure you're not reinventing the wheel... the i18n interceptor is already in the default stack.
Look into it's use. Long story short there are language property files defined for each language. If Struts2 has determined such properties are in use then then the struts tags will search the value in its name attribute for a matching string in the property file and return the value of that map entry.
It all works pretty slick. Sorry if this is what you are already doing but on the chance you didn't know it should save you a lot of time.
I'm using ant, ivy and nexus repo manager to build and store my artifacts. I managed to get everything working: dependency resolution and publishing. Until I hit a problem... (of course!).
I was publishing to a 'release' repo in nexus, which is locked to 'disable redeploy' (even if you change the setting to 'allow redeploy' (really lame UI there imo). You can imagine how pissed off I was getting when my changes weren't updating through the repo before I realised that this was happening.
Anyway, I now have to switch everything to use a 'Snapshot' repo in nexus. Problem is that this messes up my publish. I've tried a variety of things, including extensive googling, and haven't got anywhere whatsoever. The error I get is a bad PUT request, error code 400.
Can someone who has got this working please give me a pointer on what I'm missing.
Many thanks,
Alastair
fyi, here's my config:
Note that I have removed any attempts at getting snapshots to work as I didn't know what was actually (potentially) useful and what was complete guff. This is therefore the working release-only setup.
Also, please note that I've added the XXX-API ivy.xml for info only. I can't even get the xxx-common to publish (and that doesn't even have dependencies).
Ant task:
<target name="publish" depends="init-publish">
<property name="project.generated.ivy.file" value="${project.artifact.dir}/ivy.xml"/>
<property name="project.pom.file" value="${project.artifact.dir}/${project.handle}.pom"/>
<echo message="Artifact dir: ${project.artifact.dir}"/>
<ivy:deliver
deliverpattern="${project.generated.ivy.file}"
organisation="${project.organisation}"
module="${project.artifact}"
status="integration"
revision="${project.revision}"
pubrevision="${project.revision}" />
<ivy:resolve />
<ivy:makepom
ivyfile="${project.generated.ivy.file}"
pomfile="${project.pom.file}"/>
<ivy:publish
resolver="${ivy.omnicache.publisher}"
module="${project.artifact}"
organisation="${project.organisation}"
revision="${project.revision}"
pubrevision="${project.revision}"
pubdate="now"
overwrite="true"
publishivy="true"
status="integration"
artifactspattern="${project.artifact.dir}/[artifact]-[revision](-[classifier]).[ext]"
/>
</target>
Couple of ivy files to give an idea of internal dependencies:
XXX-Common project:
<ivy-module version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
<info
organisation="com.myorg.xxx"
module="xxx_common"
status="integration"
revision="1.0">
</info>
<publications>
<artifact name="xxx_common" type="jar" ext="jar"/>
<artifact name="xxx_common" type="pom" ext="pom"/>
</publications>
<dependencies>
</dependencies>
</ivy-module>
XXX-API project:
<ivy-module version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
<info
organisation="com.myorg.xxx"
module="xxx_api"
status="integration"
revision="1.0">
</info>
<publications>
<artifact name="xxx_api" type="jar" ext="jar"/>
<artifact name="xxx_api" type="pom" ext="pom"/>
</publications>
<dependencies>
<dependency org="com.myorg.xxx" name="xxx_common" rev="1.0" transitive="true" />
</dependencies>
</ivy-module>
IVY Settings.xml:
<ivysettings>
<properties file="${ivy.project.dir}/project.properties" />
<settings
defaultResolver="chain"
defaultConflictManager="all" />
<credentials host="${ivy.credentials.host}" realm="Sonatype Nexus Repository Manager" username="${ivy.credentials.username}" passwd="${ivy.credentials.passwd}" />
<caches>
<cache name="ivy.cache" basedir="${ivy.cache.dir}" />
</caches>
<resolvers>
<ibiblio name="xxx_publisher" m2compatible="true" root="${ivy.xxx.publish.url}" />
<chain name="chain">
<url name="xxx">
<ivy pattern="${ivy.xxx.repo.url}/com/myorg/xxx/[module]/[revision]/ivy-[revision].xml" />
<artifact pattern="${ivy.xxx.repo.url}/com/myorg/xxx/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
<ibiblio name="xxx" m2compatible="true" root="${ivy.xxx.repo.url}"/>
<ibiblio name="public" m2compatible="true" root="${ivy.master.repo.url}" />
<url name="com.springsource.repository.bundles.release">
<ivy pattern="http://repository.springsource.com/ivy/bundles/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
<artifact pattern="http://repository.springsource.com/ivy/bundles/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
<url name="com.springsource.repository.bundles.external">
<ivy pattern="http://repository.springsource.com/ivy/bundles/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
<artifact pattern="http://repository.springsource.com/ivy/bundles/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
</chain>
</resolvers>
</ivysettings>
w00h00t.
(There's something cathartic about asking the world for help. Usually you fix the problem much faster, even without a response).
Anyway, for the interested it came down to a couple of things:
a) the addition of -SNAPSHOT to all revisions. This involved forking a second ivy.xml -> ivy.SNAPSHOT.xml and referencing that explicitly in the ivy ant tasks.
b) given that this is a manual addition I had to go through my entire tree of build files and provide parallel paths for release and snapshot flows. This, in my opinion, is lame. But, as I guess we're extremely unlikely to invent any other type of flow, this probably won't bloat, and 2 parallel flows is where it will stay.
c) I specified various hints to ivy to check for updates to the snapshots. e.g. checkUpdated="true" and changePattern=".*-SNAPSHOT" on the resolver. And the addition of
<modules org="myorg" name=*" resolveMode="dynamic" />
Still, it'd be nice if there had been automatic integration with snapshot stuff. A bit of (optional) cleverness on the part of ivy. Let's face it, maven repos like nexus ARE really useful and I'm certainly using ivy only to get round maven's crappy build process. I like using nexus.
Anyway. If anyone ever wants to question further on this, feel free.
I'm not sure if this would help with the problem of having 2 sets of configurations, but at least the build.xml would be a little bit simpler.
You can define the revision attribute on the info element in ivy.xml as ${project.revision}.
You can then omit the revision="${project.revision}" attributes on ivy elements in build.xml.
See my answer on this another question for example:
https://stackoverflow.com/a/8853823/1148030
It should be noted, the only necessary step is to include the '-SNAPSHOT' to revision when publishing to Nexus. The other steps listed in the answer are optional/improvements. To pull the published item down, you need to add '-SNAPSHOT' to the revision as well.