Is There A Constant Defined ? Also is there is a way to get the ApplicatioContext From HttpSession ?

[Joseph Sam]

Hi,

I'm having HttpSession and getting the servlet context from HttpSession

ServletContext context = request.getSession().getServletContext();
AnnotationConfigWebApplicationContext appCtx = (AnnotationConfigWebApplicationContext) context.getAttribute("org.springframework.web.servlet.FrameworkServlet.CONTEXT.dispatcher");
ConfigurableListableBeanFactory beanFactory = ((ConfigurableApplicationContext) appCtx ).getBeanFactory();
configurableListableBeanFactory.getBean(beanName)

Questions:
1. Is the above constant ("org.springframework.web.servlet.FrameworkServlet.CONTEXT.dispatcher") is defined anywhere so that we can avoid hard coding of the string?
2. Basically need to call and execute a method in a bean in doGet() or doPost() where the @autowire doesn't work in old Http Servlet classes
3. Is there is any alternate way to get the spring bean factory or get spring bean in http servlet class

Please advise

Thanks

[Tim Holloway]

If you're referring to the Spring ApplicationContext, no, I don't think it's a session object. If memory serves , you simply make an absolute class reference to it.

The reason being that not all Spring resources are accessed by app components that have access to the Request and/or Response objects and thereby also cannot get the HttpSession (nor indeed,, require an HTTPSession).

The "proper" place for such a thing might be Application Scope, but while I've never heard a formal discussion, there are a lot of things in webapps that are of"application scope"  while not literally being named as objects in Application Scope. A rough rule, I supposed would be where you'd want to have a plug-replaceable global object (looked up by name) over an absolutely-named object or class resource.

[Joseph Sam]

Yes, i am referring to spring application context. Is it going to be a problem with memory in accessing the app context and getting a bean? Why memory is going to be affected due to this operation?

Can you please clarify Tim?

[Tim Holloway]

Mostly you shouldn't need to actually obtain the ApplicationContext to manually obtain beans because Spring would be injecting them automatically.

In cases where you do need a BeanFactory, I think you can find a class method on your ApplicationContext (or maybe it's "WebApplicationContext" - I forget).

[Joseph Sam]

@Tim, are you saying a simpler way to get or obtain the application context then the below code snippet which i have pasted initial

ServletContext context = request.getSession().getServletContext();
AnnotationConfigWebApplicationContext appCtx = (AnnotationConfigWebApplicationContext) context.getAttribute("org.springframework.web.servlet.FrameworkServlet.CONTEXT.dispatcher");
ConfigurableListableBeanFactory beanFactory = ((ConfigurableApplicationContext) appCtx ).getBeanFactory();
configurableListableBeanFactory.getBean(beanName)

[Stephan van Hulst]

No, Tim is saying that you don't need to obtain the application context just to get a bean. You can just inject the bean wherever you need it without fiddling with the application context.

[Joseph Sam]

Stephan/Tim,

How to inject the bean as @Autowired doesn't work. If we create with new operator and autowired beans inside the class won't work again.

Please advise.

[Tim Holloway]

@Autowired works when you have defined a bean class whose name matches the name of the property you are trying to wire into AND if the bean being wired is defined in a package which Spring has been told to scan for manageable beans.

So you'd need something like this:

class InjectedBean {
…
}

class TargetBean {
   @Autowired
  public InjectedBean injectedBean;
}

[Joseph Sam]

Tim, the spring bean which has been declared as @Autowired doesn't work in the servlet class which i have written. Generally the @Autowired works but in this case it returns null. So i used to find a way to get the application context and get the bean via application context

Please correct me where i am going wrong.

[Tim Holloway]

No, it wouldn't. Because Spring doesn't manage the Servlet instance, the Servlet Container does and it instantiates the servlet before Spring has even started up. Maybe CDI could deal with that, but CDI and Spring often don't play well together.

Offhand, I cannot think of a "proper" way to do this, as given. In most cases, there's a dispatcher servlet like the JavaServerfaces FacesServlet or the Spring Web dispatcher servlet, and they hand off to an injectable business logic bean. I've not done this brute-force on a servlet.

[Joseph Sam]

Thanks for the reply Tim. But the below code works...Do you see anything danger or risk at the below approach ???

ServletContext context = request.getSession().getServletContext();
AnnotationConfigWebApplicationContext appCtx = (AnnotationConfigWebApplicationContext) context.getAttribute("org.springframework.web.servlet.FrameworkServlet.CONTEXT.dispatcher");
ConfigurableListableBeanFactory beanFactory = ((ConfigurableApplicationContext) appCtx ).getBeanFactory();
configurableListableBeanFactory.getBean(beanName)

[Stephan van Hulst]

Why are you using a custom servlet class?

[Joseph Sam]

Because few people doesn't support json request or response

[Tim Holloway]

1. In answer to question:

No, I don't see anything "dangerous" in it, but I'm almost certain that if you really needed to do that that there is a simpler/cleaner way to do so.

Also, it's worth considering that the preferred way of dealing with Service Lookup of beans is to make the beans be JEE session, request, or application scope objects and use the JEE APIs

2. You definitely shouldn't need a custom servlet to deal with JSON. I believe that there are at least 2 well-supported JSON frameworks for JEE.

[Joseph Sam]

Hi Tim,

Yes, I'm hardly/really needed to do that...Can you help me some little code snippet or idea about the simpler/cleaner way you are suggesting. Please advise.

Thanks

[Tim Holloway]

May I suggest you investigate this: https://spring.io/blog/2014/12/02/latest-jackson-integration-improvements-in-spring ?

[Joseph Sam]

Tim, the jackson is already implemented. It's a mixed approach so trying to solve for servlet. servlet is needed. is there is anyway to finetune the code which i have written?

[Tim Holloway]

As I said, I think so. But to find out I'd have to dig into the Spring docs and Google stuff and I don't get paid for this. There's nothing out there that you couldn't find.

More concerning is the impression we've gotten that you've created a servlet that's full of application code. The technical term for that is "monster".

Well-written servlets do very little work themselves, but instead offload onto logic beans that can be tested offline using frameworks like JUnit. And that, incidentally is what the Spring-Jackson stuff is about. It uses the Spring dispatcher servlet to invoke Jackson using your annotated entity mappings, presenting the digested JSON as a POJO bean network to the business logic bean.

My speciality is JSF and about the only time I've used a raw servlet in the past decade was to generate a PDF using a session object(s) for source data. Pretty much everything else that JSF can't handle was done by Spring Web.

[Joseph Sam]

Tim, How about this - https://stackoverflow.com/questions/18745770/spring-injection-into-servlet ?

[Joseph Sam]

Tim/Stephan,

Which one is the right way to go out of this?

1. https://stackoverflow.com/questions/18745770/spring-injection-into-servlet
2. https://stackoverflow.com/questions/43654488/spring-boot-inject-bean-into-httpservlet?noredirect=1&lq=1
3. https://stackoverflow.com/questions/47434743/ensure-spring-bean-loaded-from-non-spring-context?noredirect=1&lq=1
4. https://stackoverflow.com/questions/23839226/autowire-null-inside-a-servlet

[Tim Holloway]

Those are all pretty icky, plus one is specific to Spring Boot, which already has ideas on dispatcher servlets.

I really think you may be deep into the Sunk Cost Fallacy here.

The sad thing is that the solution that looked the cleanest apparently has a fatal flaw, as the problem was ultimately marked as unresolved.

[Stephan van Hulst]

Again, I really don't understand why you need custom servlet code at all. What are you doing in the servlet that you can't do in controller classes?

[Stephan van Hulst]

Right, so it appears that your requirement is (sort of) explained in this topic: https://coderanch.com/t/754710/java/Servlet-API-REST

Like I said in that topic, you don't need a custom servlet to do what you want. You just need to write your normal REST API, and then add one or more endpoints that transform the in- and outputs a little bit.

[Joseph Sam]

@Stephan Van Hulst - what you have said is absolutely right. But it is not possible as it is legacy system and major changes are not allowed. So the conclusion is...Please kindly confirm

We can able to retrieve the spring application context via the following..

We need to pick one solution among the below ones

1)

ServletContext context = request.getSession().getServletContext();
AnnotationConfigWebApplicationContext appCtx = (AnnotationConfigWebApplicationContext) context.getAttribute("org.springframework.web.servlet.FrameworkServlet.CONTEXT.dispatcher");
ConfigurableListableBeanFactory beanFactory = ((ConfigurableApplicationContext) appCtx ).getBeanFactory();
configurableListableBeanFactory.getBean(beanName)

2) https://stackoverflow.com/questions/18745770/spring-injection-into-servlet

3) https://stackoverflow.com/questions/43654488/spring-boot-inject-bean-into-httpservlet?noredirect=1&lq=1

4) https://stackoverflow.com/questions/47434743/ensure-spring-bean-loaded-from-non-spring-context?noredirect=1&lq=1

5)https://stackoverflow.com/questions/23839226/autowire-null-inside-a-servlet

[Rob Spoor]

Joseph Sam wrote:ServletContext context = request.getSession().getServletContext();

Why do you call getSession(), which will create a session if there isn't one yet, when you can simply use request.getServletContext()? That's been available since version 3.0 of the Servlet API. You must be using a really old container if you're still not able to use that.

[Stephan van Hulst]

I don't think I'm ready to suggest you any option, without knowing why you're trying to inject a Spring managed bean into a custom servlet. It's just a bad idea. Once you do this, over time your entire application will devolve into one big unmaintainable mess.

[Tim Holloway]

It strikes me that attempting to ram in Spring into a custom servlet is already exceeding the limits of what a shop would normally allow for modification of a "legacy application".

"Legacy application" in my experience often means "it's so old it's beginning to break down, but we're too cheap to budget enough to bring it up to date properly." That's a big red flag and would have me updating my CV.