Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
101 views

Spring Notes

Here are the key points about init and destroy method signatures: - The access modifier can be public, protected, or private. - The return type is typically void since there is no return value to capture, but any return type is allowed. - The method name can be anything. - The method cannot accept any arguments - it must be no-arg. So in summary, init and destroy methods defined in XML configuration can have any access modifier or return type, but must be no-arg methods. The method name can be anything as well.

Uploaded by

Raashid Shahab
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
101 views

Spring Notes

Here are the key points about init and destroy method signatures: - The access modifier can be public, protected, or private. - The return type is typically void since there is no return value to capture, but any return type is allowed. - The method name can be anything. - The method cannot accept any arguments - it must be no-arg. So in summary, init and destroy methods defined in XML configuration can have any access modifier or return type, but must be no-arg methods. The method name can be anything as well.

Uploaded by

Raashid Shahab
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Downloading the Source Code and PDF

Files
Download Source Code:
This only includes the source files, no JAR files. You will need to add JAR files
separately on your own. You have two options for downloading the code.

Option 1: Download zip file


File: spring-and-hibernate-for-beginners-master.zip

Option 2: Download using git command-line


You also have the option to download source code using git command-line.

git clone https://github.com/darbyluv2code/spring-and-hibernate-for-beginners.git

Note: Option 1 and Option 2 both has links to the exact same code. You only need
to choose one of the options.

---
Download PDF Files
All slides which are shown during the course are available also as a reference and
can be downloaded here:

http://www.luv2code.com/download-spring-hibernate-pdfs

---

Download FAQ Notes PDF Files


The course also includes a collection of FAQ Notes. These are available for
download as PDFs:

http://www.luv2code.com/download-spring-hibernate-faq-notes

FAQ: What is a Spring Bean?


FAQ: What is a Spring Bean?
A "Spring Bean" is simply a Java object.

When Java objects are created by the Spring Container, then Spring refers to them
as "Spring Beans".
Spring Beans are created from normal Java classes .... just like Java objects.

---

Here's a blurb from the Spring Reference Manual

Source: https://docs.spring.io/spring/docs/current/spring-framework-reference/
core.html#beans-introduction
---

In the early days, there was a term called "Java Beans". Spring Beans have a
similar concept but Spring Beans do not follow all of the rigorous requirements of
Java Beans.

---

In summary, whenever you see "Spring Bean", just think Java object. :-)

FAQ: Why do we specify the Coach


interface in getBean()?
Question
Why do we specify the Coach interface in getBean()?

For example:

Coach theCoach = context.getBean("myCoach", Coach.class);  


---

Answer
When we pass the interface to the method, behind the scenes Spring will cast the
object for you.

context.getBean("myCoach", Coach.class)   
However, there are some slight differences than normal casting.

From the Spring docs:


Behaves the same as getBean(String), but provides a measure of type safety by
throwing a BeanNotOfRequiredTypeException if the bean is not of the required
type. This means that ClassCastException can't be thrown on casting the result
correctly, as can happen with getBean(String).
Source:  http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/
springframework/beans/factory/BeanFactory.html#getBean-java.lang.String-
java.lang.Class-

FAQ: Why do we use CricketCoach


class instead of Coach Interface?
Question:
For the CricketCoach example with Setter Injection, why do we use the
CricketCoach class instead of the Coach interface?

Answer:
The getTeam() method is only defined in the CricketCoach class. It is not
part of the Coach interface.

As a result, you would need the following code:

     CricketCoach theCricketCoach = context.getBean("myCricketCoach",


CricketCoach.class);  
---

The Coach interface has two methods: getDailyWorkout and


getDailyFortune

The CricketCoach class has four methods: getDailyWorkout,


getDailyFortune, getTeam and setTeam

---

When you retrieve a bean from the Spring container using the Coach
interface:

     Coach theCricketCoach = context.getBean("myCricketCoach", Coach.class);  


You only have access to the methods defined in the Coach interface:
getDailyWorkout and getDailyFortune. Even though the actual
implementation has additional methods, you only have visibility to methods
that are defined at the Coach interface level.

---

When you retrieve a bean from the Spring container using the CricketCoach
class:

     CricketCoach theCricketCoach = context.getBean("myCricketCoach",


CricketCoach.class);  
You have access to the methods defined in the Coach interface:
getDailyWorkout and getDailyFortune.

ALSO, you have access to the additional methods defined in the


CricketCoach class: getTeam, setTeam.

---

The bottom line is it depends on how you retrieve the object and assign
it ... that determines the visibility you have to the methods.

Special Note: Defining init and


destroy methods - Method
Signatures
Special Note about init and destroy Method Signatures
When using XML configuration, I want to provide additional details
regarding the method signatures of the  init-method   and  destroy-method  .
Access modifier
The method can have any access modifier (public, protected, private)
Return type
The method can have any return type. However, "void' is most commonly
used. If you give a return type just note that you will not be able to capture
the return value. As a result, "void" is commonly used.
Method name
The method can have any method name.
Arguments
The method can not accept any arguments. The method should be no-arg.

You might also like