The cost effective way to develop web applications using Java.

Java Web Development

Objectives:

• User friendly environment that is similar to ASP.Net
• Low or no cost to develop and deploy
• Flexible deployment options
• Use standard and frameworks where possible
• MVC or other separation of presentation code from business logic. In short Multi-tier architecture

NetBeans 6.0 for IDE

• It supports deployment multiple Java Application servers
• Sun as all but decided that there will not be a next version of Java Studio Creator (pending out cry from community), and has pushed technology out to NetBeans 6.0
• Supports J2EE and Java 5 EE platform.
• JavaServer Faces built in gives an IDE and framework much like ASP.Net.
• Keeps pace with Java releases and technology changes
• Drag and Drop or code by hand developement
• FREE and OpenSource and Open Standards
• IDE and our applications are platform independent.
• Extensible IDE.

JavaServer Faces (JSF) for MVC and UI

• Is to be included in future J2EE standard.
• Can be used in same project as Struts (MVC defacto standard, but not an official standard)
• Component based framework that encourages reuse between applications

Hibernate for Persistence

jUnit or HttpUnit for testing

log4j or Java Logging API for Logging

Tiles for templating

ASP.Net and NetBeans JavaServer Faces (JSF) comparison from a .Net Developers perspective

Both have server controls (tags in JSF) that encapsulate and enhance standard html elements and form elements.

Code-behind == Backing bean (aka Managed Bean)

They both have code-behind. JSF calls it backing beans. The difference is that backing beans are just plain old java objects (POJO). This means that they are just regular classes. They don't have to inherit from any class or interface.

Another difference is that Code-behind and the .aspx files are linked together by a page directive in the .aspx. Visual Studio does this automatically for you unless you change it manually or rename a file. In JSF, this linking is done in the faces-config.xml.

Event Handler (in Code-behind) == Event Handler (in Backing bean)

Both provide event handler for user actions such as button clicks, selections, etc. Event handlers in ASP.Net always return void, but in JSF they return a string or null. Null means just navigate to the current page (a postback essentially). Any other value is is basically the name of an action that determines what navigation is taken. This is the same model as the new MVC that is being worked on in .Net currently. With JSF the class that handles the event needs to implement the ActionListener, ValueChangedListener, etc.

Postback vs. MVC

While Postback is a special case of MVC navigation as described above, JSF also allows for true MVC processing. This means that all page navigation is also done in one place. This is nice when you need to make navigation type changes. This means all requests come through a controller, and then the Model (data store) pulls the data, and the View (user interface) is rendered for that data. JSF has a powerful feature called RenderKit that allows the rendering to differ based on what medium is accessing the app. For example, if I access a page with my cell phone or computer I can get a different interface. The only change is the View, the Model and Controller stay the same. How cool is that!

ASP.Net Life Cycle vs. JSF Life Cycle

JSF has 6 lifecycle phases for a request. Restore View, Apply request values, Process validations, Update model values, Invoke the application, Render the response.

.ASPX vs. .JSF

In ASP.Net pages have the file extension and the url is also .aspx. In JSF the url is different from the file name. The filename ends in .jsp and the url has .jsf instead. By default, a knowledgeable user could access your pages with .jsp extension, but we really want all requests to go through the .jsf extension so we configure our application this way typically. However, there are exceptions to this. You can also configure your application to process .jsp pages that have a /faces/ before them in the url. The key here is that JSF allow you to define the convention for specifying which JSP pages are handled by the JSF servlet and which are not. BTW, not all .jsp pages are JSF pages, that is the reason for needing the difference.

Validation Summary == Message Group

In ASP.Net in general validation can handled by validators, and errors reported back to the user using Validation Summary. JSF, has similar items. However, in JSF, the messages are added to the FacesContext. This makes it easy to add custom validation logic back to the user also. The FacesContext shows up in the Message Group. This allows for validation to occur at the Business Logic Layer more easily.

ASP.Net Validator controls vs. JSF Standard Validators

JSF has similar validators like ASP.Net, but not as many, though you can create custom ones or just add validation code to backing bean. JSF includes DoubleRangeValidator, LengthValidator, and LongRangeValidator. ASP.Net in contrast has RequiredFieldValidator, RangeValidator, RegularExpressionValidator, CompareValidator, CutomValidator. The number of validators don't match, but much of the same validation checks can be performed on both platforms.

ASP.Net Form Data Conversion vs. JSF Converters

ASP.Net requires that you convert string form values to data types that the database (model) uses. For example, if you have a textfield that only accepts integers on a ASP.Net web form you need to get the text from the control, do data conversion to an appropriate type such as an int and then store it to the database, etc. In JSF, the same thing is needed, but it can be done using the UI using things called Converters. These converters can use number and date formats much like Excel to convert and format data. While, the effect is the same, the way that the conversion is done is different. There are converters for just about every datatype.

Change the nagging Restart Now or Later message

Have you ever been sitting at your PC and Windows XP prompts you with an annoying message indicating you need to reboot in order for an update to work? It asks if you want to restart Restart Now or Restart Later. You say later. It thinks later should be 10 minutes, you were probably thinking more like the next day.

A temporary fix (and stop all other automatic updates) until you reboot is to stop the Automatic Updates service.

A more permanent solution is to tell it to only remind you say once a day. Here is how to do that...

* In the Start Menu go to Run type gpedit.msc and press Enter * Now a Group Policy editor will open. In this window navigate to: Computer Configuration -> Administrative Template -> Windows Components -> Windows Update * Double click on No auto-restart for scheduled Automatic Updates installations * In the settings window Choose Enabled and click OK * Double click on Re-prompt for restart with scheduled installations * In the settings window Choose Enable and enter 1440 (1 day) and click OK * Close Group Policy Editor or if you prefer editing the registry directly...

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "RebootRelaunchTimeoutEnabled"=dword:00000001 "RebootRelaunchTimeout"=dword:00001440

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "NoAutoRebootWithLoggedOnUsers"=dword:00000001

My First experience with MS Integration Services (SSIS)

Working with Variables in SSIS (and other tidbits) Finding the Variable Window in the IDE Add a variable in SSIS is pretty easy. Locate your Variables window. It is most likely semi-hidden on one of the dockable areas in your IDE. To locate it, go to the View menu | Other Windows | Variables. If you don't see it there, that usually means that it is already somewhere on your screen. Just look for a tab called Variables. Adding a Variable In the Variable Window you will see an Add icon. When you click it it will add a variable that has the scope set to what you have clicked in your Control or Data Flow tabs. So, to add a global variable be sure you don't have any boxes clicked in either of those tabs, then click the Add icon. If you have any object clicked besides the background the scope will be set to that object and that is not a global variable. I recommend global variables to start with. I find them perfect for most cases. Once the variable is added, you will need to specify the Data Type property and the Value property. Using a Variable to store your SQL Query Add a variable of type String and set the Value to the SQL Query you want to use later. NOTE: You can use a Script Task to manipulate the SQL Query later if you want to. The trick seems to be in order for Data Flow objects to work ok, your variable needs to have a valid query to start with. This is how these objects know what columns need to be mapped, etc. So, you have to be careful what you do with the query variable. The query is not executed exactly, but the database is interrogated to find out the meta data about the columns being requested. So, you don't have to worry about a where clause initially if you are worried when you add the Data Source that it will bring back all rows just to find out the metadata. It appears to be much smarter than that. My guess is that it parses the select statement and determines what the table and column names are. Then it gets the metadata for those columns. Tell Data Source Editor what variable to use After dragging a Data Flow Source such as OLE DB Source on to your Data Flow tab, double-click the icon or border of the square to bring up the OLE DB Source Editor. Select "SQL command from variable" on the Data access mode drop down list. After that, there will then be a "Variable name" drop down list. Select the Variable you added under Adding a Variable section. Modifying the SQL Query Variable This step is optional and not always appropriate. In this example the where clause needs to be dynamic. To change the Value of the SQL Query Variable, you will need to add a Script Task to the Data Flow tab. Insert it into the flow somewhere before the Data Flow square that uses the variable. When you add the Script Task, open it up. You will see three navigation items on the left of the dialog. Click the Script item. Here you need to add any variables you want to use or modify in the script. If you are just reading the value of a variable, you can add it to the ReadOnlyVariables property. The syntax is User::MyVariableHere. If you will be modifying the value of a variable, you need to add it to the ReadWriteVariables. The syntax is the same. In either field you can add multiple variables. To do so just comma separate them. For example: User::MyVar1, User::MyVar2. To actually code you will need to use VB.Net. For those of you not familiar with it, don't be afraid it is very much like C# (at least as far as methods available). Click the Design Script... button to open the editor. To access a variable or set the value you use the following syntax. Dim myVar1 as String ' get value and store in local variable myVar1 = CType(Dts.Variables("MyVar1").Value, String) ' set new value Dts.Variables("MyVar1").Value = "some new value" Selecting a value from the database into a variable There may be times you want to select a column of a particular row in the database and store it in a variable that you define. This is done using the Execute SQL Task. After adding it to you the Control Flow tab, double-click the icon or the border of the square to open the Execute SQL Task Editor dialog. Make sure the following properties are set to the following: ResultSet: Single row (important) Connection: Any connection SQLSourceType: Direct input (assuming you will type it into the textfield in this dialog) SQLStatement: Type the SQL that will select one row and preferably with just one column selected. Now, in the same dialog, click the Result Set navigation item on the left of the dialog. Click the Add button. Enter two values: Result Name: This is the name of the column in the result of your query Variable Name: Choose the variable you want to store the value in. Now you can access it as we described earlier or in any other SSIS item that supports variables. Passing Parameters to SQL Task Sometimes you need to pass a parameter to an update statement, and insert statement or maybe a select statement. The SQL Task (and some other objects) support something called Parameter Mapping. What this does is map a variable you defined in SSIS package, and maps it to a SQL Parameter. The syntax of a parameter in your SQL statement depends on what your Connection Type is and what you are connecting to. Fore example, if you are using OLE DB you need to use ? to designate where a parameter should be. The name of the parameter is basically its zero-based index. For example: UPDATE MyTable set VAL1 = ?, VAL2 = ? In this example to set reference the parameter for VAL1 you would call it 0, and VAL2 would be 1. To map the SSIS variable to these parameters you must first define the variables in SSIS package (as noted above). Then open the SQL Task Editor. In the SQLStatement property type in your SQL (like the above example). Next, go to the Parameter Mapping tab by clicking the Parameter Mapping navigation item on the left pane in the SQL Task Editor. Click the Add button, and select the SSIS package variable, set Direction to Input, and Data Type to appropriate value, and the important part here is the Parameter Name is 0. Do the same for the second parameter, but the Parameter Name is 1. Useful System Variables System::StartTime - This is the local time that the package started running. Partial Debugging The most basic troubleshooting starts with finding where messages are logged. The short answer to that is the Output Window. If a step fails, check here to see why. If you have breakpoints at each point you want to stop when hitting F5 you can inspect variables you defined. While at a breakpoint, just go to the Locals Window and expand the Variables object. Here you see the variables you defined. The IDE supports debugging, but the Step Over (F10), Step Into (F11) don't seem to work. It says it can't step and when it does that you must restart debugging to do anything else. F5 to the next breakpoint seems to work fine though. Not the best debugging, but still better than nothing. You can right click on most any square in either Control Flow or Data Flow and choose Breakpoints to set a breakpoint on that square. I did notice that Step Over and Step Into DO work if you add a breakpoint in your Script Task lines of code. That is really nice! I strongly recommend using a try-catch around your script. The reason is that you must set the return code to failure. If you don't, the step in the package will just hang there indefinitely. Try 'do something here Dts.TaskResult = Dts.Results.Success Catch ex As Exception Dts.TaskResult = Dts.Results.Failure End Try Another helpful thing is that if you right click on an object you can Enable or Disable it. If it is disabled it will not execute. This is helpful if you dont' want all parts of your package to execute while you are developing or testing. References For more information on Execute SQL Task check out: http://www.sqlis.com/58.aspx For more information on using parameters with Execute SQL Task check out: http://msdn2.microsoft.com/en-us/library/ms141003.aspx