Lift Framework seems to need a lot of very specific configuration to serve static files. This is pretty tough if you want to use something like jQueryUI with Lift. Can anyone point me to a Lift project that has all the configuration necessary to use jQueryUI?
No extra configuration is needed to use JQuery UI with Lift. Simply put the JS files into the webapp directory like you would with any other static resource. The servlet container will serve that exactly like it would for any other WAR application.
You only need to resource server stuff if you want to serve files from deep in your class path (like from another JAR for example)
Related
My application ear is bundled with static resources like js, css, images, etc and was serving js files at URI app/scripts. These requests were passing through filters in the application. Now I configured WildFly to serve static contents like images, js and css. It is served at path app/scripts for js. Since both have same URI which one will be working now? It looks like static content is getting precedence because I noticed that now request are not passing through filters. Which method is better option to improve performance?
Hi Make your static contents as a separate deployment. And Create a folder named "MyContents.war" in deployment folder of your Wildfly and keep all your scripts, css what ever inside that folder, add the following settings in your standalone.xml file inside <server> tag.
<deployments>
<deployment name="MyContents.war" runtime-name="MyContents.war">
<fs-archive path="deployments\MyContents.war" relative-to="jboss.server.base.dir"/>
</deployment>
</deployments>
Now to access any resource like a script file for example scripts.js
http://<yourhost>:<port>/MyContents/scripts/scripts.js
Hope this helpful for you.
I am developing and application as a series of OSGI bundles which will run on Karaf.
The Bundles has a fair bit of interoperability, both exposing a bunch of services, and consuming services from each other.
However, I would very much like to be able to build a WAR file of the application alongside the bundles. There are a few clients that quite simply won't allow an OSGI container on their servers.
So my question is, what is the best way to separate the OSGI service logic from the application logic? The activators are no trouble, as they are just unused in the WAR deployment, but i have a lot of calls that retrives services from the bundlecontext, like bundleContext.getServiceReference(stuffISortOfNeed.class)scattered around my code. bundleContext is currently a static object set by the activator.
This won't do in a WAR container that knows nothing of OSGI.
Is it possible to somehow hide the BundleContext and the getServiceReference calls away from the actual application? Preferably i would love an injection-like approach where i could define my services with #Annotations and define and injector for OSGI and one for PlainOldJava.
To really have POJOs you could use Blueprint XML to register your Web Application Bundle (WAB).
A good example can be found in the pax web project.
By using XML over annotations you only have an extra resource file that can be ignored if you assemble you bundles as libs in a war file, no extra dependencies on specific annotations.
I'm the client-side guy at my job and for the web application we're building I am introducing some new JS libs besides the already residing jQuery and jQuery UI. We use the standard folder structure setup with CSS and images in ~/Content and JS in ~/Scripts. In the latter we have our internally developed libs categorized into subfolders such as ~/Scripts/Plugins.
However, now I want to add i.e. TinyMCE and find myself confused. NuGet installs all TinyMCE-related files to ~/Scripts/tinymce, but tinymce/skins holds CSS and images which I feel should not be contained in the ~/Scripts folder.
What is the proper way to structure vendor libs within the MVC file structure? Or, if there is no proper way, is there a proposed best practice? I don't feel like * up the original neat structure too much. Note that I am not looking for creating bundles, that lies in the future and the on-disk structure is a separate concern.
Currently I have a web service, which loads up any plugins located within its /plugins folder. Now the problem is that each plugin has its own set of configuration data, currently hardcoded and isolated into a single class, but I want to move this out into a myplugin.config file.
Normally the web service loads up its own web.config file, but I am not sure if I can get the plugins to use their own ones. As if you imagine the main web service uses NHibernate and does CRUD stuff with some arbitrary data, but one of the plugins adds a caching layer using MongoDB and has its own connection string details. So the MVC web service shouldn't really care about these settings, it should just be the MyPlugin which would need to read them.
Is there any way to do this? As I just want to get away from having the connection string ingrained within the code.
I have sorted this problem now, I was able to do it without much work really once I found out how config files could be loaded in.
I made sure my config file was named after the assembly loaded via MEF, so if my assembly was:
some-custom-plugin.dll
You would make a config file named:
some-custom-plugin.dll.config
then you would call:
var config = ConfigurationManager.OpenExeConfiguration("some-custom-plugin.dll");
var someValue = config.AppSettings["some-app-setting"];
So hope this helps someone as it took me a while to find this simple thing out.
I'm writing a Grails app which I'd like 3rd parties to augment at runtime. Ideally they would be able to add a JAR/WAR to the webapp directory which contains new domain, controller and service classes, new views, and other content.
Is there a simple way to do this within grails? Would it be simplest to create a startup script which copies the new classes etc. into the relevant directories and then updates grails.xml and web.xml?
You will be able to do this in version 2 of grails in which plugins will be also OSGI plugins http://jira.codehaus.org/browse/GRAILS/fixforversion/15421
It seems that the Grails plugins will actually fit quite well for this: http://www.grails.org/Understanding+Plugins
A plugin can do just about anything... One thing a plugin cannot do though is modify the web-app/WEB-INF/web.xml or web-app/WEB-INF/applicationContext.xml files. A plugin can participate in web.xml generation, but not modify the file or provide a replacement. A plugin can NEVER change the applicationContext.xml file, but can provide runtime bean definitions