In servlets for mapping I use #WebServlet("/path")
It means, that I can write in form's action "/path" and button click would be handled by my servlet.
In spring mvc I map controller's method as
#RequestMapping("/path")
It means, that I must write in form's action "/webAppName/path" and button click would be handled by my method. But if name of my war file will be change, I must been change mapping on html/jsp. I think it very bad.
Can You help me?
Firstly, you are absolutely wrong. Secondly, what you have mentioned as war file name, is actually context path which even remotely has no relationship with the war name.
Context path is used by the server to refer the webapp running on it. It can be possible that there are multiple applications deployed on your server so, for server to figure out which request is related to which web application context path is required.
The context path of the web application, which is matched against the beginning of each request URI to select the appropriate web application for processing. All of the context paths within a particular Host must be unique. If you specify a context path of an empty string (""), you are defining the default web application for this Host, which will process all requests not assigned to other Contexts.
The value of this field must not be set except when statically defining a Context in server.xml, as it will be inferred from the filenames used for either the .xml context file or the docBase.
And moreover, it has nothing to do with the architecture of the application weather it be Spring MVC or Java Dyanamic Web Application the same thing applies.
Related
According to the documentation for UseRouting(), we must call UseEndpoints() afterward:
A call to UseRouting(IApplicationBuilder) must be followed by a call to UseEndpoints(IApplicationBuilder, Action) for the same IApplicationBuilder instance.
But in some code samples (e.g. here) I see UseRouting() calls with UseEndpoints() omitted and MapRazorPages() used instead. Is this safe?
I entered this query into ChatGPT:
What is the difference between App.MapRazorPages and App.UseEndpoints(Sub(Routes) Routes.MapRazorPages)?
...and it returned this helpful answer:
App.MapRazorPages is a method that configures the routing for Razor pages in an ASP.NET Core application. It adds a default route for all Razor pages, which is {page}/{handler?}, where page is the name of the Razor page and handler is the name of an optional handler method defined within the page.
App.UseEndpoints is a method that enables you to specify a pipeline of middleware that will be executed when a request is received by the application. Within the lambda expression provided to UseEndpoints, you can call MapRazorPages to add a route for Razor pages to the pipeline.
So, in short, App.MapRazorPages is a specific method that configures routing for razor pages, while App.UseEndpoints is a more general method that allows you to specify a pipeline of middleware and register various types of endpoints, including razor pages, in the application.
All well and good. Very nice. But what about the admonition from the documentation, that we must call UseEndpoints() at some point after we call UseRouting()? Is it safe to rely on only a call to MapRazorPages() to fulfill that requirement?
This answer seems to indicate so, but I'd like to make sure before I go stringing things together that I don't fully understand.
---EDIT---
Well, go figure.
I consulted the almighty ChatGPT on this one (should've done that at first, I guess) and he boomed down:
No, it is not safe to rely on a call to MapRazorPages() as a substitute for the required call to UseEndpoints().
UseRouting() is used to enable routing in an ASP.NET Core application. It sets up the routing system and prepares the app to handle incoming requests.
MapRazorPages() is an extension method that can be used to configure Razor pages in an ASP.NET Core application. It adds a Razor pages endpoint to the application's endpoint routing table, which allows the app to handle requests for Razor pages.
UseEndpoints() is used to define the endpoints for an ASP.NET Core application. It adds a route to the application's endpoint routing table for each endpoint defined within the lambda passed to it.
So, while MapRazorPages() can be used to configure razor pages and add a corresponding endpoint to the application's endpoint routing table, it cannot be used as a substitute for UseEndpoints(). UseEndpoints() is required to properly define the endpoints for an ASP.NET Core application and handle incoming requests.
So there we have it. But should we trust it? I'm a little bit wary, perhaps because I tend to prefer to live on the edge and not allow myself to be lulled into complacency by The Matrix.
Can someone corroborate?
It differs in different .NET versions.
For example, in .NET 5, you have to call app.UseEndpoints() to register routing. However, in .NET 6 you can register routes with a call to app.MapRazorPage() directly, leaving out both app.UseRouting() and app.UseEndpoints(). This is documented here.
Apps typically don't need to call UseRouting or UseEndpoints. WebApplicationBuilder configures a middleware pipeline that wraps middleware added in Program.cs with UseRouting and UseEndpoints. However, apps can change the order in which UseRouting and UseEndpoints run by calling these methods explicitly.
I have an existing servlet and want to write some instructions to my log file on how to construct the URL needed to access my service . The basic logging service in J2EE is just fine for my purposes. The items I need are:
the canonical host name (got it)
the port number(s) for http connectors found in the server.xml file
the intermediate path to my servlet (servlet installation folder),
e.g. http://host:port/intermediate path/additional path
Using these three pieces of information I should be able to leave a breadcrumb of sorts in the log that tells administrators exactly how to configure my client-side app to access to this particular servlet instance.
Getting this information from within my implementation of HttpServlet.service() seems simple but I want to display the data during startup. Any thought on how to get it from within my implementation of HttpServlet.init()?
When our ASP.NET MVC 4 app starts, we need to set a property on a Log4Net Appender which depends on what the site is.
Is there a way to get the 'http://www.site.com' part some time in the sites initial load, perhaps in Global.asax?
Overview:
If the server is www.site2.com then set the Appender.SomeValue = "555"
If the server is www.site.com then set the Appender.SomeValue = "123"
Because many sites will point to the same code base we don't know what we need to set Appender.SomeValue to until it runs.
I think methods in Global.asax would run, only in response to a request. And almost everywhere inside the ASP.NET, you have access to HttpContext.Current.Request.Url.
Also there is a method that runs way before Application_Start, and that is a method decorated with PreApplicationStartMethodAttribute attribute.
One approach is to use WMI (Windows Management Instrumentation) to get access to the current website, it's bindings and thus the site address.
Pre-application start is more limited as it is run before the application is started, more for initializing di containers. To be safe I would put the code in a new static method defined in global.asax.cs that is called by application_start method at this point access to HttpContext.Current.request.Url should be safe
I have 1 Site (MySite.com) / 1 Web Service (WebService.MySite.Com) and one Common Library (LibCommon)
The common Library Contains a Model e.g. UserModel = LibCommon.UserModel
The web service has a method 'Void CheckUser(LibCommon.UserModel model)'
However when I add the 'WebService' reference to 'MySite.com' the method changes so that it looks like 'Void CheckUser(WebService.MySite.Com.UserModel model)'
So I think fair enough I can just cast one object to the other as they are identical however .NET Says I cannot do this?
Is there a work around for this?
Cheers,
Note this is for WCF, and not ASMX web services:
You can't directly cast the original data class to the proxied class generated by the WCF service reference wizard. However, you can reuse the original data class in the client:
Add the library reference containing the transfer objects (i.e. LibCommon) as a reference to both the Service (WebService) and the Client (Mysite.com). When adding the service reference on the client, choose the advanced tab and then select Reuse types in referenced assemblies. This will then reuse the common data transfer classes, instead of duplicating the types with proxies.
Note however that by eliminating the proxied data class, you are introducing direct coupling between client and server - you should do this only if you have control over both client and server w.r.t. version control issues etc (e.g. able to deploy new versions of both client and server simultaneously)
As an aside, it is also possible to eliminate the shared service interface as well, by moving the server side Service contract interface into a separate, common assembly and then using a technique such as this or this.
I'm having trouble figuring out how to access a cookie from a compiled object. I'm trying to make a compiled (DLL) object that will check the users cookie and then compare that to a database to confirm they have the correct access.
I can pass in the cookie info fine and the component will work, but I'm trying to have the component check the users cookie as well. I'm not even sure what object to use. I've been searching all weekend and I've seen references to httprequest, httpcookie, cookie, and cookiecollection.
I can look up cookie values on the page itself using Request.Cookies("inet")("user_id") but this doesn't work in the component.
Objects (App_Code/ compiled dlls) can only access Request via the static HttpContext.Current object
HttpCookie cookie = HttpContext.Current.Request.Cookies["CookieName"];
(If it's not called from a web app, HttpContext.Current is null, so you may want to check for that when running in unit testing)
(If this isn't App_Code, you'll need to reference System.Web)
If the component is a separate DLL from your web app you'd need to pass in a reference to the Request object.
That said why not just read/check the cookie value in your ASP.NET code before calling into your DLL. It's not such a good idea to have your business logic coupled to your web tier like this.