Skip to main content

Home/ SoftwareEngineering/ Group items tagged cdi

Rss Feed Group items tagged

kuni katsuya

Dependency Injection in Java EE 6: Conversations (Part 4) - 0 views

kuni katsuya

Transactional Interceptors (Linda DeMichiel's Blog) - 0 views

kuni katsuya

How To Deal With Interfaces In Java EE 6 (or no more Impl) : Adam Bien's Weblog - 0 views

  • How To Deal With Interfaces In Java EE 6 (or no more Impl)
  • In Java EE 6 interfaces became absolutely optional. Neither in EJB 3.1, nor CDI / JSR-330 you need interfaces. You can inject classes directly. They will be still proxied, so all aspects like persistence, transactions, interceptors, decorators are still available. So you are no more forced to implement interfaces by the container
  • used for: Strategy Pattern: there are already several implementations of an algorithm or concept Layering: there is a clear need to hide e.g. an ugly implementation of a legacy framework API (not very common): you have to expose a API, which gets implemented by SPI (e.g. JDBC)
  • ...4 more annotations...
  • If you introduce interfaces intentionally - and not as a general rule, you will considerably reduce the number of files. Your code becomes easier to understand and so maintain
  • Even for decoupling purposes, interfaces are no more needed
  • "Contract First", "Coding To Interfaces" or "Decoupling"
  • is not a reason to introduce an interface for everything
kuni katsuya

7. Tide Framework - Confluence - 0 views

  • GDS/Tide project represents the Data Services part of GDS
  • comparable to LiveCycle Data Services, which is neither open source nor free, as it provides similar features such as client container of managed entities, data paging, and integration with server components, but it is based on completely different principles:
  • strongly typed Hibernate/JPA detached objects
  • ...5 more annotations...
  • All managed entity instances are unique in a Tide context
  • Tide keeps the classic three layers web architecture, when LCDS removes the service layer, and is some kind of remote JPA provider for Flex applications
  • Tide approach is to minimize the amount of code needed to make things work between the client and the server
  • principles are very similar to the ones of JBoss Seam, which is the main reason why the first integration of Tide has been done with this framework. Integrations with Spring, EJB 3 and CDI are also available
  • need to compile your MXML/AS sources with the granite-essentials.swc and granite.swc libraries
kuni katsuya

JBoss Developer Framework - 0 views

  • migrating Spring Applications to Java EE 6 technology
  • rationale for migrating your applications from Spring to Java EE 6
  • examples of upgrading the web UI, replacing the data access layer, migrating AOP to CDI interceptors, migrating JMX, how to deal with JDBC templates
  • ...1 more annotation...
  • how to perform integration tests of you Java EE 6 application using Arquillian
kuni katsuya

2. Sample Projects - Confluence - 0 views

  •  
    EJB 3 Session Services
kuni katsuya

Getting Started Developing Applications Guide - JBoss AS 7.0 - Project Documentation Ed... - 0 views

  • Getting Started Developing Applications Guide
  • Installing and starting JBoss AS on Windows
  • Starting JBoss AS from Eclipse with JBoss Tools
  • ...1 more annotation...
  • CDI + JSF + EJB + JTA + Bean Validation + JAX-RS + Arquillian: Kitchensink quickstart
kuni katsuya

Comparison - 0 views

  • TomEE is a superset of OpenEJB
  • Tomcat
  • TomEE
  • ...5 more annotations...
  • TomEE+
  • OpenEJB
  • Java API for XML Web Services (JAX-WS) Java API for RESTful Web Services (JAX-RS) Java EE Connector Architecture Java Messaging Service (JMS)
  • Java Servlets Java ServerPages (JSP) Java ServerFaces (JSF) Java Transaction API (JTA)
  • Java Persistence API (JPA) Java Contexts and Dependency Injection (CDI) Java Authentication and Authorization Service (JAAS) Java Authorization Contract for Containers (JACC) JavaMail API Bean Validation Enterprise JavaBeans
kuni katsuya

InfoQ: Apache TomEE 1.0 Released - 0 views

kuni katsuya

Contexts and Dependency Injection for the Java EE Platform - The Java EE 6 Tutorial - 0 views

  • Contexts and Dependency Injection for the Java EE Platform
  • Contexts and Dependency Injection for the Java EE Platform
  • Contexts and Dependency Injection for the Java EE Platform
kuni katsuya

Selling Weld and EE6 | Weld | JBoss Community - 0 views

  • regarding the issue of selling Weld and EE6 to developers/shops....
  • How bout a JdbcTemplate Spring equivalent in the case of projects using legacy db schemas
  • portable extension to Weld
  • ...32 more annotations...
  • William Drai
  • Honestly I don't see any value in switching to CDI if it is
  • to reproduce the same awful patterns
  • please not this Dao/Template mess
  • Gavin King
  • Their template pattern is a solution in search of a problem
    • kuni katsuya
       
      gold! :)
  • to reproduce the same awful patterns
  • please not this Dao/Template mess
  • Because, of course, there are no other well-known patterns for dealing with boiler-plate cleanup code and connection leaks.
  • This is exactly the kind of
  • brain-damage that Spring does to people!
    • kuni katsuya
       
      platinum!!!
  • It gives people a
  • half-assed solution
  • and somehow shuts down their brains so they
  • stop asking themselves how this solution could be improved upon
  • It's a very impressive magic trick, and I wish I knew how to do it myself. But then, I'm just not like that. I'm always trying to poke holes in things - whether they were Invented Here or Not.
  • but that might be too high-level for your taste. Their are other, less-abstract options.
  • exception handling, this is one area where Spring does a good job: "The Spring Framework's handling of SQLException is one of its most useful features in terms of enabling easier JDBC development and maintenance. The Spring Framework provides JDBC support that abstracts SQLException and provides a DAO-friendly, unchecked exception hierarchy."
  • Utter nonsense and dishonest false advertising
  • Automatic connection closing (and other boiler-plate code) is obviously a hard requirement to be handled by the fwk.
  • Pffffff. It's a trivial requirement which I can solve in my framework with two lines of code in a @Disposes method. Did you see any connection handling in the code above?
  • I mean, seriously guys. The Spring stuff is trivial and not even very elegant. I guess it's easier for me to see that, since I spent half my career thinking about data access and designing data access APIs. But even so...
  • I don't understand. You hate the ability to write typesafw SQL that much?
  • Gavin King
  • Methods with long argument lists are a code smell.
  • It's something Spring copied from Hibernate 1.x, back in the days before varargs
  • It's something we removed in Hibernate2 and JPA.
  • there are a bunch of people
  • who don't want to use JPA.
  • They don't understand, or see the value of, using managed objects to represent their persistent data.
  • Um. Why? Why would that be a bad thing? I imagine that any app with 1000 queries has tens of thousands of classes already. What's the problem? Why is defining a class worse than writing a method?
  • Are you working from some totally bizarre metric where you measure code quality by number of classes?
« First ‹ Previous 101 - 116 of 116
Showing 20 items per page