For a limited time during the Early Access period, MyEclipse for Spring is more than 50% off the regular price!

This means that MyEclipse Professional users can upgrade to MyEclipse for Spring for only about $39 per year. But, once MyEclipse for Spring hits production release status later this month, you’ll miss out on the savings, so contact the Genuitec subscriptions department now for details.

Want to see more? View this archived webinar of MyEclipse for Spring in action.

Bookmark and Share

A subtle, but powerful, side effect of having Spring generation capabilities with MyEclipse for Spring is the fact that creating Spring BlazeDS Flex apps is easier and faster than ever.

This blog post covers the basics to getting started with a spring-flex project in MyEclipse for Spring.  The spring-flex framework uses Adobe’s open source BlazeDS project, which is the remoting and messaging foundation for connecting a Flex-based front-end to Java back-end services.  MyEclipse for Spring accelerates the Spring development by providing bootstrapping, scaffolding, and visual editing capabilities for all the necessary Spring configuration files code to support a ready to run Spring MVC application.  The tutorial then goes on to tweak the MyEclipse for Spring generated configuration files to support Flex Remoting to produce a simple list view that calls the MyEclipse for Spring generated Spring service.

This blog is divided into 2 parts:

Part 1: Setup & CRUD
Part 2: Adding Spring Flex

Want to know more about MyEclipse for Spring? Watch the webinar where we introduced it.

Bookmark and Share

We recently answered several questions relating to Skyway’s feature to generate Spring Security 2.0 as well as general questions relating to Spring Security itself.  Here is a FAQ listing of those questions.  To learn more about Skyway’s Spring Security feature in Standard Edition, please take a look at the Security Feature Page.

  1. Before running Scaffolding > Scaffold spring security on the Spring DSL, Skyway requires that the user define a new Model package. Example video shows creating one named pkg.domain.security which Scaffolding then complements by creating a pkg.dao.security. Are there assumptions, limitations, or guidelines to where this domain.secuirty package should be placed (e.g. does the package have to be suffixed with security; does the dao package get created at the same level always)?
    Only assumption is if the package ends with “.domain”.  If so, Security Scaffolding places the DAO in a .dao package, and the Authorities and Users Domain Objects in the .domain package.
  2. After running Scaffold spring security will all newly added and domain objects have their Service and DAO objects added to Secured Resources when they have their CRUD scaffolded?
    Yes, new Services and DAOs will automatically be added to the Secured Resources.
  3. Skyway Project > Enterprise Configuration: What are the other Access values for Secured URLs and Secured Resources?
    Access can be used for Authentication and Authorization:
    Here are the 3 Authentication types:
    http://static.springsource.org/spring-security/site/docs/2.0.x/apidocs/org/springframework/security/vote/AuthenticatedVoter.htmlFor AUTHORIZATION, the Access string needs to be prefixed by “ROLE_” to indicate to  Spring Security that the Access is role based.  If the ROLE_  prefix is left off, deploy errors will occur. See example screenshot below.
  4. Skyway Project > Enterprise Configuration: How does the Secured URLs work in general? Is the default rule /secure/* allow pre-authentication for pages in this URL and then NO access for all others or is the no-access assumed for all other URLs?
    In the “/secure/*” scenario, all access to anything under the /secure/ path will require authentication.  Other URL paths do not require authentication.One note to consider is via the springSecurityFilterChain in the web.xml, all requests, specified by the url-pattern will go through Spring Security.  If a request is not intercepted by the login form, the user will be an anonymous user, and the security context will have something like the following:
    org.springframework.security.providers.anonymous.AnonymousAuthenticationToken@9611881d: Principal: roleAnonymous; Password: [PROTECTED]; Authenticated: true; Details: org.springframework.security.ui.WebAuthenticationDetails@fffd148a: RemoteIpAddress: 127.0.0.1; SessionId: 478A01F999A8CD50D40E069428B71306; Granted Authorities: ROLE_ANONYMOUS(Invalid property ‘principal.username’) Errors
    Due to the above paragraph, this error may appear with pages that have not been authenticated, but use the sitemesh decoration because the login.jsp uses <sec:authentication property=“principal.username”/> which does not exist when the security context authentication is authenticated with an anonymous user.

    If the desired behavior is to remove Spring Security entirely from certain requests, the springSecurityFileChain url-pattern should match the intercept-url pattern in the security context.

    A good way to see the security context is use the code in the login.jsp page to create a sample page that displays the entire “auth” variable.

  5. Skyway Project > Enterprise Configuration: Configured Views: The Skyway training video describes the out-of-the-box operation as using the spring provide screens for login challenge. Allowing these values to be blank. However there are several default generated pages in a Skyway project that seem to appropriate to wire in here. Can you provide details into what pages become obsolete when security is enabled and provide a general description of how the login URL navigation works? In essence walking through the URL navigation from index.html through the security scenarios would help.
    Security Flow(click to enlarge)

    Files involved in security:
    6. resources/[ProjectName]-generated-security-context.xml Central Spring Security config file. All configurations from the Spring DSL > Enterprise Configuration tab are emitted into this file.
    WebContent/secure/welcome.jsp Welcome page used after someone logs in. Used in the chain of Sign-in link (from login.jsp) to /spring_security_login to welcome.jsp
    WebContent/pages/logout-redirect.jsp Straight redirect to logout-success.jsp
    WebContent/pages/logout-success.jsp Static HTML page that states “You have successfully logged out of the system.”
    WebContent/WEB-INF/sitemesh-common/login.jsp Contains top “Sign-in” tab that changes based on if a user is authenticated.  Not authenticated: sign-in link that goes to the welcome.jsp.  Authenticated: Sign out link that goes to /j_spring_security_logout
    WebContent/WEB-INF/decorators.xml Two URLs are excluded: /j_spring_security_logout, and /pages/logout-redirect.jsp to prevent the sitemesh decoration framework from intercepting these URLs and adding the decorations to them.
    /spring_security_login Default URL path to sign in to Spring Security.  Displays the default Spring Security form.  This can be overridden via the Login View field in the Enterprise Configuration tab. (not an actual file in the project)
    /j_spring_security_logout Default URL path to logout/sign out of Spring Security. By Default this will go back to the /spring_security_login URL.  A logout success/error view can be added via the Enterprise Configuration > Configured Views fields. (not an actual file in the project)
  6. Skyway Project > Enterprise Configuration: Security Information Source: Is there ever a case where the Connection in this section does not match the User & Authorities DAO connection?
    Only if a different connection is required for authentication rather than just CRUD operations.
  7. Are there any required naming conventions for the authority names (e.g. ROLE_<name>)?
    The only recommendation is to avoid using the “ROLE_” prefix in the authority names.  Spring Security adds the “ROLE_ “, for internal purposes as explained in #3 above and #2 below.  For example, if the ROLE prefix is used, Spring Security will add another role prefix resulting in something like “ROLE_ROLE_ADMIN”
  8. How do you apply the authority rules to the application? Is there a standard convention, approach to using them?
    See Question #3 above for URL authorization.
    For view element authorization, e.g. displaying buttons on a page only to ADMIN users, use the spring security tag library.  E.g.

    <sec:authorize ifAllGranted="ROLE_ADMIN">
     <input type="button" value="Save">
</sec:authorize>
  9. Security: What would happen if you had /secure/* secured, but tried to access a Secure Service via /*?
    As noted in the Securing Applications – Authentication recipe, (http://www.skywayperspectives.org/documentation/6.3/chunk/recipes/ch02s30.html), the Service and DAO Secured Resources section controls external access to those services.  It is assumed that the developer secures the entry point in the Web Application via the URL.  For example, if one of your services is a web service (JAX-WS tab on the service), and you have the Service checked in the Secured Resources pane, you will see an entry in the list of the securedServiceEndPointNames element in the resources/jaxws/jaxws-web-context file.
  10. Why is the ROLE_ prefix emitted in the security config when DB is selected?
    From the Spring API docs: “If this is set to a non-empty value, then it is automatically prepended to any roles read in from the db. This may for example be used to add the ROLE_ prefix expected to exist in role names (by default) by some other Spring Security classes, in the case that the prefix is not already present in the db.” In other words, Spring Security expects the role to have “ROLE_” as a prefix, (like in the case for the intercept url authorization) so we generate this by default so developers can create any named role in the database without the need to prefix it with “ROLE_”.

Resources

Some good resources for Spring Security:

Bookmark and Share

During the MyEclipse for Spring webinar (replay is here), we received a lot of great questions from the webinar participants.  Although we attempted to respond directly to all of the questions raised during the webinar, unfortunately, we ran out of time and couldn’t respond to all of them.  In this blog post, I would like to address some of the questions that we didn’t get to answer and share some of the questions/answers that I think would be interesting to Spring developers.

Read the full list of questions and answers here.

Bookmark and Share

In case you missed it, the recording of our MyEclipse for Spring webinar is now available.  Hosted by Genuitec and Skyway, see the new MyEclipse for Spring product in action.  Find out how to get started with Spring, generate all of the architecture you need to get going, and then customize your projects — all in minutes, not days.

See what all the buzz is about here.

And, once you’re ready to give it a try, download Milestone 1, then let us know what you think.

Bookmark and Share

We at Skyway have a passionate goal to create a product that resolves all problems associated with code generators today and earlier generation code generators. We’re not afraid to bring these concerns out on the table, because we want all developers to realize the benefits that Skyway can bring to accelerating Spring development. So, we pride ourselves in removing the roadblocks associated with code generation.

To help discuss code generation issues and how Skyway resolves these issues, this blog focuses on the following code generation statements.  These statements comprise a summarized view of our own experience with other code generators as well as what we have heard in talking with folks about Skyway.  Don’t get me wrong, these statements do accurately describe some, if not most, code generators. Unfortunately, these code generators have influenced a mindset encompassing all generation frameworks.  Hence the reason for this blog; an answer to the code generation drawbacks with a product conceived, designed and built by developers.

In six general statements, here are the drawbacks with code generators:

Code Generators …

  1. … lock me down!
  2. … contain runtime proprietary components!
  3. … generate unreadable bad code!
  4. … don’t allow me to customize what’s generated!
  5. … have an added learning curve!

The following table presents a concise view of each perceived drawback, Skyway’s answer to these drawbacks and proof where you can see it for yourself.

Drawback Skyway Solution Proof
lock me down! The generated Eclipse Dynamic Web project is completely decoupled from the Skyway DSL project. A developer can completely ignore or throw away the Skyway visual DSL and continue to hand code the project if so desired. There are also various development approaches to blend hand coding and modeling.
  • Download the Skyway Hotels sample project and remove the SkywayHotels Spring Modeling project.
contain runtime proprietary components! Skyway has no proprietary runtime components. The deployed application is a standard Spring enabled Eclipse Dynamic Web Project. The application you build and deploy is 100% owned by you.
  • Download any sample project or follow any tutorial and inspect the web application.
  • Deploy it to a WAR and inspect the contents.
generate unreadable bad code! Springsource has crawled through Skyway’s generated code and configuration files and certified what is generated. Skyway also uses various Spring Recipes, and has leveraged our strategic partnerships and community feedback to continually improve the code that is generated.
don’t allow me to customize what’s generated! Skyway’s core generation framework is open source and built on the Eclipse plug-in framework providing many extensibility options. Skyway’s newest Project Templates feature also makes it very easy for developers to modify the templates used in code generation.
have an added learning curve! Skyway’s visual Spring DSL sticks to Spring concepts familiar with Spring developers. The visual DSL has also helped new developers to Spring accelerate their learning while not sacrificing project timelines.

If you are interested in learning more about Skyway, please take a look at our features or getting started page.

If you see something that is not listed, please comment on this blog or post a forum thread or JIRA.  Your feedback is more valuable than you think.

If after reading this blog, you still are not convinced, how about a live demo or conversation? Email sales@skywaysoftware.com

Or if you still have beef with Skyway’s Generation?  Why not share it to improve Skyway?

Bookmark and Share

Join us on January 28th for a webinar that will introduce you to the new “MyEclipse for Spring” product from Genuitec and Skyway Software.  Targeted for production release in Q1 of 2010, MyEclipse for Spring is a set of accelerators for Spring development.

Get started with Spring, generate all of the architecture you need to get going, and then customize your projects – all in minutes, not days.

What does that really look like? We will be covering the following technical topics and concepts:

* Spring MVC Scaffolding: Quickly generate Spring MVC CRUD applications from database tables, POJOs and JPA entities
* Spring Project Bootstrapping: Automatically create Spring configuration files and add Java libraries and web resources
* Enhanced Spring Development Editors: Simplified configuration of Services, Controllers and Spring Web Flow

The Webinar will run for approximately one hour and include a QA session following the technical presentation.

When: January 28, 2010 at 11am Central/Noon Eastern Time (UTC -6)
Where: https://www2.gotomeeting.com/register/356610891

Participants will be given the option to participate in a free, early-access program.

Want a sneak peak?  Check out this preview video:

Bookmark and Share

This blog post is the last post of a series of blog posts related to extending Skyway Builder to enable some code generation support for GWT.  In part one I gave an overview of the Skyway Builder extension in relation to GWT, and in part two I gave an overview of how Skyway Builder will be extended to support GWT development.  In part three I describe the actual implementation of the Spring DSL extension, and in this post I will describe how to download, install, and use the extension.

The GWT extension for Skyway Builder is implemented as an Eclipse plugin.  As such it needs to be installed as an Eclipse plugin.  In the future I may create an update site, but for now you can download the plugin (com.skyway.experimental.integration.gwt_1.0.0.jar) and copy it into the plugin folder for Eclipse.  Just as a reminder this plugin is dependent on having Eclipse 3.4.2 plus Skyway Builder 6.3 (Standard Edition).  If you don’t have Skyway Builder Standard Edition, you can get a copy from here.

When you restart Eclipe the GWT extension for Skyway Builder is ready to go.  For any Spring DSL Services or Components that you have defined in any projects, Skyway Builder will start generating slightly updated or new artifacts (see post two for details).

Here’s an important consideration.  This experimental plugin was designed to toggle the generation of GWT artifacts (using the Code Generation tab), and by default the generation is turned on.  This means that it will affect all Services.  If you have any existing projects that you don’t want to be affected by the GWT extension, you will need to disable the generation of the GWT artifacts by unchecking the GWT entries from the Code Generation tab of the Spring DSL.

A better solution is to add an attribute to the definition of the service that will allow me to specify the Service should be GWT enabled.  That’s exactly the approach taken by the DWR and JAX-WS features in Skyway Builder.  When you check “Publish DWR” or “Publish Web Service” checkboxes, the service will be generated accordingly.  Perhaps I’ll tackle that in a future version of the plugin.

Here’s an example of using the new plugins.  I followed the instructions from a previous blog post (GWT and Spring: Setup of development environment and Create GWT project).  The only difference is that this time I’m using GWT 2.0 instead of GWT 1.7, and I also added the spring4gwt library to my project.  Before I start doing any code generation with Skyway Builder, I want to quickly configure the Spring DSL to generate the correctly generate the new artifacts.

The Code Generation tab of the Spring DSL is used to define the code generation defaults for the project.  You will notice there are some new code generation entries that are contributed by the new plugin.  The first step is to disable “Service Interface” generation.  I recommend sorting the table by Categories in order to see all the Service entries grouped together.  The next step is to configure the “Service Interface“, “GWT Service Interface“, and “GWT Service Async” entries with a different package.  By default they are set to ${model.package}, which means that the artifact will be generated to a java package corresponding to the model package of the Service.  However for GWT we want the interfaces generated into their own package, so we are appending “.interfaces” to the end of the package.  I won’t go into all the details why this needs to be done for GWT, but suffice it to say that it’s a GWT best practice to isolate client-side and server-side Java code so that the GWT compiler will only compiling relevant Java code (source path) to javascript.

To see the GWT extension for Skyway Builder in operation, you can create Spring DSL services by hand or you can quickly scaffold a Spring MVC application.  For this blog post I scaffolded from a domain object.  See step 9 from GWT and Spring (Part 2) – Scaffold Spring back-end for GWT Application for a quick explanation on how to scaffold a Spring MVC application with Skyway Builder.

In my example you can see that the ContactService (in Spring DSL) generated the implementation class, service interface, and asynchronous callback interface (for GWT).  As you add new operations to the service, all the artifacts are regenerated to reflect the changes.

As far as events are concerned, you can just create a model package whose corresponding java package will be listed as a source path in GWT application, which will result in it being compiled into javascript.

This concludes my series.  My hope is that I provided an easy to understand introduction on how to extend Skyway Builder and an extension that may be usefull to GWT developers using Spring as their backend.  If you have any questions or would like me to elaborate on something, please drop me a comment here.

What’s next with this plugin? I’m glad you asked.  I would like to expand the support for GWT development in Skyway Builder.  I had started experimenting with some GWT UI scaffolding, and I’m making some good progress.  However given the new UI Binder feature in GWT 2.0, I will need to re-examine this.  If you have any ideas for enhanced GWT suppport, please let me know.

Happy New Year!!!

Bookmark and Share

This blog entry describes the steps necessary to take a Skyway CRUD Scaffold bootstrapped project and merge the one-to-one related objects into one form on the presentation layer for Create and Update operations as seen in the screenshot below.  The current default for Skyway CRUD Scaffolding with related objects is to place each object’s edit form on separate pages.  Skyway also does not assume related objects should be initialized in the java code.  So, the following steps provides options to enhance what is generated from Skyway to produce a master-detail merged form.

There are 2 options to accomplish this merge detailed in this tutorial:

  1. Modifying the generated code to use the parent/master object as the form backing object.
    [Quicker and involves hand-coding]
  2. Using a Skyway component as the form backing object.
    [Longer and all visual, no hand coding]

Project Setup and Scaffold

This section assumes you have Skyway Builder installed and understand Skyway’s CRUD Scaffolding feature.  For more details on these topics, please download Skyway Builder and run through the HOW TO: CRUD App Scaffolding tutorial.

  1. Create a new Skyway Project, name it CompanyAddressBook
  2. Create 3 Domain Objects (Contractor, Employee, Address) and their fields in Skyway. Fields don’t matter in this example, create any fields you like. Then create the relationships as shown here:
    Contractor 1-to-1 bidirectional to Address
    Employee 1- to-1 bidirectional to Address
  3. Scaffold both Contractor and Employee

OPTION 1: Modifying the generated code

In this option, the generated Domain Object code is modified to allow new instantiations of related objects so the Master Domain Object can be used as the form backing object.  This option is quicker than option 2, but you will need to manage the manual changes in the generated code. Another approach to this option is to create use the Skyway Template Project or Modifying Artifact Generation to modify the Data Type JET template.

  1. In the Contractor.java file, find the getAddress method and modify it to look like the following (additions in bold): 
    /**
*
* @generated NOT
*/
public Address getAddress() {
    if(address == null)
        address = new Address();
return address;
  2. In the Web Project > WebContent > WEB-INF > pages > contractor > address > editAddress.jsp:
    1. Copy the address table in the form and paste it in the pages > contractor > editContractor.jsp page.
    2. Remove the hidden field representing the contractor id.
    3. Merge the 2 tables together by removing the first table’s end tag and the second tables begin tag (</table><table>)
    4. Modify path attributes to contain the prefix of the address object (“address.“)

OPTION 2: Use a Skyway Component

In this option, a new Skyway Component is created consisting of the domain objects to serve as the form backing object for the JSP Master Detail form page.  This approach has more steps, but does not modify the generated Skyway code.

  1. Create a new Skyway Component named EmployeeAddress in the domain package.  Add both an employee and address variable of their respective types. For each variable’s initial value, type the new instantiation in the Initial Value field (e.g. new Address()).
  2. In the EmployeeController > NewEmployee operation:
    1. Remove the employee variable,
    2. Add an employeeAddress variable of type EmployeeAddress,
    3. In the output, remove the employee output variable, and add an output named employeeAddress tied to the employeeAddress variable.
  3. In the NewEmployee > defaultAction, change the Variable Assignment expression to be employeeAddress = new EmployeeAddressImpl();
  4. In the EmployeeController > EditEmployee operation:
    1. Add a variable named employeeAddress of type EmployeeAddress,
    2. In the output, remove the employee output variable, and add an output named employeeAddress tied to the employeeAddress variable.
  5. In the EditEmployee > defaultAction:
    1. Add a Variable Assignment step to the design canvas (make it a start step), and add the following expression: employeeAddress = new EmployeeAddressImpl();
    2. Set the output of the Named Query step to employeeAddress.employee
    3. Assign the Address to the employeeAddress Component by adding another Variable Expression step after the named query and using the following expression: employeeAddress.setAddress(employeeAddress.getEmployee().getAddress());
  6. In the EmployeeController > SaveEmployee operation, remove the employee input and add an input of the component type named employeeAddress. Click Save.
  7. In the SaveEmployee > defaultAction:
    1. Modify the Call Save Employee step, to use the following input: employeeAddress.getEmployee()
    2. Add another Invoke Operation step to call CompanyAddressBook.com.cab.web.EmployeeController.SaveEmployeeAddress, configure the Inputs and outputs.
  8. In the Web Project > WebContent > WEB-INF > pages > employee > address > editAddress.jsp:
    1. Copy the address table in the form and paste it in the pages > employee > editEmployee.jsp page.
    2. Remove the hidden field representing the employee id.
    3. Merge the 2 tables together by removing the first table’s end tag and the second tables begin tag (</table><table>)
    4. In the form tag, change the modelAttribute to employeeAddress
    5. Modify path attributes to contain the prefix of the object, either “employee.” or “address.“

Sample Project

- CompanyAddressBook [Eclipse Project Archive zip | 436KB]

Bookmark and Share

This blog post is the continuation of a series of blog posts related to extending Skyway Builder to enable some code generation support for GWT, including the automated  access of Spring @Services for GWT RPC.  In part one I gave an overview of the Skyway Builder extension in relation to GWT, and in part two I gave an overview of how Skyway Builder will be extended to support GWT development.  In this post I will describe the implementation of the Spring DSL extension in more detail.

If you don’t so much care how the GWT extension for Skyway Builder is implemented and just want to start using the extension, then you will probably just want to skip to part 4 where I will describe how to download, install, and use the extension.

Since the general steps for extending in Skyway Builder are already described on Modifying Artifact Generation in the Skyway Wiki, in the post I’m going to focus specifically on how these steps were applied to create the GWT extension.

Following the setup instructions, first of all I created a Jet Transformation project called com.skyway.experimental.integration.gwt.  I accepted all the defaults in the wizard.  Next I added required dependencies.

I’m going to use JET to implement my code generation templates.  JET templates resemble JSP in many ways, making it very easy to follow the implementation of the templates.  JET supports the concept of tags and tag libraries (just like JSP).  The JET tag library is very rich in generation functionality, but you can also use custom or 3rd party tag libraries (just like JSP).  Skyway Builder contributes a set of JET tag libraries for simplifying many of the recurring generation requirements of Spring applications.  A full reference of the Skyway JET tag library can be found here.  In regards to the GWT extension, the  Skyway JET tag library need to be added as extension.

The next step is to add the artifact definitions for the new artifacts that are going to be generated and register the template overrides for the pre-existing artifact definitions.

This diagram shows the extension entries required to accomplish the functions described in post 2, which includes:

  • adding a new Service artifact definition for the GWT callback interface
  • adding a new Service artifact definition for the service interface (the decision to create new artifact definition instead of overriding existing template will be described in part 4)
  • overriding the JET template for generating the web deployment descriptor (web.xml)
  • overriding the JET template for generating the Spring context file for the service layer
  • adding a new Component artifact definition for generated GWT events

I won’t review each JET template, but the the project contains five new templates.

Here’s a summary of each template:

  • generated-service-context.jet – This template is a copy of the base template and includes additional logic to direct Spring to do a component scan of all annotated Spring components.  By default the component scan is done from the web context file, but GWT front-ends talk will directly to the service layer (and bypass the web layer).  Therefore the component scan needs to be done from service layer, otherwise the dependencies of the Service layer won’t be resolved by Spring.
  • gwtEvent.jet – This new template generates a GWT event Java class from a Spring DSL component.  The component name is used as the event name, and the component variables are use for generating the event payload.
  • gwtServiceAsync.jet - This template is a new template that generates the GWT callback interface, which is a requirement for using GWT RPC.
  • gwtServiceInterface.jet - This template is a copy of the base template and includes additional logic to emit an @RemoteServiceRelativePath annotation for each service operation.
  • web.xml.jet – This template is a copy of the base template and includes additional logic to register the spring4gwt servlet and servlet mappings.

That’s it for the plugin.  The next step is to export the plugin (Export –> Deployable plug-ins and fragments).  The resulting plugin (jar file) can be installed into an Eclipse instance with Skyway Builder 6.3.  I’ll cover that in more detail in the next post (part four).

Bookmark and Share
« Older Entries