Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Jun 12, 2012

  1. Randall Hauch

    'Release: update versions for modeshape-3.0.0.Alpha5'

    rhauch authored
  2. Randall Hauch

    Corrected release script

    rhauch authored
  3. Randall Hauch

    Corrected parent POM reference from JBoss AS integration tests

    rhauch authored
  4. Randall Hauch

    Corrected parent POM reference from JBoss AS integration tests

    rhauch authored
  5. Randall Hauch

    Additional cleanup of source distribution and removal of unused files

    rhauch authored
  6. Randall Hauch

    MODE-1508 Removed 'provided' scopes that cause JavaDoc issues

    The Maven JavaDoc plugin requires 'compile' scope to find referenced or linked classes,
    and the recently-changed 'provided' scope for the JBoss AS7 subsystem meant the
    JavaDoc could not be successfully built for the AS7 subsystem. Thus we needed to
    change the 'provided' scopes back to 'compile' for the AS7 subsystem.
    
    (Also, I couldn't find the AS7 JavaDocs to see if linking to them changed the result.)
    rhauch authored
  7. Randall Hauch

    Updated top-level POM and profiles

    rhauch authored
  8. Randall Hauch

    Updated release notes for 3.0.0.Alpha5

    rhauch authored
  9. Randall Hauch

    MODE-1509 Added libraries to AS7 kit to support storing indexes in In…

    …finispan
    
    Added the Hibernate Search Infinispan and Infinispan Lucene Directory jars to the 'org.hibernate.search-engine' AS7 module that's part of the ModeShape+AS7 kit. This allows configuring a repository to store the indexes in Infinispan caches.
    rhauch authored
  10. Randall Hauch

    MODE-1508 Corrected ModeShape module for AS7

    Merged the AS7 modules for the built-in sequencers into the 'org.modeshape' module. Other sequencers that depend on 'org.modeshape.jcr.api' can always be added as separate modules.
    rhauch authored
  11. Randall Hauch

    MODE-1508 Updated release script with new JBoss AS7 distribution

    Updated the release script to grab the new location of the kit for AS7.
    rhauch authored
  12. Randall Hauch

    MODE-1508 Cleaned up dependencies for JBoss AS7 integration

    Removed the unnecessary dependencies from the REST service WAR for JBoss AS7, since most of the third-party libraries are now provided by AS7 (including RESTEasy). The assembly was made quite a bit easier, too. Note that the WAR can no longer be tested using Jetty, since Jetty doesn't provide all of the JEE APIs or their implementations.
    rhauch authored
  13. Randall Hauch

    MODE-1508 Cleaned up optional dependency on Aperture

    The Aperture library was changed to 'provided' scope, which means developers can add this library to the classpath, and ModeShape will automatically enable the Aperture-based MIME type detector. However, it is no longer there automatically.
    rhauch authored
  14. Randall Hauch

    MODE-1508 Corrected MS Office sequencer test's use of MIME types

    Corrected the unit tests for the MS Office sequencer to expecting either of two possible MIME types for Word documents.
    rhauch authored
  15. Randall Hauch

    MODE-1508 Corrected the ZIP sequencer to use Binary.getMimeType(…)

    Changed the ZIP sequencer to no longer use the MimeTypeDetector on ExecutionContext, but instead use the method on ModeShape's Binary interface.
    rhauch authored

Jun 11, 2012

  1. Randall Hauch

    Merge branch 'mode-1510' of https://github.com/rhauch/modeshape into …

    …rhauch-mode-1510
    rhauch authored
  2. Randall Hauch

    MODE-1510 Corrected configuration of Infinispan for index storage

    ModeShape internally generates a Hibernate Search engine configuration based upon ModeShape's configuration.
    Hibernate Search can use the Infinispan Lucene Directory to store Lucene indexes in Infinispan, but
    ModeShape incorrectly passed down the information about where the Infinispan configuration was, preventing
    using the same Infinispan configuration for both content storage and index storage.
    
    This change corrects this problem, and allows defaulting to the same file-based Infinispan configuration
    for index storage that's used for content storage. This fix should also work in AS7, since the JNDI
    name of the cache container is passed through.
    
    The build completes successfully with these changes.
    rhauch authored

Jun 08, 2012

  1. Horia Chiorean

    MODE-1489 - Fixed infinite loop when calling orderBefore multiple tim…

    …es without save
    
    The problem was caused by the fact that there was a "circular" reference when the first orderBefore had been called on the same child, both as source and destination (i.e. orderBefore(child0, child0)). The fix was done on several levels:
    * orderBefore on the same source and target should be a no-op (as per spec)
    * insertBefore on the child references of a session node should be a no-op if the references are identical
    * the child references iterator, when another delegate iterator is provided, should not loop indefinitely if there are circular references
    hchiorean authored rhauch committed
  2. Randall Hauch

    MODE-1500 MODE-1501 Corrected AS7 integration (JNDI names and assembl…

    …ies)
    
    Several issues were identified and corrected. The first was that although the ModeShape engine
    (e.g, the 'org.modeshape.jcr.api.Repositories' implementation) was registered in JNDI,
    the Repository instances were not correctly being registered and were thus not able to be found
    by deployed components. This was rectified, and now the engine and each repository is properly
    registered in JNDI.
    
    Secondly, the JNDI names where the engine and repositories are registered were changed to
    more closely align with the naming patterns used by other implementations. The engine
    is always registered at "jcr" in the "java:" namespace (i.e, "java:/jcr"), while each
    repository is registered at "jcr/{repositoryName}" in the "java:" namespace. For example,
    the repository named "sample" could be found in JNDI at "java:/jcr/sample" or "jcr/sample".
    This conforms to the many examples that configure a JCR repository at "jcr/local"
    (where only one repository is used).
    
    Note that the new default JNDI names are different than ModeShape 2.x, which used "jcr/local" as the
    location of the engine and "jcr/local/{repositoryName}" as the default location for each
    repository. However, should the old style still be needed for a repository, the repository can
    be configured with a custom JNDI name.
    
    Thirdly, when a repository is configured to have a custom JNDI name, the repository is registered
    under the specified name (as before), but now the repository is still registered under the
    'jcr/{repositoryName}' name. This means that code can find the repository under either name.
    
    Fourthly, the assembly for the ModeShape kit was moved from the 'deploy/jbossas' Maven module
    (which installed the resulting ZIP into the Maven repository at 'org/modeshape/jbossas/jbossas-{version}-jbossas-7-dist.zip')
    and into the "modeshape-distribution" module, which is where the binary and source distributions
    are assembled. And the assembly descriptor was moved to the "modeshape-assembly-descriptors"
    module (again, where the other assembly descriptors are managed and installed into the Maven repository).
    
    Fifthly, new integration tests were written to verify that EJBs (of various flavors) can
    find the ModeShape repositories correctly using the 4 different ways of looking up a repository:
    1) looking up a repository in JNDI
    2) looking up the Repositories interface and using it to get a named repository
    3) using RepositoryFactory with a single URL (e.g., "jndi:jcr/sample" or "jndi:jcr?repositoryName=sample")
    4) using RepositoryFactory with a URL to the engine (e.g, "jndi:jcr") and the name of the repository
    
    These new integration tests are in a new Maven module that downloads AS7 and the ModeShape kit
    from the Maven repository and unpacks them into the 'target' directory. When Surefire runs,
    this managed server is started, the Arquillian tests are run, and then the server is shutdown.
    Each Arquillian test involves creating a WAR file that will be deployed by Arquillian to the
    running server, running the unit tests, and then undeploying the WAR file. The tests
    can also be run with a different profile so that the tests are deployed and executed in
    a separate server installation (as specified by the $JBOSS_HOME variable).
    
    Finally, the older "modeshape-integration-tests" module and the new "modeshape-jbossas-integration-tests"
    were relocated to a new top-level folder called 'integration' in the source code. Like the other
    top-level directories in our codebase, this is also a Maven module that can be used to run
    all of the integration tests. And the '-Pintegration' profile was brought back so that
    the distributions are not created and the integration tests not run during the normal builds.
    Thus, to run a normal developer build (with all the unit tests but none of the integration tests) simply use
    
        mvn clean install
    
    while the following command will build everything, run all the unit tests, build the AS7 assembly, and run the integration tests:
    
        mvn clean install -Pintegration
    
    As before, running an 'assembly' build (used for releases) will build everything, run all the unit tests,
    build the AS7, binary, and source assemblies (including JavaDoc), run the integration tests, and run
    the demos:
    
        mvn clean install -Passembly
    rhauch authored

Jun 05, 2012

  1. Randall Hauch

    MODE-1489 ModeShape's JCR Session now implements XAResource (for 'aut…

    …o' transactions)
    
    When the 'auto' transaction mode is enabled (this is the default setting), ModeShape's JCR Session implements XAResource, allowing JCR clients to explicitly enlist the Session as a resource in the transaction. In all other ways, the new JcrXaSession is identical to the JcrSession class. The JcrXaSession class delegates all calls to the XAResource of the Infinispan cache, and (as with the other JTA-related changes) ModeShape participates in the transaction via javax.transaction.Synchronization mechanism.
    
    When the 'none' transaction mode is used, ModeShape's session does not implement XAResource.
    rhauch authored
  2. Randall Hauch

    MODE-1498 Added configuration option to dictate the transaction mode

    Changed the repository configuration JSON schema to add a 'transactionMode' field, with the following enumerated values:
    
    * 'auto' is default and automatically detects whether Session.save() is called on a thread that already has a transaction associated with it, and if so works with that existing transaction. This is the safest option that can be used in all environments, and it has minimal overhead. This is the required setting when used within an JEE container where container-managed or user-managed transactions are used.
    * 'none' specifies that the repository should never look for an existing transaction on the thread, and should be used *only* in environments where the JCR clients will never use transactions. IOW, it is not safe to be used in cases where the JCR client *might* create transactions (because ModeShape uses transactions internally, and nested transactions are rarely supported). Using '{{none}}' is an optimization that prevents the (minor) overhead of the Session.save() checking for an associated transaction, but it may make sense in embedded applications running in Java SE with no TransactionManager implementation.
    
    Added tests to verify the field is being read correctly from the configuration.
    
    The build runs successfully with these changes.
    rhauch authored
  3. Randall Hauch

    MODE-1498 Added initial support for JTA transactions

    With this commit, container-managed transactions and even user-managed transactions (including both local
    and distributed) should work, per Chapter 21 of the JSR-283 specification. Even when using XA transactions,
    ModeShape works with the transactions (via Synchronizations) and Infinispan automatically registers the
    cache as a resource in the transaction.
    
    However, this commit does not yet change JcrSession to implement XAResource. We need to make this change
    per Section 21.4 of the specification so that users can directly enlist the ModeShape Session instance
    into the transaction. Implementing XAResource will be completed in a subsequent commit.
    
    The build runs successfully with these changes.
    rhauch authored
  4. Randall Hauch

    MODE-1462 Changed TransientBinaryStore log message to only output whe…

    …n not running in AS7
    
    The log message isn't needed in our AS7 subsystem because the subsystem always configures some
    binary store and doesn't rely upon the transient store.
    rhauch authored
  5. Randall Hauch

    MODE-1462 Removed (apparently) unnecessary logging dependencies from …

    …JBoss AS7 subsystem
    
    Several logging dependencies were removed from ModeShape's AS7 subsystem. They apparently aren't
    needed, since ModeShape uses SLF4J (if it's available, and it is in AS7) and the build works
    without issue and the subsystem can be deployed to AS7 and used without any issues (and logging works).
    rhauch authored
  6. Randall Hauch

    MODE-1462 Added support for a custom logger

    ModeShape now supports using a custom logger, allowing applications to provide
    a 'org.modeshape.common.logging.CustomLoggerFactory' class that will be found
    and used only after SLF4J and Log4J.
    rhauch authored

May 31, 2012

  1. Randall Hauch

    MODE-1496 JCR-3313 Added fixed JCR TCK test and corrected result set …

    …column behavior
    
    Corrected the behavior of query result column names when the query contains a wildcard in the SELECT statement.
    rhauch authored

May 30, 2012

  1. Randall Hauch

    MODE-1494 Changed the XSD sequencer to not generate 'application/xsd'…

    … for the MIME type
    
    The correct MIME type for XSD files is "application/xml" or "text/xml", so changed the XSD
    sequencer to generate "application/xml" for the MIME type property on the derived output.
    
    Also clean up a few compiler warnings.
    rhauch authored
  2. Randall Hauch

    MODE-1491 Improved the sequencer initialization logic

    Added state that captures whether each Sequencer instance has been successfully initialized, allowing
    the Sequencer's internal (private) methods to better manage and create state that is now safely accessible to
    subclasses. (For example, the Set<String> containing the accepted MIME types is now an immutable collection.)
    rhauch authored

May 29, 2012

  1. Randall Hauch

    MODE-1491 Added support for sequencers specifying acceptable MIME types

    Added support for the sequencers to specify the set of MIME types for the binary content that they accept. Some sequencers (such as the DDL sequencer) do not specify any MIME types (for various reasons, often because there is no MIME type defined for the content types), and thus fall back to the old behavior where the sequencer attempts to process all matching input.
    
    As before, the input node must first satisfy the path expression. However, sequencers that also specify one or more MIME types (either via defaults or overwritten in each sequencer configuration) are invoked only if the MIME type of the changed property matches can be found and is one of the sequencer's MIME types.
    
    The MIME type of the changed property is found as follows:
    
    - if the input node contains a single-valued 'jcr:mimeType' property, then the value of this property is considered the MIME type of the changed property; otherwise
    - if the input node is named "jcr:content" and its parent contains a single-valued 'jcr:mimeType' property, then the value of this property is considered the MIME type of the changed property; otherwise
    - if the changed property is a BINARY property, then the ModeShape-specific Binary interface is used to obtain the MIME type for the binary value, given the name of the parent node (or grandparent node, if the parent node is named "jcr:content"); otherwise
    - the MIME type could not be determined and does not influence whether the sequencer is invoked
    rhauch authored
  2. Randall Hauch

    MODE-1462 Updated the web modules with recent logging changes

    rhauch authored
  3. Horia Chiorean

    MODE-1462 - Updated logging based on code review comments

    hchiorean authored
  4. Horia Chiorean

    MODE-1462 - Updated logging:

    - moved all logging classes to common.logging instead of common.util
    - added logging factory  & logger for pure Log4j support
    - changed logging dependencies scope from <compile> to <provided>
    - added a logger abstraction in modeshape-jcr-api and an implementation in modeshape-jcr which should be used for extensions
    - updated Sequencer and TextExtractor base classes so that upon creation, they are provided with the extension logger
    hchiorean authored

May 25, 2012

  1. Horia Chiorean

    MODE-1477- Updated test configuration stub for the TCK tests to use a…

    … separate root node for the locking tests
    
    The reason why the  ExportDocViewTest were failing asynchronously was because of the locking tests which were modifying the root test node
    hchiorean authored

May 24, 2012

  1. Randall Hauch

    MODE-1477 Changed JCR TCK test suite to use standard suite.

    rhauch authored
  2. Randall Hauch

    MODE-1485 Corrected names of columns when property name is not specif…

    …ied.
    
    >
    > The names of columns in query results were corrected to be of the form 'selectorName.propertyName' when the
    > property name is not explicitly specified in the query (e.g., 'SELECT * ...' or 'SELECT s.* ...').
    rhauch authored
Something went wrong with that request. Please try again.