Monthly Archives: February 2016

How do I make a basic operating system?


I will tell you about my personal experience of writing a x86 64 bit OS from scratch.  Like many others who have answered, I took an OS class last semester.  You can find source code of my OS here: mysterious4 / SBUnix – Bitbucket

Programming OS is one of the most interesting and satisfying experience in terms of learning.

Get yourself familiar with qemu (x86 emulator), gdb (debugging), ctags (Navigating code), git (maintaining repo).

I hope you have sufficient knowledge of C, ASM, x-86 architecture, calling convention for x86 .

Firstly, I think you should really ask yourself what level of complexity you wish to have in your OS. Sketch out the rough design, components you wish to program etc. 

If learning OS concepts is your main aim, I would suggest start with an existing implementation; something like MIT – JOS. 6.828 / Fall 2011 / Overview
It will provide you with skeleton code for memory management, page table setup etc and then you would incrementally add support of various syscalls, interrupt handlers etc.
—————————————————————————————————————–
If you wish to go the hard way and program everything yourself, roll up your sleeves, its going to be exhaustive. I will enumerate steps for you:

Step 1. Writing your own bootloader: Use BOCHS which is a 32bit emulator. Read some theory about where BIOS is loaded, real modes, protected mode and then start implementing. This link might help you : Category:Babystep – OSDev Wiki

Step 2. Write small code for defining your kernel entry point where before calling main, you will setup your stack, GDT tables etc.

Step 3. Now you have task of writing ISR (interrupt service routines). Start from basic stuff. Set up your own GDT, IDT tables. Write your own printf by writing to video memory at 0xB8000. Refer this Printing To Screen 

Step  4. Writing code for PIC (programmable interrupt microcontroller). PIC tells processor what IRQ to call within our IDT (interrupt descriptor table) when interrupt is recieved from device. Refer this : Operating Systems Development Series. PIT (programmable interrupt timer) is your system clock. Write simple timer handler.

Step  5. Write simple device driver for your keyboard by mapping its scan codes. Write this into your keyboard interrupt handler.

Step 6. Now comes part of handling physical memory. Your BIOS e801 map will give you total main memory available. Further when you will come down to paging, it is going to request you physical pages of size 4 Kb. Divide memory into page size and have a bit-map/free list type physical memory manager which will keep track of occupied and free pages.

Step 7. Now arrives the mammoth task of programming virtual page tables. Start by reading first some theory that you won't usually find in OS books like one's which explain when to load cr3 register with physical addr of pml4 in case of 64-bit to enable paging, self referencing page tables etc. Map your kernel to higher memory address.
Write code for heap memory management, kernel malloc etc.

Step 8. Now comes part of process management. Define simple datastructres for your managing your processes – PCB, MM_struct, task_struct (required later on) etc. (refer linux 1.0). Now write procedure for loading simple kernel level process. Once you have this running, go on do define ring permissions and then user level processes.
Write simple round robin scheduler by keeping simple runqueue.

Step 9. Once you have processes running, now you have job of loading processes from memory. Define simple tarfs kind of in memory file system, then procedure for reading elf binary and loading it in your memory.

Step 10. If you want to proceed more, you have task of writing your own file system and later on you can go on to add support for network stack, multi threading etc.

some references for your reading:
1. Your bible – Expanded Main Page
2.
osdever.net
Bran's Kernel Development Tutorial: Getting Started
3. BrokenThorn Entertainment
4. 1.-Environment setup

Answer by Aniket Alshi:

I will tell you about my personal experience of writing a x86 64 bit OS from scratch.  Like many others who have answered, I took an OS class last semester.  You can find source code of my OS here: mysterious4 / SBUnix – Bitbucket

Programming OS is one of the most interesting and satisfying experience in terms of learning.

Get yourself familiar with qemu (x86 emulator), gdb (debugging), ctags (Navigating code), git (maintaining repo).

I hope you have sufficient knowledge of C, ASM, x-86 architecture, calling convention for x86 .

Firstly, I think you should really ask yourself what level of complexity you wish to have in your OS. Sketch out the rough design, components you wish to program etc. 

If learning OS concepts is your main aim, I would suggest start with an existing implementation; something like MIT – JOS. 6.828 / Fall 2011 / Overview
It will provide you with skeleton code for memory management, page table setup etc and then you would incrementally add support of various syscalls, interrupt handlers etc.
—————————————————————————————————————–
If you wish to go the hard way and program everything yourself, roll up your sleeves, its going to be exhaustive. I will enumerate steps for you:

Step 1. Writing your own bootloader: Use BOCHS which is a 32bit emulator. Read some theory about where BIOS is loaded, real modes, protected mode and then start implementing. This link might help you : Category:Babystep – OSDev Wiki

Step 2. Write small code for defining your kernel entry point where before calling main, you will setup your stack, GDT tables etc.

Step 3. Now you have task of writing ISR (interrupt service routines). Start from basic stuff. Set up your own GDT, IDT tables. Write your own printf by writing to video memory at 0xB8000. Refer this Printing To Screen 

Step  4. Writing code for PIC (programmable interrupt microcontroller). PIC tells processor what IRQ to call within our IDT (interrupt descriptor table) when interrupt is recieved from device. Refer this : Operating Systems Development Series. PIT (programmable interrupt timer) is your system clock. Write simple timer handler.

Step  5. Write simple device driver for your keyboard by mapping its scan codes. Write this into your keyboard interrupt handler.

Step 6. Now comes part of handling physical memory. Your BIOS e801 map will give you total main memory available. Further when you will come down to paging, it is going to request you physical pages of size 4 Kb. Divide memory into page size and have a bit-map/free list type physical memory manager which will keep track of occupied and free pages.

Step 7. Now arrives the mammoth task of programming virtual page tables. Start by reading first some theory that you won't usually find in OS books like one's which explain when to load cr3 register with physical addr of pml4 in case of 64-bit to enable paging, self referencing page tables etc. Map your kernel to higher memory address.
Write code for heap memory management, kernel malloc etc.

Step 8. Now comes part of process management. Define simple datastructres for your managing your processes – PCB, MM_struct, task_struct (required later on) etc. (refer linux 1.0). Now write procedure for loading simple kernel level process. Once you have this running, go on do define ring permissions and then user level processes.
Write simple round robin scheduler by keeping simple runqueue.

Step 9. Once you have processes running, now you have job of loading processes from memory. Define simple tarfs kind of in memory file system, then procedure for reading elf binary and loading it in your memory.

Step 10. If you want to proceed more, you have task of writing your own file system and later on you can go on to add support for network stack, multi threading etc.

some references for your reading:
1. Your bible – Expanded Main Page
2. Bran's Kernel Development Tutorial: Getting Started
3. BrokenThorn Entertainment
4. 1.-Environment setup

How do I make a basic operating system?

Leave a comment

Filed under Life

How can I make GUI Framework in C++?


A good start would be to learn an existing GUI framework. wxWidgets (Cross-Platform GUI Library) and Qt (Qt Project) are both cross-platform GUI frameworks that are worth learning from (of these two, wx is simpler but much less capable). The major operating systems also have their own proprietary frameworks. Windows has the Win32 API, the MFC API, and parts of .Net (plus some new thing for the tablets which I haven't played with yet). OS X has Cocoa. Linux has X-Windows, and a bunch of stuff that boils down to adding goop on top of X-Windows. I'm also a fan of Unity (Unity – Game Engine), which has a GUI library that is very simple (you just write a render method) and surprisingly expressive.

Next, you need to decide which layers you're interested in writing. Do you want to build your own graphics sub-system entirely from scratch? You might want to look into writing your own operating system. Do you want to use an existing graphics subsystem, and build your GUI on top of that? You should look into 2-d rendering libraries, like the native tools in your OS or something like SDL (Simple DirectMedia Layer – Homepage). You can also write a 2d or 3d GUI on top of an existing library, like OpenGL (NeHe Productions – Everything OpenGL) or DirectX (DirectX Software Development Kit). SDL or DirectX will also handle input from peripheral devices (mouse, keyboard, joystick, …) for you; if you're using OpenGL, you will need to find some other library to help with this. You might use glut (GLUT – The OpenGL Utility Toolkit), which is easy but a bit limited, or you might use SDL + OpenGL if you still want the 3d support.

Once you've got graphics and I/O, things are wide open. Will your GUI work as an event-pump, and your users write code by filling out event handlers? Qt is like this. Or will you leave the main execution loop in your user's hands, and your GUI is just a bunch of utility methods? Unity is like this. Or will you have the user implement both the event pump and the event handlers? The raw Win32 API works this way.

I could talk a little about the inheritance structure that's usually used for a GUI, but that's not the only way to do it. Read up on Qt if you want to see a beautiful implementation (or MFC if you want to see a hideous implementation). Really, I think you'll have more fun just by experimenting.

Answer by Adam Helps:

A good start would be to learn an existing GUI framework. wxWidgets (Cross-Platform GUI Library) and Qt (Qt Project) are both cross-platform GUI frameworks that are worth learning from (of these two, wx is simpler but much less capable). The major operating systems also have their own proprietary frameworks. Windows has the Win32 API, the MFC API, and parts of .Net (plus some new thing for the tablets which I haven't played with yet). OS X has Cocoa. Linux has X-Windows, and a bunch of stuff that boils down to adding goop on top of X-Windows. I'm also a fan of Unity (Unity – Game Engine), which has a GUI library that is very simple (you just write a render method) and surprisingly expressive.

Next, you need to decide which layers you're interested in writing. Do you want to build your own graphics sub-system entirely from scratch? You might want to look into writing your own operating system. Do you want to use an existing graphics subsystem, and build your GUI on top of that? You should look into 2-d rendering libraries, like the native tools in your OS or something like SDL (Simple DirectMedia Layer – Homepage). You can also write a 2d or 3d GUI on top of an existing library, like OpenGL (NeHe Productions – Everything OpenGL) or DirectX (DirectX Software Development Kit). SDL or DirectX will also handle input from peripheral devices (mouse, keyboard, joystick, …) for you; if you're using OpenGL, you will need to find some other library to help with this. You might use glut (GLUT – The OpenGL Utility Toolkit), which is easy but a bit limited, or you might use SDL + OpenGL if you still want the 3d support.

Once you've got graphics and I/O, things are wide open. Will your GUI work as an event-pump, and your users write code by filling out event handlers? Qt is like this. Or will you leave the main execution loop in your user's hands, and your GUI is just a bunch of utility methods? Unity is like this. Or will you have the user implement both the event pump and the event handlers? The raw Win32 API works this way.

I could talk a little about the inheritance structure that's usually used for a GUI, but that's not the only way to do it. Read up on Qt if you want to see a beautiful implementation (or MFC if you want to see a hideous implementation). Really, I think you'll have more fun just by experimenting.

How can I make GUI Framework in C++?

Leave a comment

Filed under Life

Which is the best library to implement GUI in C++?


There are several different ways to do this –
1. Platform specific – they work very well for the platform that they are tied to –
2.
1. MFC – feature rich, easy to bypass and go straight to the Win32 API when you need it. Only works on Windows.
2. Cocoa -again – extremely feature rich – only available / works on Mac

3. Cross Platform – these typically cover several platforms and they usually offer a subset of what each platform has.
4.
1. QT – the grand daddy of them all. It is a complete programming environment. Works on pretty much every single platform that you can think of.
2. wxWidgets – a more traditional desktop library. It is inspired to a certain extent by MFC – works on the Mac, Linux and Windows
3. JUCE – little light weight compared to QT. But code quality is excellent.
4. CEF (chromiumembedded / cef – Bitbucket ) – the Chromium Embedded Framework. It wraps the Chromium browser and offers it as a library. So you can write your app in HTML5/JS and just render it inside CEF. Pretty exciting – Evernote uses this, so does Avast. You can create really slick UIs in very little time! And the best part – it is trivial to integrate C++ and Javascript code.

So – if I were going to write a GUI today for desktops (Mac / Windows / Linux) – I would go for CEF. The look and feel can be way superior to any other native library, and I wont need to learn OpenGL / DirectX/ WPF etc to achieve stunning visual effects.
P.S. There are several other excellent libraries out there. I've just mentioned the ones that I am familiar with.

Answer by Raghupathy Srinivasan:

There are several different ways to do this –
  1. Platform specific – they work very well for the platform that they are tied to –
  1. MFC – feature rich, easy to bypass and go straight to the Win32 API when you need it. Only works on Windows.
  2. Cocoa -again – extremely feature rich – only available / works on Mac
  • Cross Platform – these typically cover several platforms and they usually offer a subset of what each platform has.
    1. QT – the grand daddy of them all. It is a complete programming environment. Works on pretty much every single platform that you can think of.
    2. wxWidgets – a more traditional desktop library. It is inspired to a certain extent by MFC – works on the Mac, Linux and Windows
    3. JUCE – little light weight compared to QT. But code quality is excellent.
    4. CEF (chromiumembedded / cef – Bitbucket ) – the Chromium Embedded Framework. It wraps the Chromium browser and offers it as a library. So you can write your app in HTML5/JS and just render it inside CEF. Pretty exciting – Evernote uses this, so does Avast. You can create really slick UIs in very little time! And the best part – it is trivial to integrate C++ and Javascript code.
    So – if I were going to write a GUI today for desktops (Mac / Windows / Linux) – I would go for CEF. The look and feel can be way superior to any other native library, and I wont need to learn OpenGL / DirectX/ WPF etc to achieve stunning visual effects.
    P.S. There are several other excellent libraries out there. I've just mentioned the ones that I am familiar with.

    Which is the best library to implement GUI in C++?

    Leave a comment

    Filed under Life

    How can I write my own GUI libraries and API in C and C++?


    At the very bottom of X is two types of drawables: pixmap and windows. These are just a series of bytes that represent the window. The other piece is the visual which determines how to interpret those bytes. Thought it might be rare to find now you might have a monochrome screen that can show only black and white. In that case general a single bit is used per pixel on screen. If this bit is on the pixel is white, if it is off the pixel is black. If the screen is 800×600 you need
    800 / (8 bits / 1 bpp) = 100 bytes per line * 600 lines = 60,000 bytes to represent the screen

    Now let's instead say you have a screen capable of showing 16 colors. Since you have 16 colts you need 4 bits for each pixel to choose the color for each pixel. Now youonly get 2 pixels per byte. An 800 x 600 screen is now

    800 / (8  / 4 bbp ) = 400 bytes per line * 600 ines = 240,000 bytes

    If you have a true color screen with 256 values for each of the three color components you end up with 3 bytes per pixel. The same 800×600 screen is now

    800 * 3 = 2,400 bytes per line * 600 lines 1,440,000 bytes to represent the screen.

    Generally that memory is viewed as a linear array of bits that represent the pixels. On the black and white screen if you want to draw horizontal line you need to determine which byte each bit falls in and turn it on using an assignment for full bytes and bit operations for bytes that aren't fully covered. For each of these visuals you will need to determine how to set the pixels for each primitive you want to create such as set_pixel, draw_line, draw_circle, etc.

    You'll also need all the X calls to create a window, get the visual the screen si using, get window size, handle events, etc. You'll find these in Xlib and XCB the X client libraries. That is the very bottom level if you want to you it all yourself and it will be a great long term project.

    There are other libraries you can use to do all the really low level work like create and managing windows and drawing lines and such. Fortunately the base X client library Xlib has graphic primitives for you like XFillRectangle(). But you can also go with GDK which will work with more underlying graphic device interfaces and allow easy porting to Mac, Windows, etc. Others will combine graphic primitives with some widgets like FTLK. If you're familiar with OpenGL you might choose to use the GLX extension will will let you handle display lists and be fairly portable while still remaining very low level. Though if you want the whole experience stick to the bits above then you can say it was all you (except for X — you can without that as well if you want and use the frame buffer directly though\now we're talking life long project).

    Answer by Mick Stute:

    At the very bottom of X is two types of drawables: pixmap and windows. These are just a series of bytes that represent the window. The other piece is the visual which determines how to interpret those bytes. Thought it might be rare to find now you might have a monochrome screen that can show only black and white. In that case general a single bit is used per pixel on screen. If this bit is on the pixel is white, if it is off the pixel is black. If the screen is 800×600 you need
    800 / (8 bits / 1 bpp) = 100 bytes per line * 600 lines = 60,000 bytes to represent the screen

    Now let's instead say you have a screen capable of showing 16 colors. Since you have 16 colts you need 4 bits for each pixel to choose the color for each pixel. Now youonly get 2 pixels per byte. An 800 x 600 screen is now

    800 / (8  / 4 bbp ) = 400 bytes per line * 600 ines = 240,000 bytes

    If you have a true color screen with 256 values for each of the three color components you end up with 3 bytes per pixel. The same 800×600 screen is now

    800 * 3 = 2,400 bytes per line * 600 lines 1,440,000 bytes to represent the screen.

    Generally that memory is viewed as a linear array of bits that represent the pixels. On the black and white screen if you want to draw horizontal line you need to determine which byte each bit falls in and turn it on using an assignment for full bytes and bit operations for bytes that aren't fully covered. For each of these visuals you will need to determine how to set the pixels for each primitive you want to create such as set_pixel, draw_line, draw_circle, etc.

    You'll also need all the X calls to create a window, get the visual the screen si using, get window size, handle events, etc. You'll find these in Xlib and XCB the X client libraries. That is the very bottom level if you want to you it all yourself and it will be a great long term project.

    There are other libraries you can use to do all the really low level work like create and managing windows and drawing lines and such. Fortunately the base X client library Xlib has graphic primitives for you like XFillRectangle(). But you can also go with GDK which will work with more underlying graphic device interfaces and allow easy porting to Mac, Windows, etc. Others will combine graphic primitives with some widgets like FTLK. If you're familiar with OpenGL you might choose to use the GLX extension will will let you handle display lists and be fairly portable while still remaining very low level. Though if you want the whole experience stick to the bits above then you can say it was all you (except for X — you can without that as well if you want and use the frame buffer directly though\now we're talking life long project).

    How can I write my own GUI libraries and API in C and C++?

    Leave a comment

    Filed under Life

    What is dependency injection in AngularJS?


    There is a general term "Inversion of Control" of which "Dependency Injection" is a sub-term. IoC means instead of taking away control flow to a new object when needed in decoupled objects, but to pass the alert or data to objects to perform the job or task on their own. You can delegate the control flow by callback delegates, observer pattern, events, DI (Dependency injection) and lot of other ways.

    DI provides objects that an object needs. So rather than the dependencies construct themselves they are injected by some external mean e.g. constructor injection, setter injection or method injection. Finally, Dependency injection is the practice of passing in the object’s collaborators (the code objects that our object depends on) into it, rather than creating them inside the object.

    AngularJS is said to be the most unit test friendly framework due to its modular nature. Even you can separate the big parts of your application to different modules. For example a Product_Module and a Auth_Module. Within those modules you can have repetitive tasks in services being used in controllers. There are also built-in services for some necessary operations like server-client communication and routing. Now using these services or modules where your code depends on those some methods of services is called Dependency Injection.

    Below is $http being injected to be used in an AngularJS Controller.

    1. function controller($http){
    2.           $http.get("/url").success(function(data)
    3.                                            {
    4.                                                  console.log(data);
    5.                                            }
    6.                                  );
    7. }

    Answer by Ahmad Ali:

    There is a general term "Inversion of Control" of which "Dependency Injection" is a sub-term. IoC means instead of taking away control flow to a new object when needed in decoupled objects, but to pass the alert or data to objects to perform the job or task on their own. You can delegate the control flow by callback delegates, observer pattern, events, DI (Dependency injection) and lot of other ways.

    DI provides objects that an object needs. So rather than the dependencies construct themselves they are injected by some external mean e.g. constructor injection, setter injection or method injection. Finally, Dependency injection is the practice of passing in the object’s collaborators (the code objects that our object depends on) into it, rather than creating them inside the object.

    AngularJS is said to be the most unit test friendly framework due to its modular nature. Even you can separate the big parts of your application to different modules. For example a Product_Module and a Auth_Module. Within those modules you can have repetitive tasks in services being used in controllers. There are also built-in services for some necessary operations like server-client communication and routing. Now using these services or modules where your code depends on those some methods of services is called Dependency Injection.

    Below is $http being injected to be used in an AngularJS Controller.

    function controller($http){
              $http.get("/url").success(function(data)
                                               {
                                                     console.log(data);
                                               }
                                     );
    }

    What is dependency injection in AngularJS?

    Leave a comment

    Filed under Life

    How does dependency injection work in Spring?


    Spring makes application loosely coupled using Dependency Injection. Dependency Injection is an implementation of the Inversion of Control principle. DI is the process of providing the dependencies.

    The core of the Spring Framework is Ioc container. The IoC container manages java objects from instantiation to destruction  through its BeanFactory. And the IoC container manages bean scope, lifecycle, and all AOP features for which it has been configured and coded.

    Dependency injection (DI) is a process whereby objects define their dependencies, that is, the other objects they work with, only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies on its own by using direct construction of classes, or the Service Locator pattern…

    Code is cleaner with the DI principle and decoupling is more effective when objects are provided with their dependencies. The object does not look up its dependencies, and does not know the location or class of the dependencies. As such, your classes become easier to test, in particular when the dependencies are on interfaces or abstract base classes, which allow for stub or mock implementations to be used in unit tests.

    There are three types of Dependency Injection employed by the IoC container.
     *
    1. Constructor-based Injection: The constructor arguments are injected during instance instantiation.
    2. Setter Injection: This is the most favored method of dependency injection in Spring. Dependencies are “set” in the objects through setter methods defined in a Spring XML-based configuration file or annotation.
    3. Interface Injection: using mapping items to inject to specific interfaces.

    The BeanFactory is the actual container which instantiates, configures, and manages a number of beans. A BeanFactory is represented by the interface org.springframework.beans.factory.BeanFactory, for which there are multiple implementations. The most commonly used simple BeanFactory implementation is org.springframework.beans.factory.xml.XmlBeanFactory.

    ApplicationContext is derived from BeanFactory to provide added functionality to work in web application. As the ApplicationContext includes all functionality of the BeanFactory, it is generally recommended that it be used in preference to the BeanFactory, except for a few limited situations such as in an Applet, where memory consumption might be critical and a few extra kilobytes might make a difference. 

    You can instantiate ApplicationContext using FileSystemXmlApplicationContext, ClassPathXmlApplicationContext , or WebXmlApplicationContext.

    Here’re an example code snippet using ClassPathXmlApplicationContext:

    > ApplicationContext context = new ClassPathXmlApplicationContext("/info/java/tips/config/spring-bean.xml");
    HelloBean hello = (HelloBean) context.getBean("hBean");
    System.out.println(hello.getMessage() + hello.getName());

    With the XML-base spring configuration file:

    > <bean id="refBean" class="java.lang.String">
    <constructor-arg value="Mike" />
    </bean>

    <bean id="hBean" class="info.java.tips.bean.HelloBean">
    <constructor-arg value="This is the message from Bean Constructor" />
    <property name="message" value="Hello " />

    <property name="name" ref="refBean"/>
    </bean>

    Answer by Hai Nguyen:

    Spring makes application loosely coupled using Dependency Injection. Dependency Injection is an implementation of the Inversion of Control principle. DI is the process of providing the dependencies.

    The core of the Spring Framework is Ioc container. The IoC container manages java objects from instantiation to destruction  through its BeanFactory. And the IoC container manages bean scope, lifecycle, and all AOP features for which it has been configured and coded.

    Dependency injection (DI) is a process whereby objects define their dependencies, that is, the other objects they work with, only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies on its own by using direct construction of classes, or the Service Locator pattern…

    Code is cleaner with the DI principle and decoupling is more effective when objects are provided with their dependencies. The object does not look up its dependencies, and does not know the location or class of the dependencies. As such, your classes become easier to test, in particular when the dependencies are on interfaces or abstract base classes, which allow for stub or mock implementations to be used in unit tests.

    There are three types of Dependency Injection employed by the IoC container.

      1. Constructor-based Injection: The constructor arguments are injected during instance instantiation.
      2. Setter Injection: This is the most favored method of dependency injection in Spring. Dependencies are “set” in the objects through setter methods defined in a Spring XML-based configuration file or annotation.
      3. Interface Injection: using mapping items to inject to specific interfaces.

    The BeanFactory is the actual container which instantiates, configures, and manages a number of beans. A BeanFactory is represented by the interface org.springframework.beans.factory.BeanFactory, for which there are multiple implementations. The most commonly used simple BeanFactory implementation is org.springframework.beans.factory.xml.XmlBeanFactory.

    ApplicationContext is derived from BeanFactory to provide added functionality to work in web application. As the ApplicationContext includes all functionality of the BeanFactory, it is generally recommended that it be used in preference to the BeanFactory, except for a few limited situations such as in an Applet, where memory consumption might be critical and a few extra kilobytes might make a difference. 

    You can instantiate ApplicationContext using FileSystemXmlApplicationContext, ClassPathXmlApplicationContext , or WebXmlApplicationContext.

    Here’re an example code snippet using ClassPathXmlApplicationContext:

    ApplicationContext context = new ClassPathXmlApplicationContext("/info/java/tips/config/spring-bean.xml");
    HelloBean hello = (HelloBean) context.getBean("hBean");
    System.out.println(hello.getMessage() + hello.getName());

    With the XML-base spring configuration file:

    <bean id="refBean" class="java.lang.String">
    <constructor-arg value="Mike" />
    </bean>

    <bean id="hBean" class="info.java.tips.bean.HelloBean">
    <constructor-arg value="This is the message from Bean Constructor" />
    <property name="message" value="Hello " />

    <property name="name" ref="refBean"/>
    </bean>

    Hope this helps!

    How does dependency injection work in Spring?

    Leave a comment

    Filed under Life

    Why is Google Guice so popular for Dependency Injection over Spring?


    Guice is simple, easy to use, lightweight and focused in DI.

    Spring is not only DI and became kind of heavy. If you are not using hibernate/jpa, quartz, AOP and many other tools that spring makes an easier use of (eg @Transactional), you might not need it.

    Say for example that you are using AppEngine, spring is not necessary and  using Guice or Pico can decrease your app start time by half.

    Answer by Bruno Fuster:

    Guice is simple, easy to use, lightweight and focused in DI.

    Spring is not only DI and became kind of heavy. If you are not using hibernate/jpa, quartz, AOP and many other tools that spring makes an easier use of (eg @Transactional), you might not need it.

    Say for example that you are using AppEngine, spring is not necessary and  using Guice or Pico can decrease your app start time by half.

    Why is Google Guice so popular for Dependency Injection over Spring?

    Leave a comment

    Filed under Life