Front Controller Servlet

Hello friends.
I need to implement a Front Controller servlet. I will then forward the request to other servlets. So, even I the client explicitly requests the servlet, say /Dummy, I want the request to pass through /FrontController first.
If I map FrontController to /*, and Dummy to /Dummy, then the letter will override the more general mapping. Also, the first mapping (/*) will spoil all other URL requests, such as /index.htm, etc.
Please, give a hint.

Is it possible at all?
When a servlet is called (any servlet), another servlet intercepts it first, and then forward the request to the called servlet.

Similar Messages

Splitting up the Spring front controller servlet into more than one file

In a multi-developer environment, it's obviously a bit of a pain to all use the same front controller xml file for mapping requests. Therefore does anyone know of a way we could split this into many files, for example one for each logically distinct application?
Many thanks

Hi,
What are these files did you want to delete? As I know, the trusted installer group owns many system files and will deny you access to move or delete. incorrect deletion of these files will cause serious problem. If you want to delete these files, you can
take the owner of these files and guarantee administrator permissions with icacls command, it can reduce amount of your work.
How to Handle NTFS Folder Permissions, Security Descriptors and ACLs in PowerShell
http://blogs.technet.com/b/josebda/archive/2010/11/12/how-to-handle-ntfs-folder-permissions-security-descriptors-and-acls-in-powershell.aspx
And according to your description, do you want to convert an internal hard drive to external? if so, how did you perform this action? here is an article you can refer to:
http://www.computershopper.com/peripherals/howto/build-your-own-external-hard-drive
NOTE
This
response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you.
Microsoft
does not control these sites and has not tested any software or information found on these sites.
Yolanda Zhu
TechNet Community Support

Front controller calls

Hey all
At the moment my front controller servlet determines where my JSP calls come from via hidden html fields, sort of like this:
<input type="hidden" name="jspSource" value="addToFavorite" />But I've also seen people take this route:
<form action="/controllerServlet?action=<addToFavorite>Are there any conventions here I should follow? I find that my method works well, but I need a bunch of if clauses in the controller to determine where the call comes from, like this if(jspSource.equals("addToFavorite"))

Just always use the same parameter. I usually use two parameters:
action - this determines what servlet / jsp to invoke
subaction - this determines what the servlet should do and what the jsp should display.
Example:
action - repository
subaction - deletefile

Front Controller Pattern and issues

Hi,
I've implemented the front controller pattern using a Servlet and some JSP pages. The issue I have is that if the JSP page button is clicked, the controller handles the request and performs the proper forwarding.
But for instance, if I type in the URL for the page directly without going through the servlet in the FORM tag then obviously the servlet cannot process the request.
Here's a more concrete example: I have an informational page that you get to by first logging in. But if I type the name of the page directly, http://localhost/employerInfo.jsp I am taken directly to this page, even though I should have logged in first.
I believe there's a way to do this, but I'm completely stumped as to how.
Any information or insight is greatly appreciated.
Thanks,
John

Hey John,
What you need to do is not to access the employerInfo.jsp directly but call the servlet.
You can map a servlet to a URL. For example, using your example below you can call: http://localhost/myservlet?action=openEmployeeInfo
Now your servlet can retreive the action using String x = request.getParameter("action"); You can test if x.equals("openEmployeeInfo") then get the information from a db or something else. Set the info on a context like request, session or servlet context and then forward to the jsp page using the request dispatcher.
RequestDispatcher rd = request.getRequestDispatcher("/employeeInfo.jsp");
rd.forward(request, response);
If you have more questions, post here again.

Front Controller in Web Logic

I am currently working on a front controller.
WHat i whant to do is pass all call to object on my server through this controller
like this
a get for /Info.jsp is caught by the /* servlet url pattern
next i will handle and check things.
Finally a want t pass the user the Page.
This causes a loop.
Anybody any ideas on how to solve this in web logic

I think what you need to do is make sure that your scripts are not stored in the root path of your application.
In your example you are using the root context to trap all requests incoming, processing that request and then presumably trying to forward or redirect to the /login.jsp page after initial processing. Unfortunately requests sent to /* are intercepted and passed to your controller so the attempt to forward to /login.jsp loops back through your server repeatedly.
Perhaps if you map your controller servlet to a different context to the one where you store your scripts you will then be able to forward successfully
e.g map the context /members/* to your controller, but store your scripts in the /private context - /private/login.jsp . Then provide a mapping in your controller between script name and actual script location, do a lookup and forward accordingly.
if you make sure that all your links within your application point through /members/ they will always be processed through your controller. For example the login page would be accessed as /members/login.jsp but after processing in your controller you do a look up and see that login.jsp is in private so you forward your request to /private/login.jsp .
Well, thats how I would approach it anyway ....

Difference between MVC & Front- Controller

Hi All,
could anyone help me out in differenciating the MVC & Front controller patterns.
regards
Karthik

When should an application use the Front Controller
patern and when should they use MVC? This boils down to scope of the problem domain and requirements.
The Front Controller seems largely like a subset of
MVC.Yes.
Is there a situation where the Front Controller
is more advantageous to use than MVC?Where its lighter weight pays off, i.e where you do not have a conventional model, e.g with streaming prototcol handlers or with fast readers. MVC is most useful for a N-Tier J2ee application offering CRUD type functionality.

Musings: MVC Front Controller/Command and Controller Strategy

Hi,
I am currently taking my first shot at implementing the Front Controller pattern, the Command and Controller Strategy flavor, in Java. When applying the pattern, my chosen point of focus is achieving as much isolation as possible of Client-specific implementation details from the rest of the framework (Web-based framework Clients, Swing-based framework Clients, queueing-based framework Clients, etc.) However, I am running into a lot of (apparent?) inconsistencies when it comes to CCS discussions "out there", so I have a feeling that perhaps I have misunderstood the Front Controller/Command and Controller Strategy pattern. Maybe the MVC gurus out there would have some thoughts on the matter.
My issues:
1.) Some CCS discussions seem to assign View presentation (sometimes called "dispatch", or "rendering", or "forwarding"?) to an ApplicationController. It seems puzzling to me, since only a concrete FrontController should include any knowledge of a concrete View structure. Shouldn't only a FrontController perform a logical-to-physical resource mapping, thus encapsulating knowledge whether a particular View is a separate, stand-alone Web page or a compound, argument-driven Swing object, and how to "present it" (by either redirecting to a Web page, or bringing a particular Swing object into the foreground)?
2.) Some CCS discussions seem to introduce Client-specific implementation details at the ApplicationController level, for example "HTTP requests" or "HTTP responses". It seems puzzling to me, since I feel that every part of the framework, except for a concrete FrontController, should be completely independent of the nature of a Client making a request. Instead, I created a generic Request object w/arguments and have a concrete FrontController translate any client-specific details into such a generic Request, before delegating to an ApplicationController.
3.) In the light of the (2.) above, I am not sure what constitutes a "response" from an ApplicationController back to a FrontController. It seems to me that the only universal "response" is a LogicalViewEnumeration: what View to present once a command has been completed, in many cases a "don't care", or a "show the requestor", or a "show a home page" (not every request has to result in changing a View). Well, perhaps a LogicalViewEnumeration as well as possible View arguments (?).
4.) In the light of the (3.) above, I suspect that any failures in Request delegation, or Command execution, should be perhaps propagated back to a FrontController by exceptions only, since, say, a WebFrontController might want to show a click-through error page, when a SwingFrontController might prefer to show an error dialog box, a LogicalErrorViewEnumeration might not make sense at all in the context of a particular Client, for example a queueing Client.
5.) In the light of the (4.) above, there is the question of an appropriate Request interface (into an ApplicationController), an appropriate Response interface (back into a FrontController), as well as an appropriate ViewArguments interface (into a FrontController and later into a View). The problem with generic Requests is that they can be created with nonsensical argument combinations, so shouldn't Requests be abstract and force proper arguments in concrete subclasses, through explicit constructors (in a sense, degenerate Commands)? The problem with Responses and ViewArguments is that... well, I have not found any formal discussion anywhere as to what those should look like. In most samples I have encountered, Responses include Client-specific implementation details, as mentioned in (2.), above.
6.) Some CCS discussions seem to introduce a Flow Manager at the ApplicationController level. It seems puzzling to me, since the whole point of the Command and Controller Strategy flavor seems to be centralization of business logic execution within self-contained Command objects. Shouldn't Requests get associated with Handlers (objects capable of actually carrying out Requests) and transformed into Commands inside an ApplicationController, thus Commands themselves return appropriate LogicalViewEnumeration back to an ApplicationController, back to a FrontController? Let's consider a ShowMyShippingAddress request coming into the framework: unless such a Request is eventually treated as a Command returning a particular LogicalViewEnumeration, it is suddenly a Flow Manager "acting" as a business logic driver. I guess the question here is: except for a few special cases handled by a particular ApplicationController (authentication, error conditions, default behavior, etc.), should flow management be considered stand-alone, or always delegated to Commands?
7.) Some CCS discussions seem to include an extra Request argument that specifies an ApplicationController to use (Request.Action="create", Request.Controller="account", Request.Username="me-me-me"), instead of using a Router inside of a FrontController to resolve to a particular ApplicationController through a generic action (Request.Action="createAccount", Request.Username="me-me-me"). I am not sure about the reason for such a design decision: why should a Client or a FrontController be allowed to concern itself with an implementation-level structure of the framework? Wouldn't any framework state -dependent ApplicationController resolution issues be best handled inside a Router, used by a FrontController to resolve [obtain] an appropriate ApplicationController, thus preventing Clients from ever forcing the framework into a possibly inconsistent behavior?
Any comments appreciated...
Thanks,
Gary

gniemcew wrote:
1.) Some CCS discussions seem to assign View presentation (sometimes called "dispatch", or "rendering", or "forwarding"?) to an ApplicationController. It seems puzzling to me, since only a concrete FrontController should include any knowledge of a concrete View structure. Shouldn't only a FrontController perform a logical-to-physical resource mapping, thus encapsulating knowledge whether a particular View is a separate, stand-alone Web page or a compound, argument-driven Swing object, and how to "present it" (by either redirecting to a Web page, or bringing a particular Swing object into the foreground)?It is hard to tell without reading the actual discussion, but my guess is that the posters were either conflating or being loose with the distinction between a FrontController and an ApplicationController. The former is (normally) intimately tied to the actual view being used (HTTP, Swing, etc.) whereas the ApplicationController typically is not. Both are involved in dispatch and event processing. The former normally renders a view whereas the latter does not.
gniemcew wrote:
2.) Some CCS discussions seem to introduce Client-specific implementation details at the ApplicationController level, for example "HTTP requests" or "HTTP responses". It seems puzzling to me, since I feel that every part of the framework, except for a concrete FrontController, should be completely independent of the nature of a Client making a request. Instead, I created a generic Request object w/arguments and have a concrete FrontController translate any client-specific details into such a generic Request, before delegating to an ApplicationController.Generic is fine. However, you can become generic to the point where your Request and Response interfaces are only acting as "marker" interfaces (think of java.io.Serializable). Writing a truly generic controller is possible, but personally, I have never found the effort justified.
gniemcew wrote:
3.) In the light of the (2.) above, I am not sure what constitutes a "response" from an ApplicationController back to a FrontController. It seems to me that the only universal "response" is a LogicalViewEnumeration: what View to present once a command has been completed, in many cases a "don't care", or a "show the requestor", or a "show a home page" (not every request has to result in changing a View). Well, perhaps a LogicalViewEnumeration as well as possible View arguments (?).A given service (if you ascribe to SOA) should be the fundamental unit in your architectural design. A good application controller would be responsible for determining how to dispatch a given Command. Whether a Command pattern is used or whether service methods are invoked directly from your FrontController, the ApplicationController should enforce common service aspects. These include authentication, authorization, auditing, orchestration, validation, logging, error handling, just to name a few.
The ApplicationController should ideally offload these aspects from a given service. The service would indicate how the aspects are to be applied (e.g., strong authentication required, x role required, fetching of existing process state, etc.) This allows services to be developed more quickly and to have these critical aforementioned aspects developed and tested centrally.
Your FrontController, in contrast, is responsible for transforming whatever input it is designed to receive (HTTP form data posts, XML-RPC, etc.) and ensure that it honors the contract(s) that the ApplicationController establishes. There are no cut-and-dry decisions though about when a given piece of functionality should be ApplicationController or FrontController. Take error handling. Should I emit just a generic ServiceException or allow the FrontController to decide what to do with a more concrete checked exception? (The FrontController, in any case, should present the error to the user in a manner dictated by the protocol it serves).
gniemcew wrote:
4.) In the light of the (3.) above, I suspect that any failures in Request delegation, or Command execution, should be perhaps propagated back to a FrontController by exceptions only, since, say, a WebFrontController might want to show a click-through error page, when a SwingFrontController might prefer to show an error dialog box, a LogicalErrorViewEnumeration might not make sense at all in the context of a particular Client, for example a queueing Client.See above. Yes. However, the ApplicationController could easily 'hide' details about the failure. For example, any number of exceptions being mapped to a generic DataAccessException or even more abstractly to a ServiceFailureException. The ApplicationController could indicate whether the failure was recoverable and/or populate information necessary to speed up production support (e.g., mapping exceptions to error codes and/or providing a primary key in an error audit log table for support to reference). A given FrontController would present that information to the user in the method that makes sense (e.g., error dialog for Swing, error page for HTML, etc.)
gniemcew wrote:
5.) In the light of the (4.) above, there is the question of an appropriate Request interface (into an ApplicationController), an appropriate Response interface (back into a FrontController), as well as an appropriate ViewArguments interface (into a FrontController and later into a View). The problem with generic Requests is that they can be created with nonsensical argument combinations, so shouldn't Requests be abstract and force proper arguments in concrete subclasses, through explicit constructors (in a sense, degenerate Commands)? The problem with Responses and ViewArguments is that... well, I have not found any formal discussion anywhere as to what those should look like. In most samples I have encountered, Responses include Client-specific implementation details, as mentioned in (2.), above.See comment on marker interfaces above. Nothing, however, stops you from requiring a certain sub-type in a given service method. You can still pass in the interface and validate the proper type by an assert statement (after all, in the vast majority of situations, the proper service method should get the proper instance of a given Request object). IMO, the FrontController would create the Command instance which would be passed to the ApplicationController which would dispatch and invoke the proper service method. A model response would be received by the FrontController which would then render the appropriate view.
gniemcew wrote:
6.) Some CCS discussions seem to introduce a Flow Manager at the ApplicationController level. It seems puzzling to me, since the whole point of the Command and Controller Strategy flavor seems to be centralization of business logic execution within self-contained Command objects. Shouldn't Requests get associated with Handlers (objects capable of actually carrying out Requests) and transformed into Commands inside an ApplicationController, thus Commands themselves return appropriate LogicalViewEnumeration back to an ApplicationController, back to a FrontController? Let's consider a ShowMyShippingAddress request coming into the framework: unless such a Request is eventually treated as a Command returning a particular LogicalViewEnumeration, it is suddenly a Flow Manager "acting" as a business logic driver. I guess the question here is: except for a few special cases handled by a particular ApplicationController (authentication, error conditions, default behavior, etc.), should flow management be considered stand-alone, or always delegated to Commands?There are distinct kinds of flow management. For example, orchestration (or BPM) is properly at either the service or ApplicationController layers. However, determining which view to display is properly at the FrontController layer. The ApplicationController should receive a Command (with a populate Request) and return that Command (with a populated Response). Both the Request and Response are fundamentally model classes (within MVC). The FrontController is responsible for populating the Request and/or Command and rendering the Response and/or Command. Generic error handling is usually centralized for both controllers.
gniemcew wrote:
7.) Some CCS discussions seem to include an extra Request argument that specifies an ApplicationController to use (Request.Action="create", Request.Controller="account", Request.Username="me-me-me"), instead of using a Router inside of a FrontController to resolve to a particular ApplicationController through a generic action (Request.Action="createAccount", Request.Username="me-me-me"). I am not sure about the reason for such a design decision: why should a Client or a FrontController be allowed to concern itself with an implementation-level structure of the framework? Wouldn't any framework state -dependent ApplicationController resolution issues be best handled inside a Router, used by a FrontController to resolve [obtain] an appropriate ApplicationController, thus preventing Clients from ever forcing the framework into a possibly inconsistent behavior?I am not 100% sure of what you are getting at here. However, it seems to be the method by which commands are dispatched. They are in effect allowing a FrontController to dictate which of n ApplicationControllers should receive the request. If we allow a FrontController to directly invoke a service method, then the ApplicationController is simply a centralized framework that should always be invoked for each service method (enforced via AOP or some other mechanism). If there is a single, concrete ApplicationController which handles dispatch, then all FrontControllers communicate directly with that instance. It is really just a design decision (probably based on your comfort level with concepts like AOP that allow the ApplicationController to exist solely behind the scenes).
I might have totally missed your questions, but those are my thoughts on a Monday. Best of luck.
- Saish

Controller Servlet

Hello,
I'm developing web framework.
Framework architecture is the following:
Controller servlet(C) as a gate to JSP in /WEB-INF, so all requests are mado through this servlet.
If request points to simple static JSP page C is doing it's job, but when I need to prepopulate JSP
with POJO value objects I need to make modifications to C code.
C methods grow as application functionality grows and it will be fat soon.
How can I refactor C to make somekind of WebAction to prepopulate JSP not storing Business Logic in
this servlet ?
Thanks in advnce.

I can sympathise with that but consider:
I've broken some long-winded processing down into a
number of smaller methods called from a bounding
"doSomeProcess" method. Either each of these methods
gets a new connection and releases it, in which case
transaction handling becomes an issue or each of the
component methods needs to take the existing DB
Connection as an argument.
The former opens a can of worms and could introduce
well obscured bugs while the later achieves much the
same as my getConnection -> handler.process
->releaseConnection model but by passing the
connection down the line.I prefer the second approach. It keeps one connection open as long as it needs to be, and makes sure it closes as soon as possible. I don't see what making it a member of the class saves, except the passing of a parameter.
Not quite. If the controller gets and releases the
connection, it can be passed into a constructor or set
through an accessor method. The handler itself then
doesn't need to get or release anything. As everything
is going through the controller the connection will
always be tidied away. And with the connection pool
counting the number of times that connection has been
used, we can be confident that it will be destroyed
when its time is up.Okay, that's an approach. but that couples the Controller/Web Application to the Database. I try to keep the data layer separate from the controll layer. My approach is to create a Data Access Interface and code my handlers (and Control Servlet usually won't use it, that is the handler's job) against that. I then set an environmental entry that specifies the concreate implementation of the interface. This means the Handler does not need to change based on what data structure is used in the Underlying Data Access Object.
The immediate benefit is that during early stages orf development, I can create a simple wrapper around a java.util.List when testing my web application and developing an interface to use. Then code my real Data Model to this interface and independently of the web application. When I am sure that both are working correctly independently, I can put them together by changing the environment entry, and nothing else.
This also means that if I want to change how I store my data from a database to XML, or to a feed from an external site, or a resource bundle, or whatever, I can do so without changing my Handlers/Controller, but just by coding a new Data Access Object and fixing the environment entry.
(alternative to the environment entry my be a context parameter that my controller will read, create the class, and pass to handlers, but I still think this is bad since it widens the scope of the DAO)
This was my initial response to building web apps,
probably because of my (long forgotten) ASP
background. However, each method within the handling
process can be made much cleaner and simpler when we
don't need to worry about db connections (getting,
releasing or otherwise handling).But in reality, you are not getting rid of it. You are just moving it further away from where it is used, thus expanding its scope and increasing the possibility for errors. (That is my view anyway...)
If you have time I'd recommend looking into this. I
can't take all the credit for it but I am a staunch
evangelist for the architecture. I guess it's because
I'm lazy and like the idea of all the crunchy bits
being hidden away in superclasses that I don't need to
play with.I am all for a good inheritance pattern, but I am also one for keeping objects in the smallest scope, and as close to their usage as possible. having a method in an abstract super class that closes connections might be usefull, but this would have to (in my book) be part of the Data Access Object's inheritance tree and not part of the Handler's/Controller's. ie: i might have
abstract class SQLDataAccess
with a method called
protected Connection getConnection(...)
that will take a connection from the naming context, initialize it, and return it, and another named
protected void closeConnection(Connection ...)
that will go through the process of closing the DB connection. And then, I might have a method called public List getEmployeeList()
Connection connection = getConnection(...);
List empList = null;
try
    empList = getEmployees(connection);
} catch (...)
finally
    closeConnection(connection);
    return empList;
}or some such...
Then have the abstract method
abstract List getEmployees(Connection ...) throws ...;
that the sub classes might need to implement on a DB specific or case specific manner. But this type of thing would all be in the DataAccessObject heirarchy, and the need for DB connections would never leak out from that into the controller or handler.

Front Controller Pattern

I'm going to implement the front controller pattern. As it is implemented in the blueprints (Pet Store), requestmappings.xml and screendefinitions.xml are only read upon start up. Thus, the web application has to be restarted to carry out changes.
I'd like the possibility to perform changes to these files without restarting the app. How should I go about? As I don't want to read the file for every request, I need some kind of cache. But this cache should have some kind of automatic updating mechanism when the files are changed.
Has anyone done something like this for large web applications?

I've used a similar approach for this (kitv.co.uk), the project not the website, which is pretty heavy weight application, interactive digital Television over IP.
My design used the command pattern (GOF 233), which is (IMHO) a better solution to implement the front controller.
I created an action/command to perform a reload, this re-initialises my request/response handlers (equivelent to the ScreenFlowManager). The re-initialise is really just an alternative wrapper as the initial load.

Page/front controller

Does JSF implement front controller pattern or page controller pattern?
In this article http://websphere.sys-con.com/read/46516.htm I read that it implements page controller but sincerely I am not able to see JSF fit in this pattern...Do you think it is true? But, above all....why?:P
thanks

I hate to do this to you but check this link for the debate: http://mail-archives.apache.org/mod_mbox/struts-user/200603.mbox/%[email protected]%3E
There is no doubt that JSF uses the Front Controller design pattern, but gives you "page controller" funcationality to.

Front controller/database - architecture question

Hello! Thanks for checking out my question! I am pretty new to web services/servlets and jdbc.
I am implementing an application that essentially is an index of reports. I have an index page where a user can click on one of 6 available reports, go to an input page to customize the information being sent into the different queries and then the results of that query will be displayed on the next page. I have two controller servlets.. one for the input pages and another for the output of the queries. I am just curious as to if there should be anything I need to be cautious about when I am coding this. We expect to have no more than 500 users (that is a very high estimate) on the page at a particular time.
My real question is how do I divide the database calls into the program? Should I have a bean for each jsp result page that handles the queries or should I the queries being handled in the controller request? The result of the query is a cachedResultSet and we already have connection pooling set up so the actual database request will only last a short time. I'm just not sure on the best practice as far as these kinds of things go. Do I need to serialize any requests? Should I consider that when I'm writing the servlets/beans/jsps? Thanks in advance for any kind of answers. Have a great day!

Hello,
I worked on something similar to this, here's what I did in a nutshell:
One controller servlet takes requests which describes a query. It delegates the request a specific request handling servlet/session ejb pair. Every servlet/ejb pair then handles the request and dispatches the appropriate response.
There was a lot a similar functionality in the way responses were handled by the ejbs and this could all be encapsulated in a base handler ejb that was subclassed.
This worked well for my problem but I have also used struts to accomplish similar tasks, although I still think struts is a bit too heavy weight for most of my work.
I think you can use a similar pattern with oridanry beans an JDBC to accomplish your task.
We expect to have no more than 500 users (that is a very high >estimate) on the page at a particular time.I suspect most platforms will accomadate your users but what platform are you deploying your application on?
Do I need to serialize any requests?I don't think so, but why do you ask, will your application be distributed over multiple servers?

Problem with Controller Servlet in WAS 4.0

Hello guys,
          I am working on WPS over WAS 4.0. I have an Enterprise application
          with a servlet which acts as a Traffic Controller. Its job is to
          intercept every http request to the Portal Server and make some
          changes to the URL and redirect/forward the changed URL to the Portal
          server. I plan to map the servlet to "/" so as all the requests are
          handled by this servlet. I hope it will work this way.
          So, the user clicks on a URL like http://server_name/meeting, the
          servlet sees a mapping table for /meetinf, constructs a new URL and
          redirects it. I read the /meeting as "pathInfo" variable from the
          request object. Please note that "/" is mapped to the servlet. This
          works fine. But if I give a JSP file instead
          (http://server_name/meeting/m.jsp), it starts looking for the JSP file
          in the Servlet WAR file. So the question is if there's any any other
          way of achieving this effect or is there any way to make all the .jsp
          file requests to go to this servlet instead of being searched in the
          WAR file?
          I would be grateful if someone can put their thoughts over this
          problem.
          Thanks
          Kapil.
          ([email protected])


Sorry to hear that.
As far as I know the campus topology is based on CDP info. And since you see all the links in the CDP tables, so should campus.
I've seen campus getting it wrong a few times, especially when there was some repatching done, but until now, when I delete the devices and re-add these devices, the next data collection gets the links correct.
Cheers,
Michel

Why controller Servlet instead of JSP?

Hi,
Could someone explain why do we go for Controller as Servlet instead of JSP?

Controller might have logic to redirect the page.
Generally we donot prefer scriptlets in JSP. SO
SO better option will be writing servlets.It might be possible to write that controller JSP without any scriptlet code if you use JSTL.
But the point that JSPs should be for presentation only stands. It's too easy to let control code start leaking into the JSP once you start.

Controller Servlet that Redirects to URLS

Dear Members,
I would like to do the following but I am not quite sure how to proceed.
I have a website that has several pages (not just *.jsp but also *.html). I would like to have a servlet controller to sit on top of the website, so that without altering the WebPages, to monitor for each user session, the URL visited.
In other words, say a user click on a link of one of the webpages. The controller should get the URL request, record it and then direct the user to where the link points.
I have tried the following but it does not work.
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
ServletContext application = getServletContext();
String reqUrl = getUrl(req);
String checkUrl = reqUrl.substring(reqUrl.length()-2);
if (checkUrl == ".jsp")
RequestDispatcher dispatcher = application.getRequestDispatcher("/Welcome.jsp"); //nextURL
dispatcher.forward(req,res);
else
res.sendRedirect(reqUrl);
res.setStatus(res.SC_MOVED_TEMPORARILY);
res.setHeader("Location", "reqUrl");
public static String getUrl(HttpServletRequest req) {
String reqUrl = req.getRequestURL().toString();
String queryString = req.getQueryString(); // d=789
if (queryString != null) {
reqUrl += "?"+queryString;
return reqUrl;
-----------------------------------------------------------------------------------

Sounds like you rather need a filter, read up on the javax.servlet.Filter interface.
You can map a filter to urls in your web.xml like this:
<filter>
<filter-name>TestFilter</filter-name>
<filter-class>test.TestFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>TestFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Protocol Router for Rich Client Front Controller

Hello,
I would like to support multiple client types in my J2EE application - Web Client and Rich Client (Swing Application).
Java BluePrints (Designing Enterprise Applications
with the J2EETM Platform, Second Edition) suggests using a Protocol Router for centralized control in case of supporting multiple client types with multiple controllers - http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html.
I have several doubts with this approach and will appreciate very much any help with clarifying the following:
1) How does a Rich Client communicate to Protocol Router? Using HTTP? That means then that each request/response has to be wrapped in HTTP Request/Response object. It may impact the performance and make the communication between Rich Client and back-end slower.
2) If rich client communicates with Protocol Router through HTTP, what is the difference between Fron Controller for Web Client and for Rich Client?
3) The J2EE Tutorial on the other hand, shows direct connection from Application (Rich) Client to EJB layer - http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Ebank.html.
It will be greatly appreciated to know how would you address the above doubts.
Best Regards.

1) How does a Rich Client communicate to Protocol
Router? Using HTTP? Yes, HTTP . You are right about performance issues. That protocol router seems to me like like overengineering. Anyway, I think a WEB service could be better choice. It's a standart way how to wrap remote requests in HTTP.
2) If rich client communicates with Protocol Router
through HTTP, what is the difference between Fron
Controller for Web Client and for Rich Client?I think the difference is in types of requests. WEB client would request
WEB pages, SWING client doesnt need WEB pages. It would request contents
of list boxes and things like that.
I would suggest you to use EJB's with session facade pattern. Provide WEB service style access to your app. Many app. servers provide feature to expose SLSB as WEB services. Thus you will support almost any types of clients (.NET, Perl, whatever). You can also use WEB service to connect from you'r SWING client. If later you are not satisfied with performance, you can switch to RMI. If you use BusinessDelegate pattern then you will need to change BusinessDelegate only, just one class.
I have written an example EJB based app. which can be accessed by SWING client using RMI or SOAP, WEB client, .NET client and CORBA.
You can get it from:
http://www.datapro.lv/~mariso/ejb.html
feel free to ask questions, if you have any
Maris Orbidans

Front Controller Servlet

Similar Messages

Maybe you are looking for