I'm looking for a solution which allows me to proxy specific requests from my Spring MVC webapp to an another HTTP server while running in development profile. What i'm trying to achieve is to make Dart's Pub serve the web application files on it's own HTTP port, but map this path into my Spring MVC application so the Spring provided REST resources and the Dart files will be served from the Spring MVC HTTP server from the browser's perspective of view. In a release configuration these files will be bundled into the war so the proxy will be not required.
I wonder if this is supported by any built in MVC element in Spring (eg. the mvc:resource) or i have to write my own proxy element for this?
It can be done using a special Controller which's bean can be assigned to a profile and included in the dispatcher context scope only in development time.
Related
according to this guide! I run servlet successfully, but some of actions of the servlet failed, because they need servlet-api 2.5+ support. how can I use my own servlet-api library instead of domino web server's old version.
thanks!
David Taieb (software architect at IBM) stated in a comment to a blog post:
In 8.5.2, Domino introduced support for Equinox Http Service which allows you to create lightweight servlets registered via extension points. I say lightweight because these servlets are not run within the context of a traditional J2EE Web App with web.xml support. However, the Equinox Http Service lets you associate an http context to different servlets so that they share the same http session object.
Starting in 8.5.3, Domino will start supporting the XPD Web Container which is a full fledged J2EE Web Container (although it does not support things like EJBs). With the XPD Web Container, you can transform almost any WAR into a WAB (Web Archive bundle) and run it in Domino.
You maybe also want to take a look at Servlet Sample at OpenNTF.
Otherwise, please state the version of Domino, you are currently using.
I have web app which is already developed based on Spring MVC. I need to re-implement that web app in Mule.
Can I develop the mule application based on Spring MVC?
Can I declare the Spring MVC dispatcher servlet inside a mule's servlet endpoint and take things further from there?
The web app has web.xml where it defines the DispatcherServlet, the contextparams, the listener classes and so on. How can we remodel that in a mule application?
Any examples where a mule application is developed based on SpringMVC would be great.
Thanks to its embedded Jetty container, you can deploy any JavaEE web application in Mule. So there's no need to remodel anything.
The "Boosktore" example application demonstrates running web-apps within Mule: https://github.com/mulesoft/mule/tree/mule-3.x/examples/bookstore
Mule ESB is not an MVC Framework. It is developed using enterprise integration patterns in mind.
Please go through this blog, to know when to use ESB.
spring mvc can be integrated with mule.
Define all your spring related configuration in separate xml file and include it in mule configuration file.
You can write your custom transformers ,in the custom transformations you can inject or do an autowire of your service classes and from service object you can interact with dao layers.
Lately my focus has been on creating an ASP.NET MVC application that can host 3rd party MVC plugins. Ideally, development of those plugins would follow these rules:
Plugins can be developed in a standard MVC project, and be able to use all the existing infrastructure of the ASP.NET MVC framework.
The complexity of compiling the plugin MVC project and including into a host MVC application should not be severe.
Any changes to the normal development flow of an MVC application would be the bear minimum
After some research I've come up with the following approaches to achieve this, each with their own advantages and disadvantages.
Approach 1 - MVC plugin assembly loaded into main MVC AppDomain
Work Flow
Develop plugin inside a separate MVC project.
Compile the assembly and load it and any dependencies into the host application via PreApplicationStartMethodAttribute, MEF or a basic assembly reference within the host project (if possible).
Map a route to the plugin controllers so that the plugin is treated as an Area within the host.
Place the plugin views into the correct area folder. The layout file will need to be changed so that the layout path points to an area based location, rather than the root of the application (which would have been the case in the development MVC project)
When a request comes in for the plugin, ASP.NET will use the existing areas functionality to route the request to the correct controllers and look in the correct location for the view files.
Advantages
Will work as seamlessly as if the controllers were embedded in the host MVC application assembly.
Simple to include the assemblies into the host App Domain before application start (PreApplicationStartMethodAttribute, project reference) and after application start (MEF)
Disadvantages
No sandboxing - the controllers will have the same trust level as host.
Conclusion
This is the easiest approach, however it is also the least secure. It essentially removes the possibility of allowing untrusted developers to create plugins because those plugins will have the same trust level as the host application (meaning that if the host application can execute methods such as System.IO.File.Delete, so can the plugin)
Approach 2 - MVC plugin assembly running in own AppDomain via MAF
This approach intends to allow the creation of MVC plugins that can be sandboxed into their own AppDomains and used by the host via the System.Addin libraries.
Structure
A route is setup in the host that determines whether the url being processed is targeting a plugin. May have a pattern such as example.com/p/{plugin}/{controller}/{action}/{id}
All routes that have the above pattern are mapped to a host controller that has a module routing action. That action looks at any given route and determines the appropriate plugin to process the request based on the {plugin} segment.
The plugin view is a receiver/sender object that acts as a gateway to the plugin controllers. It has a method called AcceptRequest that receives a RequestContext from the host, and that returns an ActionResult.
The plugin pipeline contains adapters that can serialise RequestContext and ActionResult for transmission across the isolation boundary of the pipeline.
Execution Flow
A route for a plugin is matched and the plugin routing controller is called.
The controller loads the required plugin into it's own AppDomain and calls AcceptRequest, passing through the RequestContext (which is serialised via the pipeline)
AcceptRequest receives the context and determines the appropriate controller to execute based on that request (using a custom controller factory).
Once the controller has finished executing the request, it returns an ActionResult to the receiver object which then passed that ActionResult (also serialised via the pipeline) back to the host AppDomain.
The controller that initially called AcceptRequest can then return the ActionResult to the host MVC execution pipeline, as if it processed the request itself. The plugin AppDomain can then be unloaded if so wished.
Advantages
Plugin will be sandboxed in it's AppDomain, thus any permission set can be used that suits the host.
Disadvantages
Would have to be possible to serialise RequestContext and ActionResult.
Will possibly break other ASP.NET MVC functionality within the isolated AppDomain.
Conclusion
This approach sounds good on paper, but I'm not sure if it's possible/feasible to serialise the RequestContext and ActionResult objects, as well as run an MVC controller in isolation.
Questions
The first approach is fine if the code is being created by trusted developers. I know that I'm not going delete all the host view files or it's web.config file. But ultimately, if you want third party devs to create plugins for your MVC app, you need to be able to sandbox their code.
From all my research, the System.Addin library makes it easy to implement a host/plugin environment when you are using simple API based class libraries. However it seems that it isn't easy to do this when MVC is involved.
Some questions I have are:
Is the second approach I've outlined here feasible?
Is there a better way to do this?
Is there going to be easier ways to achieve MVC plugin isolation in the future?
You're going to end up making separate sites for each plugin. This way you can create reduced-privilege users for each AppPool and a systems administrator can install the "plugin" as a website running under that user.
Any alternatives are going to exhibit the Inner Platform antipattern. Unless you have a lot of time and money to spend developing a plugin-hosting system, you're going to become mired in it and resent it. I speak from experience.
The sites can share AspnetIdentity user repos and you can provide your core objects as a dll that can be referenced. Host your content (script files, css, images) on a CDN so they can be referenced. If you want to share views with your child sites, compile them in as resources:
Including Pre-Compiled Views in an ASP.NET MVC Web Application
Good luck!
IMHO System.AddIn is a a bit overkill for what you are trying to do.
Are you familiar with the System.Security.Permissions namespace? If not you could have a look at the FileIOPermission. Perhaps you could sandbox your extensible system by using (and why not, even extending) the Code Access Security mechanism of .NET.
When an AJAX call from the client side hits the server url, data of the type JSON, XML or CSV is exchanged with the browser.
What are the various alternatives for the server side end point for each of the following technologies for the AJAX url call (i.e. xmlhttprequestobj.open(TARGETURL))
1) ASP.NET (excluding AJAX Toolkit)
TARGETURL can be ASMX, WCF services, ASP .NET page serving the content
Is there any other way?
What is the standard way?
2.) For Java EE the target URL should be a servlet?
What is the standard here?
3.) How does it work for the LAMP stack and PHP?
What is the standard here?
For Java EE, Servlets can indeed be used. However, if you're looking at a more of less independent client application that does (AJAX) calls to server-side services, then JAX-RS is much more typical. JAX-RS' main function is to provide RESTFull web-services.
If you're looking at web pages that are more integrated with the server application, then JSF has first class support for processing AJAX calls as well. JSF's main function is to provide a component based MVC web framework.
The big difference is that with JAX-RS, you'll be making explicit calls using some URL pattern from your application and will manually process the data it returns (which can be in JSON or XML, but is rarely CSV).
With JSF the AJAX machinery is more a behind the scenes kind of thing for the average application developer. You put some component on your page, specify bindings to some backing bean, and at run-time AJAX interactions will take place.
You can use for example mod_rewrite in apache with php application and then your url can be for example yourapp.com/user/seahorse and this can be mapped by your application to whatever.php script. So url needn't be exactly mapped to some code unit.
If you are using LAMP, then you probably create new virtual host in apache config files, that is mapped to some domain (for example yourblog.com). And then if apache gets request to this domain, then it see to home directory of this app and try find appropriate script.
yourblog.com/user/whatever.php -> yourblog directory -> user directory - whatever.php
script.
Or you can put special file .htaccess to home directory of your app and in this file put some rewrite condition, for example all requests to index.php script.
Can anyone tell me the purpose of this HttpModule? It's showing up on my HttpModuleCollection list, but I don't know what's it's for.
System.ServiceModel.Activation.HttpModule
I can't find any documentation on it.
System.ServiceModel.Activation.HttpModule come from because you installed "Microsoft .NET Framework 3.5.1" / "Windows Communication Foundation HTTP Activation" feature. If you don't need the feature you can uninstall it of remove the module from your web.config. The less unused modules you load the more quickly run your web application.
If you install this feature after the installation of .NET 4 framework on your server you can receive problems described in http://blogs.iis.net/webtopics/archive/2010/04/28/system-typeloadexception-for-system-servicemodel-activation-httpmodule-in-asp-net-4.aspx.
In general an HTTP module is called on every request in response to the BeginRequest() and EndRequest() events. As a result, the module runs before and after a request is processed. In the section "How HTTP Modules Work" on http://msdn.microsoft.com/en-us/library/bb398986(v=VS.100).aspx you can read more about HTTP modules.
http://msdn.microsoft.com/en-us/library/ms227673.aspx describes how to create a Custom HTTP Module. Some small custom modules can be really helpful. For example, you can read in How to remove the ".svc" extension in RESTful WCF service? a code example (which originate from the book "RESTful .NET", Chapter 5, page 96) "Removing the .SVC Extension from WCF REST URLs". In http://www.west-wind.com/weblog/posts/570695.aspx you can read how to do the same with respect of "IIS 7 Rewrite Module".
The general information about HTTP module is not a part of your question, but I inserted it to better understanding what Activation.HttpModule do, and what other more useful modules you can use or write yourself.
This module is what allows WCF (Windows Communication Foundation) services to work (starting in .net Framework 3.0).
You can safely ignore it and it shouldn't cause trouble. If you really want to get rid of it, you can remove it from your root web.config file (e.g. in
\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config). But I suggest leaving it there just in case you need WCF at some point.
A http module is a .net assembly that is called every time your web application gets a request. This is the standard one that asp.net provides that connects your .net web application code to the IIS web infrastructure.
See here for an explanation.
HTTP Modules
An HTTP module is an assembly that is
called on every request that is made
to your application. HTTP modules are
called as part of the request pipeline
and have access to life-cycle events
throughout the request. HTTP modules
therefore let you examine incoming
requests and take action based on the
request. They also let you examine the
outgoing response and modify it.
In IIS 6.0, the ASP.NET request
pipeline is separate from the Web
server request pipeline. In IIS 7.0,
the ASP.NET request pipeline and the
Web server request pipeline can be
integrated into a common request
pipeline. In IIS 7.0, this is referred
to as Integrated mode. The unified
pipeline has several benefits for
ASP.NET developers. For example, it
lets managed-code modules receive
pipeline notifications for all
requests, even if the requests are not
for ASP.NET resources. However, if you
want, you can run IIS 7.0 in Classic
mode, which emulates ASP.NET running
in IIS 6.0. For more information, see
ASP.NET Application Life Cycle
Overview for IIS 7.0.
ASP.NET HTTP modules are like ISAPI
filters because they are invoked for
all requests. However, they are
written in managed code and are fully
integrated with the life cycle of an
ASP.NET application. You can put
custom module source code in the
App_Code folder of your application,
or you can put compiled custom modules
as assemblies in the Bin folder of an
application.
ASP.NET uses modules to implement
various application features, which
includes forms authentication,
caching, session state, and client
script services. In each case, when
those services are enabled, the module
is called as part of a request and
performs tasks that are outside the
scope of any single page request.
Modules can consume application events
and can raise events that can be
handled in the Global.asax file. For
more information about application
events, see ASP.NET Application Life
Cycle Overview for IIS 5.0 and 6.0 and
ASP.NET Application Life Cycle
Overview for IIS 7.0.