At work I have to regularly work on a site that uses Tomcat, Hybris and (I think?) Spring. Although I'm slowly learning, I'm quite unfamiliar with all of these technologies.
Is there a simple way to handle 301 redirects through Hybris? Perhaps through the Hybris administration console or Hybris management console?
Currently, we are using http://www.tuckey.org/urlrewrite/ and functionally, it works great. But adding a vanity URL or a URL redirect to the website involves editing / testing on localhost, then pushing urlrewrite.xml to stage and testing, then finally pushing urlrewrite.xml to the production environment.
Is there a better way to handle 301's with the technology we're using?
Hybris is built almost entirely upon the Spring framework. I'm not sure if the site you are maintaining uses the Accelerator template for the storefront, but if it is, then you'll want to look into Spring MVC. Look for methods that are annotated with #Controller. You can do just about anything you want with Spring MVC including 301 redirects.
There is no simple way to do this immediately in a nice configurable way in hybris. And frankly you would not want to. You should handle this in your web server.
But if you really want to, you should add a filter to the Accelerator storefront to check incoming requests against a list of items (perhaps RedirectURL Items) and redirect as required.
Could you explain exactly what you are trying to achieve ? I think like it has been said, in most cases redirection at the web server level would be more appropriate.
Related
I have a design question: I use DB + Hibernate + SpringBoot as back end in a server and use Swing clients on desktops.
I am considering for a new project the following architecture:
Back end (maybe in separate servers):
SQL DB
Spring Boot + Hibernate Java App
Front end(s):
Swing Java App
later: mobile App; Browser
I have searched a bit, but still have some doubts and feel I am missing something. I initially considered using React for front end. But this is going to take too long for me and I have lots of Swing components that I already optimized (and this my applications tend to use lots of grids with edits "in place")
I searched for Spring + Swing, but what I found was about running everything on the same JVM. I would think that separating them would allow me to (later) build a Mobile or Web front end using the same back end.
To sum it up:
create back end services with spring boot + hibernate on top of SQL db
create Swing front end that consumes those services
(later stage) mobile app to consume these same services
Questions:
Is this a good approach ? Am I seeing this the wrong way
How to "share" the POJOs between the back end and the front end? (thinking about placing the models on a separate lib); I don't mean how to transport them, I mean how to reuse them on both projects.
This is possible.
I would create the backend application with Spring Boot and access a datastore with Spring DATA. I would make services available via REST.
To access REST from your Swing client you must use a REST client of some sort. I would recommend Spring RestTemplate but there are many alternatives.
Synchronous client to perform HTTP requests, exposing a simple,
template method API over underlying HTTP client libraries such as the
JDK HttpURLConnection, Apache HttpComponents, and others.
Since you want mobile support some time in the future you could consider creating a webclient instead and making it cross platform (browser only).
To answer your two questions:
Regarding backend you will be perfectly fine as Spring Boot is a good option. As for the client I personally would not choose Swing today since it is very old and rather go for JavaFX 2 or a web client if that is an option. If you are the only developer and since you are proficient it might be a good solution for you.
You can share the POJOs from you Server for your Client as an api that you include as dependency. However it is usually not recommended to share POJOs but rather generate it on the client side or just type them. In your case if it is a small project it probably is ok. Do what is most easy for you.
I would recommend start using Maven as a build tool if you do not already.
Good luck.
Your request is perfectly valid, as you are a Swing developer and your approach is absolutely fine.
So let's draw the general picture: you're building a backend/frontend product/software.
Backend
Your backend will be a Spring application that will run on a server, let's say http://localhost:8080, serving requests to clients.
You'd probably want to create a #RestController on http://localhost:8080/api/... to expose your functions to your Swing client.
Swing client
Your client will be a Swing application running on your desktop.
To connect your client to the Spring application, you now need to implement a service in your Swing application that will call your Spring web server and fetch the resources from there.
To achieve this goal, may options exist:
Why not plain Java ? Use this tutorial to call your Spring services.
Http components from Apache are quite common.
Spring your app ! Spring API includes RestTemplate that you can use in your Swing app to call Spring backend and fetch resources for your desktop app.
As you can see, this is EXACTLY the same thing as with a website in React:
your web page is the JFrame
your JSX components in React would be your JPanels and components
you'd connect action listeners on components (JComboBox, JButton) to a service calling your Spring backend.
you'd then use the resources fetched from your Spring server to update your application state.
rince and repeat
So, be confident, your approach is correct. You'll find people ranting at you having chosen an obsolete techno but really, who cares?
(May I add, totally a pun, you've been smarter than the JavaFX guys which are now facing the segregation of javafx libraries from the core Java ;-))
And as always... happy coding !
I am having REST API with JPA and for login framework I am using Apache Shiro. Is it possible to integrate Apache Shiro with AngularJS and If YES Please give some example to workout with it.
Thanks
I know this is old, but if someone is looking for a solution still (as of Oct 2016) there is this. Requires some effort to integrate.
Thats a valid ques... in fact I am scoping this out now prototyping.
I wont get to it soon though I am tied up
create your login.html which is the view and to a home page
create your controller (angular style)
create your model (angular style)
write your java model
include shiro libs inside your maven project xml file
implement a shiro realm configuring such
implement a java security service which should be triggered by shiro onlogin
operate your doMethods for shiro within the service
allow room for java permission and role logic
build deploy...
DONE
wish I could give you more just haven't had a chance to grudge thru it. I will eventually though.
I am sure someone else will clean this up but shiro and angular I say are ok...
in fact all JAVA and Angular are perfect... nobody realizes http has been abused and misused for twenty years... (ok 15)... and REST puts the old days away for good.
here is your new architecture
Bootstrap,Angular,MVC JavaScript,REST,Hibernate JPA
BackBone is another alternative to Angular but its listener implementation is mandatory. Angular does more for you without need for listeners and is how HTMl would have been implemented if it were app centric when it was invented.
All these do is implement MVC and bury your ajax so your got a clean lookin html.
I've a java based web application running on Tomcat and it uses spring framework. I need to expose a ping URL to check whether the application is up and running. I've considered the following implementation approaches and all of them seems to work well when I tried them. However, I could not make up my mind whether one approach is better than another. Does it matter which path I take? Could someone advise which approach is better and why?
Create a web page and modify web.xml to redirect the url to the jsp page.
Create a REST service using Spring-WS
Create a servlet and return response
Use anything you want :-) But notice, that both Spring-WS and JSP are a little heavier (really not a meaningful reason here) than servlets. If you already have REST API to your aplication, use Spring-WS, if you render pages through JSP, use JSP. Or if you use none of these, write a plain servlet.
Since you are using Spring, assuming you use Spring MVC, you can just add another controller mapped to a certain URL which would be responsible for returning a status.
Solution 1 might not work depending on your requirement since a jsp page might work even if the rest of the app does not since it is not part of spring config.
I'm looking for a servlet filter library that helps me secure our web service against unauthorized usage and DDoS.
We have "authorized clients" for our web service, so ideally the filter would help detect clients that aren't authorized or behave improperly, or detect multiple people using the same account. Also we need a way to prevent DoS'ing of our various services since we have an open-account policy -- limiting the number of simultaneous connections for a user, etc.
We've looked at the Tomcat LockOutFilter and such but those are fairly primitive and only prevent against one sort of attack.
Of course there are many application-specific components of the solution, but I was wondering if someone had written up a general solution as a starting point.
Apache Shiro is an interesting security solution (it was called jSecurity before joining Apache.org). I find their source code much easier to understand and tweak for my needs, and also to integrate it.
iTransformers DDOS servlet filter is a good example for a servlet filter able to apply Remotely Triggered Black holing https://www.rfc-editor.org/rfc/rfc5635 which is the only real/good and scalable way to defend yourself from a DDOS attacks.
If you are using Spring then Acegi security is pretty complete.
Here is a series of tutorial articles.
It looks like you might be able to run this without needing Spring everywhere, See here.
Acegi has become Spring Security since this was posted.
Also looks like www.acegisecurity.org has been hacked.
I am working on a project where we'd like to pull content from one of our legacy applications, BUT, we'd like to avoid showing the "waiting for www.somehostname.com/someproduct/..." to the user.
We can easily add another domain that points to the same server, but we still have the problem of the someproduct context root in the url. Simply changing the context root is not an option since there are hundreds of hard coded bits in the legacy app that refer to the existing context root.
What I'd like to do is be able to send a request to a different context root (Say /foo/bar.do), and have it actually go to /someproduct/bar.do, (but without a redirect, so the browser still shows /foo/bar.do).
I've found a few URL rewriting options that do something similar, but so far they seem to all be restricted to catching/forwarding requests only to/from the same context root.
Is there any project out there that handles this type of thing? We are using weblogic 10.3 (on legacy app it is weblogic 8). Ideally we could host this as part of the new app, but if we had to, we could also add something to the old app.
Or, is there some completely different solution that would work better that we haven't though of?
Update: I should mention that we already originally suggested using apace with mod_rewrite or something similar, but management/hosting are giving the thumbs down to this solution. :/
Update 2 More information:
The places where the user is able to see the old url / context root have to do with pages/workflows that are loaded from the old app into an iframe in the new app.
So there is really nothing special about the communication between the two apps that client could see, it's plain old HTTPS handled by the browser.
I think you should be able to do this using a fairly simple custom servlet.
At a high level, you'd:
Map the servlet to a mapping like /foo/*
In the servlet's implementation, simply take the request's pathInfo, and use that to make a request to the legacy site (using HttpUrlConnection or the Apache Commons equivalent).
Pipe the response to the client (some processing may be necessary to handle the headers).
Why not front weblogic with Apache.
This is a very standard setup and will bring lots of other advantages also. URL rewriting in apache is extremely well supported and the documentation is excellent.
Don't be put off by the setup it's fairly simple and you can run apache on the same box if necessary.
Using Restlet would allow you to do this. The Redirector object can be used. See here and here for example.
If you instead serve out a JSP page you can use the tag to do the request server side.
Then the user will not even know that the resource was external.
http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html
a bit more context for the API the client is working against would help here to give a solution that could work. Are you trying to provide a complete new API totally different from the legacy Java EE app? What artifact is serving the API (Servlet, EJB, REST service)?
If you have the API provided by a different enterprise application then I suppose you simply use a Pojo class to work as a gateway to the legacy app wich of cause can then be reachable via another context root than the new service app. This solution would assume you know all legacy API methods and can map them to the calls for the new API.
For a generic solution where you don't have to worry about what methods are called. I am curious if the proxy approach could really work. Would the user credentials also be served correctly to the legacy system by URL re-writing? Would you have to switch to a different user for the legacy calls instead of using the origin caller? Is that possible with URL re-writing. Not sure if that could work in a secure context.
Maybe you can provide a bit more information here.