Thanks for the help!

Yes, the sequencer initializes (I see it log its initialization and I see it show up in a diagnostic that returns  repo.getConfiguration().getSequencing().getSequencers()).

I have tried (*.xml) and (.*) and a few other variants, without success... I looked hard at the configuration in the modeshape-sequencers example, but I can't see where I'm going wrong.

No change in behavior from using 3.1.0.Final.

I will try rebuilding ModeShape with extra debugging, but it is going to take a while for me to get the chance. Right now I'm thinking I may have to just trigger the sequencer directly from the appropriate JAXRS resource, which means I can't use getLogger(), but at least it will execute.

I will first try installing a "stock" sequencer and confirm that it is functional.

Thanks for the help so far!

Okay, this may be an important clue.

I added:

"Images in the same location" : {

                "classname" : "org.modeshape.sequencer.image.ImageMetadataSequencer",

                "pathExpressions" : [ "fedora://(*.(gif|png|pict|jpg))/jcr:content[@jcr:data]" ]

            }

to the sequencers in my repository config and added modeshape-sequencer-images to my Maven dependencies. The seqencer apppars to exist (via the same diagnostic result as described above).

I tried adding a resource at fedora:/foxml/test.jpg. I'm using JcrTools.uploadFile in a JAXRS resource to do it, and loading the file via curl with "Content-type: image/jpg", and... nothing. Nothing in the log to indicate that anything happened in the way of sequencing. I would think I should at least get a stack trace because the file is not a proper JPG.

Am I missing some kind of obvious global setting to turn the sequencers on? I had thought they were on all the time to support ModeShape standard functionality like full-text indexing...

Another possiblity: my sequencer config defines to use a thread pool "modeshape-workers". Removing this seems to have no effect, but I'm wondering if I need to have a particular setting here. Perhaps my sequencers are not getting executed because there are no threads to run them?

Thanks to both of you for the help!

I put a line in my JAXRS resource:

{code} 
logger.debug("Storing to " + ws.getName() + ":" + foxmlpath);
{code}

where ws is the workspace (from which I'm getting my Session) and foxmlpath is the path under which to store. The actually storage occurs with:

{code} 
final Node foxmlnode = jcrtools.uploadFile(session, foxmlpath, foxml);
{code}

where foxml is the InputStream from the request body. For my test this produces:

"Storing to fedora:/foxml/test.jpg"

I changed the config to:

{code}
"Images in the same location" : {
                "classname" : "org.modeshape.sequencer.image.ImageMetadataSequencer",
                "pathExpressions" : [ "fedora:/foxml/test.jpg/jcr:content[@jcr:data]" ]
            }
{code}

and still... nothing. As I said, the request body isn't a legitimate JPG, so I would expect to see a stack trace of some kind. Incidentally, I do see the content stored and can retrieve it (via JAXRS)...

I just noticed some odd behavior in my application that might be another clue.

I'm using the Maven Jetty plugin to run this application. That's how I've been doing testing. I haven't configuring any transaction managment, so at repository startup I see a lot of messages from GenericTransactionManagerLookup about trying to find transaction managers from various containers and not finding them, finishing with:

WARN  o.i.t.l.GenericTransactionManagerLookup - ISPN000104: Falling back to DummyTransactionManager from Infinispan

In my JAXRS resource, I have a PUT method that stores request material in a JCR node (the code about which this whole discussion has centered). In that code, if the node does not exist, it gets stored (no problem). If it does exist, I was doing a

{code}
if (session.hasPermission(foxmlpath, "remove")) {
     logger.debug("Removing old FOXML file at" + foxmlpath);  
     session.removeItem(foxmlpath);
     //session.save();
     logger.debug("Adding new FOXML file at" + foxmlpath);
     final Node foxmlnode = jcrtools.uploadFile(session, foxmlpath, foxml);
     session.save();
{code}
etc.

and it would fail because it couldn't add a same-name sibling in that location. When I uncomment the session.save(), it works. This puzzles me, beacuse I thought part of the semantics of JCR provided for the ability to use the Session for lightweight transactionality. I shouldn't (I thought) have to persist all my changes as I go-- I should be able to make several changes and then save, and provided my changes left the repository in a valid state, no problem. But it appears that I have to save after any change to have it be visible to subsequent operations in the same Session! A colleague of mine working on the same code found the same thing happening elsewhere.

Is it possible that my weird "No sequencing for you, buddy!" problem is related to this? Do I need to engage some kind of transaction manager to have the sequencing work correctly and have session state operate as I expect?

Right-- I had understood that to be what was going on with the GenericTransactionManagerLookup. Having latched in your suggested dependency, that sequence of logging now finishes with:

12:37:52.810 [qtp1743416060-27] INFO  o.i.t.l.JBossStandaloneJTAManagerLookup - ISPN000107: Retrieving transaction manager Transaction: unknown

which I assume is good news.

Unfortunately, nothing else changes. The code still fails with a javax.jcr.ItemExistsException without the extra save in place and sequencing is not triggered. The code is a little different than what is at Github because I've been trying different changes as you talk me through this problem, so let me include it here:

{code}
@PUT
 @Path("/{filename}")
 //@Consumes("text/xml")
          public Response addFOXML(@PathParam("filename") final String filename,
                              InputStream foxml) throws RepositoryException, IOException {
 
                    final Session session = ws.getSession();
                    if (session.hasPermission("/foxml", "add_node")) {
                              final String foxmlpath = "/foxml/" + filename;
                              logger.debug("Storing to " + ws.getName() + ":" + foxmlpath);
                              if (!session.nodeExists(foxmlpath)) {
                                logger.debug("Adding new FOXML file at" + foxmlpath);
                                        final Node foxmlnode = jcrtools.uploadFile(session, foxmlpath,
                                                            foxml);
                                        session.save();
                                        return Response.created(URI.create(foxmlnode.getPath()))
                                                            .build();
                              } else {
                                        if (session.hasPermission(foxmlpath, "remove")) {
                                        logger.debug("Removing old FOXML file at" + foxmlpath);
                                                  session.removeItem(foxmlpath);
                                          //session.save();
                                                  logger.debug("Adding new FOXML file at" + foxmlpath);
                                                  final Node foxmlnode = jcrtools.uploadFile(session,
                                                                      foxmlpath, foxml);
                                                  session.save();
                                                  return Response.created(URI.create(foxmlnode.getPath()))
                                                                      .build();
                                        } else return four01;
                              }
                    } else return four01;
          }
 
{code}

I'm sorry for the rotten cut-and-paste formatting. ws is a static member which is the 'fedora' workspace. As you can see, it's fairly simple, and to speak to Horla's point, there is a final session.save() happening in both cases, which is the point after which I would expect to see sequencing. It's the (commented-out above) session.save() that seems to be required after I remove the pre-existing resource that is odd. Incidentally, the occasion when my colleague found similar behavior did not involve JcrTools at all. It was all "manual" nodebuilding, but he saw the same thing-- extra saves required in between operations.

To the persistence configuration: we have succesfully configured Infinispan to store to disk and to use pessimistic locking, but we didn't thikn it necessary for this simple code (which is being written just for the purpose of evaluating ModeShape). Perhaps we need to do that to get sequencing to work? Is it not possible to take advantage of that great feature with an in-memory store? We'd very much like to.

---

Update:

I've gone ahead and made use of the information Randall gave: that JcrTools.updateFile() uses findOrCreateNode() behind the scenes so that I don't have to test for pre-existence myself. This works and make the code considerably shorter (yay!).

But still no sequencing. And I'm still confused by the behavior of Sessions as lightweight transactions.

Thanks for the help so far!

See my update to my last message above-- that works very well for this example. But I'm still confused by the behavior of Session, and why I and my colleague required "too many saves". Could this be connected with the Infinispan configuration? Shouldn't it be independent of anything else in the system, since the behavior of Session is governed by the JCR semantics? It seemed very clear to me (and him) that a change made in a Session should be immediately visible to subsequent changes in the same Session, but not visible to other Sessions. But that doesn't seem to be the case for our (possibly strange) configuration. And has this behavior any connection to the mysterious absence of sequencing...?