Skip to main content

Home/ SoftwareEngineering/ Group items tagged api

Rss Feed Group items tagged

kuni katsuya

Realm | Apache Shiro - 0 views

  • A Realm is a component that can access application-specific security data such as users, roles, and permissions. The Realm translates this application-specific data into a format that Shiro understands so Shiro can in turn provide a single easy-to-understand Subject programming API no matter how many data sources exist or how application-specific your data might be.
  • A Realm is essentially a security-specific DAO
kuni katsuya

Chapter 3. Project Setup - 0 views

  • The configuration of a GraniteDS project will generally involve the following steps : Add the GraniteDS jars to the WEB-INF/lib folder of the WAR file or the lib folder of the EAR file Add the GraniteDS listener, servlets and filters in the standard WEB-INF/web.xml configuration file Define the internal configuration of GraniteDS in the WEB-INF/granite/granite-config.xml file Define the application configuration of GraniteDS (remoting destinations, messaging topics...) in the WEB-INF/flex/services-config.xml
  • You will always need granite.jar
  • jar for your JPA provider (granite-hibernate.jar for Hibernate)
  • ...11 more annotations...
  • granite-beanvalidation.jar if you want to benefit from the integration with the Bean Validation API
  • configuration file declares 3 differents things
  • Channel endpoint
  • Service factories
  • Service/destinations
  • destinations using this factory will route incoming remote calls to EJB 3
  • endpoint
  • factory 
  • destination
  • channel 
  • factory
kuni katsuya

Chapter 10. Integration with CDI - 0 views

  • 10.3.5. Security GraniteDS provides a client-side component named identity that ensures the integration between the client RemoteObject credentials and the server-side container security. It additionally includes an easy-to-use API to define runtime authorization checks on the Flex UI.
  • CDI identity component (of class org.granite.tide.cdi.Identity) predictably provides two methods login() and logout()
  • identity component is integrated with server-side role-based security and can be used to get information or show/hide UI depending on the user access rights:
  • ...2 more annotations...
  •  enabled="{identity.hasRole('admin')}"
  • button labeled Delete will be enabled only if the user has the role admin
kuni katsuya

Security Module Drafts - Apache DeltaSpike - Apache Software Foundation - 0 views

  • Authorization
  • Impersonalization
    • kuni katsuya
       
      impersonation
  • authenticates “as a user” or access application imitating his identity - without knowing his password
  • ...36 more annotations...
  • elements of the user interface are displayed to the user based on the user's privilege level
  • assign permissions to individual objects within the application’s business domain
    • kuni katsuya
       
      individual objects == instances
  • Permissions
  • Permissions assigned to user for a given resource in the tree are inherited by other resources
  • Permissions are inherited
  • persist user, group and role information in database. JPA implementation is his dream
  • Security Module Drafts
  • Identity
  • interface Identity
  • login()
  • logout()
  • getUser()
  • Events LoggedInEvent LoginFailedEvent AlreadyLoggedInEvent PreLoggedOutEvent PostLoggedOutEvent PreAuthenticateEvent PostAuthenticateEvent
  • Object level permission
  • Grant or revoke permissions
  • Group management
  • User/Identity management
  • identity.hasRole
  • identity.hasPermission
  • Permissions model
  • Identity Management (IDM)
  • User, Group and Role
  • Events
  • hooks for common IDM or Security operations
  • Audit and logging for permission and IDM related changes
  • Event API.
  • Impersonalization
  • Impersonalization
  • control which elements of the user interface are displayed to the user based on their assigned permissions
  • ask for permission
  • without need to obtain object from DB
  • String resourceId
  • structure of resources
  • more advanced security resolution mechanisms
  • Rules based engine
  • external services - XACML
kuni katsuya

Chapter 4. Remoting and Serialization - 0 views

  • 4.3. Mapping Java and AS3 objects
  • data conversions are done during serialization/deserialization
  • Externalizers and AS3 Code Generation
  • ...21 more annotations...
  • Due to the limited capabilities of the ActionScript 3 reflection API than cannot access private fields, it is necessary to create an externalizable AS3 class (implementing flash.utils.IExternalizable and its corresponding externalizable Java class
  • writeExternal
  • In both classes you have to implement two methods
  • the Gas3 generator can automatically generate the writeExternal and readExternal methods.
  • With GraniteDS automated externalization and without any modification made to our bean, we may serialize all properties of the Person class, private or not
  • In order to externalize the Person.java entity bean, we must tell GraniteDS which classes we want to externalize with a
  • externalize all classes named com.myapp.entity.Person by using the org.granite.hibernate.HibernateExternalizer
  • you could use this declaration, but note that type in the example above is replaced by
  • instance-of:
  •             <include annotated-with="javax.persistence.Entity"/>             <include annotated-with="javax.persistence.MappedSuperclass"/>             <include annotated-with="javax.persistence.Embeddable"/>
  • : type
  • annotated-with
  • Instead of configuring externalizers with the above method, you may use the
  • feature:
  • precedence rules for these three configuration options:
  • <granite-config scan="true"/>
  • autoscan
  • GraniteDS will scan at startup all classes
  • found in the classloader of the GraniteConfig class, and discover all externalizers (classes that implements the GDS Externalizer interface)
  • DefaultExternalizer
  • this externalizer may be used with any POJO bean.
  •  
    4.3. Mapping Java and AS3 objects
kuni katsuya

Persistence - The Java EE 6 Tutorial - 0 views

kuni katsuya

JBoss AS 7 | Granite Data Services - 0 views

  • JBoss AS 7 with GDS 2.3
  • JBoss AS 7 is its deep integration with Hibernate 4 which makes very painful to deploy Hibernate 3.x applications
  • recommended to upgrade to H4
  • ...6 more annotations...
  • GraniteDS now fully supports Hibernate 4
  • use the granite-hibernate4.jar instead of granite-hibernate.jar
  • Flex 4.5 broke a few APIs and there were two main issues with Tide : The client libraries crashed when run in a mobile application The PagedQuery was unusable
  • These two issues are now fixed
  • granite-flex45.swc
  • Flex SDK 4.5 here
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?
kuni katsuya

Chapter 15. Data Management - 1 views

  •  abstractEntity.uid();
    • kuni katsuya
       
      sets the uid before persist
  •  UUID.randomUUID().toString();
  • AbstractEntity 
  • ...70 more annotations...
  • @MappedSuperclass
  • Important things on ID/UID
  • entity lives in three layers:
  • Flex client
  • JPA persistence context
  • database
  • When updating existing entities coming from the database
  • id is defined and is maintained in the three layers during the different serialization/persistence operations
  • when a new entity is being created in any of the two upper layers (Flex/JPA)
  • new entity has no id until it has been persisted to the database
  • most common solution is to
  • have a second persisted id, the uid
  • which is created by the client and persisted along with the entity
  • recommended approach to avoid any kind of subtle problems is to have a real uid property which will be persisted in the database but is not a primary key for efficiency concerns
  • You can now ask Tide to
  • limit the object graph before sending it
  • Flex with the following API :
  • EntityGraphUnintializer
  • uninitializeEntityGraph
  • Person object will be uninitialized
  • uperson contains
  • only the minimum of data
  • to correctly merge your changes in the server persistence context
  • Tide uses the
  • client data tracking
  • to determine which parts of the graph need to be sent
  • Calling the EntityGraphUninitializer manually is a bit tedious and ugly, so there is a cleaner possibility when you are using generated typesafe service proxies
  • annotate your service method arguments with @org.granite.tide.data.Lazy :
  • @Lazy
  • take care that you have added the [Lazy] annotation to your Flex metadata compilation configuration
  • in the Flex application, register the UninitializeArgumentPreprocessor component in Tide as follows :
  • [UninitializeArgumentPreprocessor]
  • all calls to PersonService.save() will
  • automatically use a properly uninitialized version
  • of the person argument.
  • 15.4. Dirty Checking and Conflict Handling
  • simplify the handling of data between Flex and Java EE
  • Chapter 15. Data Management
  • Tide maintains a client-side cache of entity instances and ensures that every instance is unique in the Flex client context
  •  uid().hashCode();
  • Tide currently only supports Integer or Long version fields, not timestamps and that the field must be nullable
  • in a multi-tier environment (@Version annotation)
  • highly recommended to use
  • JPA optimistic locking
  • highly recommended to add a
  • persistent uid field
  • AbstractEntity
  • in general this identifier will be
  • initialized from Flex
  • @Column(name="ENTITY_UID", unique=true, nullable=false, updatable=false, length=36)     private String uid;
  • @Version     private Integer version;
  • uid().equals(((AbstractEntity)o).uid())
  • consistent identifier through all application layers
  • @PrePersist
  • 15.3. Reverse Lazy Loading
  • 15.4. Dirty Checking and Conflict Handling
  • 15.4. Dirty Checking and Conflict Handling
  • 15.4. Dirty Checking and Conflict Handling
  • Dirty Checking and Conflict Handling
  • entity instance can be in two states :
  • Stable
  • Dirty
  • property meta_dirty is
  • bindable
  • could be used
  • to enable/disable a Save button
  • correct way of knowing if any object has been changed in the context, is to use the property meta_dirty of the Tide context
  • tideContext.meta_dirty
  • reliable when using optimistic locking
  • check that its @Version field has been incremented
« First ‹ Previous 101 - 110 of 110
Showing 20 items per page