Skip to main content

Home/ SoftwareEngineering/ Group items tagged compatibility

Rss Feed Group items tagged

kuni katsuya

Java EE Compatibility - 0 views

kuni katsuya

GraphicsMagick FAQ - 0 views

  • 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
kuni katsuya

Session Management | Apache Shiro - 0 views

  • available in any application,
  • regardless of container.
  • even if you deploy your application in a Servlet or EJB container, there are still compelling reasons to use Shiro's Session support instead of the container's
  • ...40 more annotations...
  • Easy Custom Session Storage
  • POJO/J2SE based (IoC friendly)
  • Container-Independent Clustering!
  • Heterogeneous Client Access
  • Event Listeners
  • listen to lifecycle events during a session's lifetime
  • Host Address Retention
  • retain the IP address or host name of the host from where the session was initiated
  • Inactivity/Expiration Support
  • can be prolonged via a touch() method to keep them 'alive' if desired
  • Transparent Web Use
  • can use Shiro sessions in existing web applications and you
  • don't need to change any of your existing web cod
  • Can be used for SSO
  • easily stored in any data source
  • can be
  • 'shared'
  • across applications if needed
  • 'poor man's SSO'
  • simple sign-on experience since the shared session can retain authentication state
  • interface-based and implemented with POJOs
  • allows you to easily configure all session components with any JavaBeans-compatible configuration format, like JSON, YAML
  • easily extend
  • customize session management functionality
  • session data can be easily stored in any number of data sources
  • easily clustered using any of the readily-available networked caching products
  • no matter what container you deploy to, your sessions will be clustered the same way
  • No need for container-specific configuration!
  • Shiro sessions can be 'shared' across various client technologies
  • listen for these events and react to them for custom application behavior
  • SecurityUtils.getSubject()
  • currentUser.getSession()
  • If the Subject already has a Session, the boolean argument is ignored and the Session is returned immediately
  • If the Subject does not yet have a Session and the create boolean argument is true,
  • a new session will be created
  • and returned.
  • If the Subject does not yet have a Session and the create boolean argument is false, a new session will not be created and null is returned.
  • Suject.getSession(boolean create)
  • method functions the same way as the
  • HttpServletRequest.getSession(boolean create) method:
    • kuni katsuya
kuni katsuya

MySQL & Apache Derby as jdbcRealm for Apache Shiro | Nabil Hachicha - 0 views

  • http://localhost:8080/ShiroDemo/auth/secured.jsp
  • MySQL & Apache Derby as jdbcRealm for Apache Shiro
  • Step 1 creating a simple WebApp
  • ...36 more annotations...
  • Step 2 securing some content
  • create a database that will hold the list of the authorized users along with their password
  • Create a new directory “auth” and add a new JSP under it, let’s call it “BackOffice.jsp“
    • kuni katsuya
       
      create directory 'auth' under webapps directory
  • enable Shiro into our project by adding a ServletFilter into our Web.xml
  •  <filter-class>05            org.apache.shiro.web.servlet.IniShiroFilter06        </filter-class>
  • 10    <filter-mapping>11         <filter-name>ShiroFilter</filter-name>12         <url-pattern>/*</url-pattern>13    </filter-mapping>
  • classpath:shiro.ini
  • shiro-core
  • shiro-web
  • create shiro.ini under resource dir
  • 07ds.jdbcUrl=jdbc:derby://localhost:1527/shiro_schema08ds.username = APP09ds.password = APP
  • 15/auth/** = authcBasic16/** = anon
  • jdbcRealm.authenticationQuery
  • jdbcRealm=org.apache.shiro.realm.jdbc.JdbcRealm
  • setup the jdbc realm, this is where Shiro will find the authorized users
  • map the URLs to be protected, all the url under /auth should be authenticated with basic HTTP authentication
  • All the other URLs should be accessed without authentication
  • Add a new directory under src let’s call it production we will create a new shiro configuration file compatible with MySQL
    • kuni katsuya
       
      create src/production/resources/shiro.ini with contents below
  • 06ds.serverName = localhost07ds.user = ADM08ds.password = secret12309ds.databaseName = shiro_schema
  • jdbcRealm which use a MySQL driver
  • jdbcRealm.dataSource = $ds
  • jdbcRealm.dataSource=$ds
  • added the appropriate dependency to maven pom.xml
  • mysql-connector-java
  • environment.type
  • staging
  • 13                <jdbc.user>APP</jdbc.user>14                <jdbc.passwd>APP</jdbc.passwd>15                <jdbc.url>jdbc:derby://localhost:1527/shiro_schema</jdbc.url>16                <jdbc.driver>org.apache.derby.jdbc.ClientDriver</jdbc.driver>
  • src/main/resources
  • derbyclient
  • production
  • environment.type
  • 45                <jdbc.user>ADM</jdbc.user>46                <jdbc.passwd>secret123</jdbc.passwd>47                <jdbc.ds>com.mysql.jdbc.jdbc2.optional.MysqlDataSource</jdbc.ds>48                <jdbc.serverName>localhost</jdbc.serverName>49                <jdbc.databaseName>shiro_schema</jdbc.databaseName>
  • src/production/resources
  • To build and run for staging
  • To build for production
  • -Denvironment.type=prod
kuni katsuya

Matrix of supported platforms, runtimes and technologies in JBossTools & JBDS | JBoss T... - 0 views

  • Matrix of supported platforms, runtimes and technologies in JBossTools & JBDS
  • 4.2/Juno4.06.04.3,5.0,6.07.0,6.0,5.1, 5.0, 4.2, 4.0, 3.22.3, 2.2, 2.1, 2.0, 1.22.0 , 1.2, 1.13.3.x, 4.0.x
  • 3.7/Indigo3.35.04.3,5.0,6.07.0,6.0,5.1, 5.0, 4.2, 4.0, 3.22.3, 2.2, 2.1, 2.0, 1.22.0, 1.2, 1.13.3.x, 4.0.x
kuni katsuya

MySQL :: MySQL 5.7 Reference Manual :: 5.4.4.2 Configurable InnoDB Auto-Increment Locking - 0 views

  • Configurable
    • kuni katsuya
       
      new and improved!(?)
  • table-level locks held until the end of a statement make INSERT statements using auto-increment safe for use with
  • statement-based replication
  • ...24 more annotations...
  • However, those locks limit concurrency and scalability when multiple transactions are executing insert statements at the same time
  • For INSERT statements where the number of rows to be inserted is known at the beginning of processing the statement, InnoDB quickly allocates the required number of auto-increment values without taking any lock, but only if there is no concurrent session already holding the table-level AUTO-INC lock (because that other statement will be allocating auto-increment values one-by-one as it proceeds)
  • obtains auto-increment values under the control of a mutex (a light-weight lock) that is not held until the statement completes, but only for the duration of the allocation process
  • innodb_autoinc_lock_mode = 0 (“traditional” lock mode)
  • special table-level AUTO-INC lock is obtained and held to the end of the statement
  • lock mode is provided for:
  • Backward compatibility.
  • innodb_autoinc_lock_mode = 1 (“consecutive” lock mode)
  • important impact of this lock mode is significantly better scalability
  • This mode is safe for use with
  • statement-based replication
  • innodb_autoinc_lock_mode = 2 (“interleaved” lock mode)
  • This is the fastest and most scalable lock mode
  • but it is
  • not safe
  • when using
  • statement-based replication
  • recovery scenarios when SQL statements are replayed from the binary log
  • Using auto-increment with replication
  • set innodb_autoinc_lock_mode to 0 or 1 and use the same value on the master and its slaves
  • Auto-increment values are not ensured to be the same on the slaves as on the master if you use innodb_autoinc_lock_mode = 2 (“interleaved”) or configurations where the master and slaves do not use the same lock mode
  • If you are using
  • row-based replication
  • all of the auto-increment lock modes are safe
1 - 8 of 8
Showing 20 items per page