Skip to main content

Home/ SoftwareEngineering/ Group items tagged api

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

Dependency Injection in Java EE 6 - Part 1 - 0 views

www.theserverside.com/...-Injection-in-Java-EE-6-Part-1

javaee6 DependencyInjection DI

shared by kuni katsuya on 13 Sep 12 - Cached
  • Dependency Injection in Java EE 6 - Part 1
  • high-level look at CDI, see how it fits with Java EE overall and discuss basic dependency management as well as scoping.
  • CDI is designed to solve
  • ...21 more annotations...
  • highly type-safe
  • consistent
  • portable
  • CDI enhances the Java EE programming model in two more important ways
  • allows you to use EJBs directly as JSF backing beans
  • CDI allows you to manage the scope, state, life-cycle and context for objects in a much more declarative fashion, rather than the programmatic way
  • CDI has no component model of its own
  • set of services that are consumed by Java EE components such as managed beans, Servlets and EJBs.
  • well-defined create/destroy life-cycle that you can get callbacks for via the @PostConstruct and @PreDestroy annotations.
  • Managed beans
  • @ManagedBean
  • annotation
  • CDI also integrates with JSF via EL bean name resolution
  • CDI does not directly support business component services such as transactions, security, remoting, messaging
  • Dependency Injection for Java
  • JSR 330
  • JSR 330 defines a minimalistic API for dependency injection solutions and is primarily geared towards non-Java EE environments.
  • Figure 1 shows how CDI fits with the major APIs in the Java EE platform.
  • none of this uses string names that can be mistyped and all the code is in Java and so is checked at compile time
  • Qualifiers
  • are additional pieces of meta-data that narrow down a particular class when more than one candidate for injection exists
kuni katsuya

Java EE 7 Roadmap (The Aquarium) - 0 views

blogs.oracle.com/...java_ee_7_roadmap

javaee javaee7 roadmap

shared by kuni katsuya on 14 Sep 12 - No Cached
  • Java EE 7 Roadmap
  • support for use in cloud environments
  • Web Sockets
  • ...19 more annotations...
  • JSON-P
  • we believe that providing solid support for standardized PaaS-based programming and multi-tenancy would delay the release of Java EE 7 until the spring of 2014
  • way too long
  • defer the remaining aspects of our agenda for PaaS enablement and multi-tenancy support to
  • Java EE 8
  • already laid some of the infrastructure for cloud support in Java EE 7
  • resource definition metadata
  • improved security configuration
  • JPA schema generation
  • Java EE 8 Platform release for the
  • spring of 2015
  • support for HTML 5 in the form of Web Sockets
  • JSON-P
  • simplified JMS 2.0 APIs
  • improved Managed Bean alignment, including
  • transactional interceptors
  • JAX-RS 2.0 client API
  • method-level validation
  • more comprehensive expression language
kuni katsuya

Java Persistence/Transactions - Wikibooks, open books for an open world - 0 views

en.wikibooks.org/...Transactions

jpa transactions

shared by kuni katsuya on 20 Jul 12 - No Cached
  • JTA transactions are
  • implicitly defined through SessionBean usage/methods. In a SessionBean normally each SessionBean method invocation defines a JTA transaction.
  • JTA Transactions
  • ...10 more annotations...
  • In JEE managed mode, such as an EntityManager injected into a SessionBean, the EntityManager reference, represents a new persistence context for each transaction. This means objects read in one transaction become detached after the end of the transaction, and should no longer be used, or need to be merged into the next transaction. In managed mode, you never create or close an EntityManager.
  • Transactions
  • operations that are committed or rolled back as a single unit
  • JPA provides two mechanisms for transactions
  • JTA (Java Transaction API
  • EntityTransaction
  • all changes made to all persistent objects in the persistence context are part of the transaction.
  • Nested Transactions
  • do not support nested transactions
  • JPA and JTA
kuni katsuya

Comparing JSF Beans, CDI Beans and EJBs | Andy Gibson - 0 views

www.andygibson.net/...g-jsf-beans-cdi-beans-and-ejbs

javaee6 ejb3.1 cdi JsfBackingBean

shared by kuni katsuya on 30 Jul 12 - No Cached
  • differences between CDI beans and EJBs is that EJBs are : Transactional Remote or local Able to passivate stateful beans freeing up resources Able to make use of timers Can be asynchronous
  • Stateless EJBs can be thought of as thread safe single-use beans that don’t maintain any state between two web requests
  • Stateful EJBs do hold state and can be created and sit around for as long as they are needed until they are disposed of
  • ...15 more annotations...
  • Stateless beans must have a dependent scope while a stateful session bean can have any scope. By default they are transactional, but you can use the transaction attribute annotation.
  • CDI beans can be injected into EJBs and EJBs can be injected into CDI beans
  • When to use which bean How do you know when to use which bean? Simple.
  • In general, you should use CDI beans unless you need the advanced functionality available in the EJBs such as transactional functions. You can write your own interceptor to make CDI beans transactional, but for now, its simpler to use an EJB until CDI gets transactional CDI beans which is just around the corner
  • Comparing JSF Beans, CDI Beans and EJBs
  • JSF Managed Beans
  • In short, don’t use them if you are developing for Java EE 6 and using CDI. They provide a simple mechanism for dependency injection and defining backing beans for web pages, but they are far less powerful than CDI beans.
  • JSF beans cannot be mixed with other kinds of beans without some kind of manual coding.
  • CDI Beans
  • includes a complete, comprehensive managed bean facility
  • interceptors, conversation scope, Events, type safe injection, decorators, stereotypes and producer methods
  • JSF-like features, you can define the scope of the CDI bean using one of the scopes defined in the javax.enterprise.context package (namely, request, conversation, session and application scopes). If you want to use the CDI bean from a JSF page, you can give it a name using the javax.inject.Named annotation
  • Comparing JSF Beans, CDI Beans and EJBs
  • Comparing JSF Beans, CDI Beans and EJBs
  • JSF Managed Beans
kuni katsuya

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

www.adam-bien.com/...how_to_deal_with_interfaces

CodingStandards

shared by kuni katsuya on 04 Aug 12 - No Cached
  • 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

Spring Security - Features - 0 views

static.springsource.org/...features.html

Java security SpringSecurity

shared by kuni katsuya on 09 Aug 12 - Cached
  • Domain object instance security: In many applications it's desirable to define Access Control Lists (ACLs) for individual domain object instances. We provide a comprehensive ACL package with features including integer bit masking, permission inheritance (including blocking), an optimized JDBC-backed ACL repository, caching and a pluggable, interface-driven design.
  • OpenID Support: the web's emerging single sign-on standard (supported by Google, IBM, Sun, Yahoo and others) is also supported in Spring Security
  • Easy integration with existing databases: Our implementations have been designed to make it easy to use your existing authentication schema and data (without modification). Of course, you can also provide your own Data Access Object if you wish. Password encoding: Of course, passwords in your authentication repository need not be in plain text. We support both SHA and MD5 encoding, and also pluggable "salt" providers to maximise password security.
  • ...5 more annotations...
  • Caching: Spring Security optionally integrates with Spring's Ehcache factory. This flexibility means your database (or other authentication repository) is not repeatedly queried for authentication information when using Spring Security with stateless applications.
  • Run-as replacement: The system fully supports temporarily replacing the authenticated principal for the duration of the web request or bean invocation. This enables you to build public-facing object tiers with different security configurations than your backend objects.
  • Tag library support: Your JSP files can use our taglib to ensure that protected content like links and messages are only displayed to users holding the appropriate granted authorities. The taglib also fully integrates with Spring Security's ACL services, and obtaining extra information about the logged-in principal.
  • User Provisioning APIs: Support for groups, hierarchical roles and a user management API, which all combine to reduce development time and significantly improve system administration.
  • Enterprise-wide single sign on using CAS 3: Spring Security integrates with JA-SIG's open source Central Authentication Service (CAS)
kuni katsuya

Interview of GraniteDS founders | RIAgora - 0 views

www.riagora.com/...nterview-of-graniteds-founders

graniteds blazeds comparison interview

shared by kuni katsuya on 06 Jun 12 - No Cached
  • explained the origin of GraniteDS and the differences with LiveCycle Data Services
  • ActionScript3 reflection API
  • GraniteDS 2.2
  • ...8 more annotations...
  • JSR-303 (“Bean Validation”) ActionScript3 framework for form validation
  • validation framework is a specific adaptation of the JSR-303 (Bean Validation) specification to Flex: like its Java counterpart, it relies on validation annotations placed on bean properties and provides an engine API that lets you validate your forms without writing by hand a specific validator for each of your input fields
  • code generation tools provided by GraniteDS so that when you write your Java entity bean with validation annotations, they are automatically replicated in your ActionScript3 beans
  • problem with LCDS is mainly that it promotes a strict “client / server” architecture, with – roughly speaking – a heavy Flex client application connected to a server almost reduced to a database frontend
  • big majority of  these organizations use BlazeDS, a free and open-source subset of LCDS
  • need more advanced mechanisms than just Remoting start looking for open-source libraries to enable deeper integrations with the Java business layer, and GraniteDS is for sure the most popular project
  • “Flex Data Services” (now renamed to “Live Cycle Data Services”)
  • Flex Data Services seemed too “client-centric”
kuni katsuya

Chapter 9. Integration with Seam 2.2 - 0 views

www.graniteds.org/...graniteds.seam2.html

graniteds seam2 integration

shared by kuni katsuya on 15 May 12 - No Cached
  • Integration with Seam 2.2
  • GraniteDS provides out-of-the-box integration with Seam 2.2 via either the RemoteObject API or the Tide API to remotely call Seam components, and fully supports serialization of JPA entities from and to your Flex application, taking care of lazily loaded associations
kuni katsuya

AllPermission (Apache Shiro 1.2.1 API) - 0 views

shiro.apache.org/...AllPermission.html

security ApacheShiro authorization AllPermission

shared by kuni katsuya on 23 Sep 12 - No Cached
  • AllPermission
  • always implies any other permission
    • kuni katsuya
      kuni katsuya on 23 Sep 12
       
      equivalent to *:*, ie. all actions on all resource types
  • implies method
  • ...2 more annotations...
  • always returns true
  • have the ability to do anything
kuni katsuya

Seam Cron Module - 0 views

docs.jboss.org/...html_single

Seam Seam3 Cron scheduling CdiExtensions

shared by kuni katsuya on 04 Dec 12 - No Cached
  • Seam Cron is a CDI portable extension for scheduled and asynchronous method invocation
  • It wraps common scheduling and backgrounding tasks in an intuitive, type-safe, event driven API
  • Seam Cron Module
kuni katsuya

The WebSocket API - 0 views

dev.w3.org/websockets

HTML5 WebSockets WebSocketsAPI specification

shared by kuni katsuya on 16 Mar 13 - No Cached
  • two-way communication with a remote host.
kuni katsuya

Quick Start · SpringSource/spring-social Wiki - 0 views

github.com/...Quick-Start

SocialNetwork SpringSocial tutorial

shared by kuni katsuya on 27 Mar 13 - No Cached
kuni katsuya

fernandezpablo85/scribe-java · GitHub - 0 views

github.com/...scribe-java

shared by kuni katsuya on 27 Mar 13 - No Cached
  • Configuring scribe
    • kuni katsuya
      kuni katsuya on 27 Mar 13
       
      fluent builder-style api
kuni katsuya

GraphicsMagick FAQ - 0 views

www.graphicsmagick.org/FAQ.html

graphicsmagick imagemagick

shared by kuni katsuya on 23 Apr 13 - No Cached
  • How does GraphicsMagick differ from ImageMagick?
  • How does GraphicsMagick differ from ImageMagick?
  • originally based on (forked from) ImageMagick 5.5.2 in November 2002
  • ...13 more annotations...
  • command-line syntax and programming APIs remain entirely upward compatible with ImageMagick 5.5.2
  • maintains a stable source repository with complete version history so that changes are controlled
  • maintains a detailed ChangeLog
  • maintains a stable release branch
  • ImageMagick does not offer any of these things
  • more time has been spent optimizing and debugging its code
  • dramatically fewer dependencies on external libraries
  • much smaller than ImageMagick
  • installation footprint is 3-5X smaller than ImageMagick
  • usually faster than ImageMagick
  • more efficient at dealing with large images
  • GraphicsMagick has been significantly updated to use multiple CPU cores to speed up the image processing
  • non-parallelizable code paths often dominating the time
« First ‹ Previous 41 - 60 of 110 Next › Last »
Showing 20▼ items per page