Recent changes to the connector framework
by Randall Hauch
I just finished working on some big changes to the connector
framework. All the detail regarding the issue and the design can be
found in DNA-281 (https://jira.jboss.org/jira/browse/DNA-281).
However, this is a fairly significant change, so I wanted to let
everyone know what's going on. (The commit email was actually too
big, which is another reason for this email).
The problem stems from not having a perfect mapping between a
connector and the notion of a JCR workspace. When we came up with the
initial connector design, we'd hoped that a connector would map to a
JCR workspace, and that we could just create multiple sources
(instances of connectors) when we need multiple workspaces.
Unfortunately, some of the workspace-level operations in JCR don't
work too well with this. In particular, creating workspaces would
have entailed setting up new RepositorySource instances, which is
difficult if you have to also set up the back end system, like a
database. To really fix this, we need a connector to be able to have
multiple workspaces and to support creating, cloning, and destroying
workspaces.
Normally, this would be that much of a surprise. We've always
followed the evolutionary approach to design and development. So this
change wouldn't really be that special - if it weren't for the size of
the change. The connector API is affected, which means that each
connector implementation is affected. Also, the Graph API is affected
because we need to expose these new operations. And this meant that
every code that used the Graph API may be affected, since they now
need to possibly have some notion of a workspace. All in all, a lot
of code has been impacted by this. And I spent several days trying
different approaches that were incremental, and nothing worked. I had
no choice but to make all the changes at once.
Interestingly, while making the changes, I discovered a bug in the
federation code (DNA-282), and a number of existing test cases fail.
And of course the Getting Started repository example fails because it
relies up the federation connector. So, rather than complicate an
already mess of a commit set, I decided to temporarily remove these
two projects from the build.
Similarly, I have local changes to the JCR project to support writing
(which was the ultimate reason why support for workspaces was needed
in the first place). And these changes aren't quite complete enough
to commit, yet I didn't want to spent a lot of time fixing test cases
that I'll be making changes to. So this project was also pulled from
the build, too.
My apologies for the state of the project, and for this massive
commit. I dislike these large changes with a passion, but just
couldn't figure out a way to get around it. But everything compiles,
and all tests (except those listed above) run successfully.
For those of you working on connector implementations, feel free to
look at the in-memory connector, the JBoss Cache connector, or the JPA
Store connector. Specifically, look in the RequestProcessor
implementation classes in the connectors, since that's where all the
interesting stuff is. Of course, some of the source implementations
have properties that define the names of "predefined workspaces" and a
"default workspace", and that may be of use to you. These all support
multiple workspaces, but in slightly different ways. I think the
notion of workspaces would work really well in a couple of our
connectors, including SVN and JDBC metadata. Of course, if you have
any questions, please post to this list.
Best regards,
Randall
16 years
- 1
- 0
- ← Newer
- 1
- Older →