Skip to main content
This revision made June 19, 2013 18:16, by mitch.upton

Meeting Minutes

  • Jun 19
    • Attendees: Mitch, Paul
    • Need to address security enforcement. Perhaps have the spec say that platform must secure the StateConnection but not dedicate any API to this specifically.
    • Talked about configuration ID. Leaning toward app owning the ID and making it required that it is globally unique. Need more discussion on how to get app a globally unique namespace, and that namespace would then qualify all other IDs used between app and JSR 350
    • Suggested that 'platform implementor' (the party that implements the JSR-350 SPIs) will need to provide a 'default state management provider' that can be used to store StateConnection configuration using the configuration ID discussed above.
      • NOTE: StateConnection configuration is connection-level config, like a database URL, user/password, etc. and is *NOT* deeper storage configuration like a database schema would be.
      • This lead to a discussion of 'dynamic provisioning' of resources needed to support a StateConnection. An analogy would be how JPA allows the definition of an EntityManagerFactory where the provider's database schema can be dynamically created based on name/value metadata given at the JPA level.
      • Some providers may support dynamic provisioning and some may not. This suggests we may want a DynamicProvisioningCapability as a standard capability in the JSR 350 spec.
  • Jun 12
    • Attendees: Mitch, Paul, Werner
    • Went over Paul's flowchart updates.
      • Goal of the flowchart is to define a 'roadmap' for how an application uses JSR 350.
      • Paul's Slide 2 represents the top-level runtime flow, and slide 3 represents 'design-time' for a new configuration that can be used at runtime.
      • Discussed slide 2 'Request StateConnection via configuration identifier' node
        • This node implies that the app either knows about a prior confid id or generates a new one
        • We tabled this discussion for now, but I wonder if we want providers to control these IDs, not the app
      • Jumped into slide 3 and this spawned a couple of different discussions. Summary is below.
    • Discussed what a capability is
      • Capability has a name, optional functional interface
      • Some capabilities might require configuration
      • We spent a good deal of time discussing configuration of capabilities
        • Example is transactional capability
        • TransactionalCapability is the capability name we'll use for now (not sure how we'll represent a capability in the API yet, but maybe as a class named TransactionalCapability)
        • TransactionalCapability defines a functional interface, call it TransactionalStateConnection, that contains rollback/commit methods that the app can use
        • If the app requests TransactionalCapability, it will be matched, during capability query processing, with providers that provide the TransactionalCapability
        • We discussed details of the query process, and I'll summarize them below in a separate bullet
        • Let's assume a given provider 'ProviderX' is matched to the app's capability query.
        • It is possible that TransactionalCapability may define or require extra configuration in order to behave as the app intends at runtime
          • A TransactionIsolation parameter seems like a likely candidate for a 'standard' configuration parameter that might be defined with the TransactionCapability itself
          • But other tuning parameters, maybe specific to ProviderX, seem likely too. For example ProviderX may have a configurable concurrency strategy for locking (e.g. optimistic with collision detection vs. pessimistic with locks).
          • How can ProviderX make the app aware of this custom configuration? Should JSR 350 define a mechanism (e.g. JavaBeans) by which the provider should expose its custom config to the app? Should we just not try, and tell application writers that they will need to consult with the provider (via documentation/etc.) out-of-band in order to achieve any custom configuration?
          • Honestly, I'd like to investigate a standard way to expose provider configuration because I think leaving to out-of-band negotiations between app and provider makes the use of JSR 350 in a cloud much more difficult and really prevents a nice 'IDE-based' experience for configuration regardless of provider. But, I'm open to discussions on this.
    • We also discussed how the capability query will work
      • We could accept a list of capabilities and return a list of matching providers, allowing the app to iterate the list, interrogate the provider for a list of any optional/nice-to-have capabilities it offers, and then ultimately pick the provider it wants, by name
      • Or, we could accept a 'filter' object of some kind, along with a list of capabilities, that the query logic invokes against any provider that matches the required capabilities. The filter would evaluate any nice-to-have capabilites for the provider, the provider's name, etc. and calculate a 'rank' for the provider. The query logic would then pick, on behalf of the app, the provider that was assigned the best (I assume lowest) rank. I personally like this second approach because it allows us to better hide the concept of a 'provider' behind specific interfaces like the Filter and not exposing the full provider to the app directly.
    • We also agreed we'll begin meeting weekly to get this JSR moving quickly
    • Next week: Continue discussion on capability config and query mechanics.
  • Oct 3
    • Attendees: Mitch, Peter
    • Disappointing turnout today. The agenda included having a strong group agreement on the High-level Design items on the Wiki so we could all move on as a group.
    • Peter and Mitch discussed terminology and naming, and arrived at a small set of terms that seem good. EG members that didn't attend today can feel free to comment via email.
    • Mitch to take the High Level Design page and use its contents to 'seed' the State Management Specification document.
    • TODO this week. Begin fleshing out each of the main concepts in High Level Design (StateContainer, StateManager, StateManagerFactory, StateManagerProvider).
    • Mitch to send email about each concept to act as a basis for EG discussion.
  • Sep 27
    • Attendees: Mitch, Mircea, Peter, Pinaki
    • Discussed Pinaki's API proposal and some of how it would be used with Pinaki's scenario (Person/Dog)
    • Looks like the proposed API favors single StateManager for multiple types
    • We discussed how the proposed API wraps user visible key with a system-defined key to ensure uniqueness in the VM
    • It appears to me (Mitch) that the proposed API strongly overlaps with the one in svn today, with notable differences
    • Peter suggested that we define a process to come to conceptual agreement on the fundamentals of state management.
    • His proposal (which seemed reasonable to all) was that we should step back and write down descriptions of the main entities in state management
    • Mitch volunteered to begin a spec document using LibreOffice ODT format and seed the description of main entities using Wiki, and API/code based descriptions as they exist today. We'll discuss via email during the week and reconvene next week.
  • Sep 19
    • Attendees: Mitch, Peter, Werner, Pinaki
    • Discussed Peter's and Pinaki's use case examples
    • In Peter's example
      • He was storing a POJO
      • He needed quick CRUD operations (sub-second at least)
      • He needed data to persist beyond the lifetime of a single VM
      • He needed data to persist only a short while (may age off quickly)
    • In Pinaki's example:
      • He wanted to manipulate a number of data types (e.g. Person, Dog)
      • He may need transactions to coordinate updates between a Person and Dog
    • We agreed that State Management should act as a middle man that matches application requirements to providers
    • We agreed that application should define the data types they want to use
    • We agreed that application should define other requirements such as the need for transactions, and query support, etc.
    • The application will define all these requirements via capability declarations.
    • Pinaki suggested that if an application attempts to use a data type or capability at runtime that wasn't declared up front, that the API should throw an exception or otherwise indicate an error
    • Mitch suggested that he'd like the API to be modular and flexible such that the application sees only the API methods that are applicable to the query they issued up front, limiting the possibility of late-breaking runtime exceptions
    • Pinaki said he has some examples of API usage that shows his ideas.
    • Pinaki to make those examples available to the group for next week
    • So, next week, we'll continue the discussion of the above two examples, and attempt to write out some pseudo-code to show how the application would interact with our API
  • Sep 12
  • Sep 5
    • Attendees: Mitch, Peter, Werner
    • Discussed Peter's work to get the Weld stuff working in the examples project.
      • Talked about where else to use injection vs a factory pattern from the interfaces (registry and downward)
      • Seemed like an interesting approach because implementers could plug in nearly any item they'd like and take the rest from a platform provider.
    • Talked about what tools to use for the spec
      • Candidates are OpenOffice, asciidocs, or Maven site plugin
      • Homework for the group is to come prepared to vote on the tool of their choice at the next meeting.
  • Aug 29
    • Attendees: Mitch, Werner, Mircea
    • Discussed Key as a generic
      • Adding a generic for key implied the need for adding a binding for keys as well as for values.
      • Need to look at JSR107 to see if they have something equivalent to DataHandler.
    • Discussed the 'StateManager Snapshot' facility where you can generate a durable ID from StateManager, and use it to get back an equivalent StateManager
      • Showed the code I added this week for that.
      • Changed the String I had used for the ID to a new interface called SessionManagerID (no methods yet)
    • It's time to start writing an actual spec.
      • Discussed what possible tools could be used for the spec effort.
      • Need to look into using GoogleDocs for spec. Check with Oracle Legal.
    • Mitch TODO this week
      • Add a way to release/delete a durable StateManagerID.
      • Check-in the durable StateManager ID stuff into the API and examples
      • Send Oracle Legal's reply to RedHat's question about the OCA.
      • Send info on how EG members should get the OCA signed and returned
      • Move code to GitHub, combining API/Examples under one repository


  • Aug 22
    • Attendees: Mitch, Mircea, Werner
    • Need to account for Mircea's enhancements in the API (one-step setValue/record, and createState(value)
    • Also need to verify we have Contributor agreements in place, and setup GitHub repository.
    • I think we should merge API module and examples modules in GitHub to make development easier.
    • Mircea mentioned that he's very busy with Infinispan work. He's going to give it another month, but may need to designate someone else to work on this JSR.
    • Went through the binding and capability, and configuration changes we've made the last couple of weeks
      • General agreement that the changes are a step in the right direction
      • Werner mentioned that ExpirySpec might want to use a JSR310-defined TimeUnit+Value class instead of Duration. We'll investigate. We want to use the most common and easiest to use representation here.
      • Mircea suggested we need a way to 'lock in' a StateManager once we query for and configure it. This lock in means you can get back an equivalent StateManager at a later time using some generated identifier. We agreed this was useful. Added some methods to StateManager and StateManagementRegistry to allow the generation of a 'durable StateManager ID' to refer to the StateManager, and that durable ID can be used against the registry to fetch the StateManager back at a later time
      • TODO: Need a way to 'release or delete' a durable ID to release the resources associated with it.
    • Mitch TODO this week
      • Incorporate the durable StateManager ID stuff into the API and examples
      • Send Oracle Legal's reply to RedHat's question about the OCA.
      • Send info on how EG members should get the OCA signed and returned
      • Move code to GitHub, combining API/Examples under one repository


  • Aug 15
    • Attendees: Mitch, Peter, Werner
    • Did some on-the-fly coding examples of adding features to queries. Mitch to work the new approach we came up with into the APIs, and we'll review next week
  • Aug 8
    • Attendees: Mitch, Mircea, Werner
    • Discussed the notes I added on the provider query.
      • Seems like we might need both approaches. That is, in some cases, the client may want to use a single provider to create multiple StateManagers. If that is the case, they need a way to get the provider for reusing it. However, if they don't care about the provider or reusing it, it might be clearer to just have a single step to both match the provider and create the StateManager from it.
      • We should try to find a way to have the Query include the configuration in some discrete/clear way, such that in the two-step approach, the client would create a simple capability-only Query with no configuration in it, and use that to get the provider. Then, they can create an object of some type to hold the configuration they want, and pass this to the provider to create the StateManager.
      • In the one-step case, they'd create the Query, add the capabilities they need, and then create/initialize the configuration the same as in the two-step case, and finally just set it onto the Query before passing it to some new one-step signature on StateManagementRegistry.
      • NOTE: Mircea suggested maybe we rename StateManagementRegistry to something like StateManagerFactory. That *does* make sense for the one-step case, but maybe not so much for the two-step case. I'm open to opinions here, but I'm inclined to stay with StateManagementRegistry if we want to support both the one-step and two-step StateManager creation scenarios. If we only go with one-step, then StateManagerFactory gets my vote. :-)
    • Discussed Mircea's email with feedback on the new 'Java Binding' API work
      • Collected our discussion into an email reply
      • Briefly, we identified a couple of enhancements:
        • Enhancement 1: add a record(V) signature that does setContent and record.
        • Enhancement 2: add a createState that takes an initial value (and will do a setContent/record)
      • And we identified a couple of open issues
        • Issue 1: how to handle the 'chunking' of a stream of data. Maybe a record and recordFully method where record won't block and recordFully will block and drain the entire stream.
        • Issue 2: need a cleaner way of handling keys. The Key interface seems wrong. Maybe make another generic type to represent key and let client declare their key type. Note: we also need to discuss the use of 'namespace' to qualify the keys used by the StateManager. The initial intent called out in the requirements section was that those keys are only guaranteed to be unique within the StateManager. In order to be globally unique you need to prepend the namespace of the StateManager.
  • Aug 1
    • Attendees: Mitch, Peter, Werner
    • Discussed Peters test failures. Looks like some type of mismatch between java compiler version and runtime version. Peter will investigate further this week.
    • Discussed Java bindings for StateManagement. We focused on what a Java binding for StateManagement *is*, and made some notes in the Requirements section
    • We decided that a small number of bindings might be sufficient to handle a large number of use cases. We decided to focus on the POJO binding (where we have a java class name and a marshaller), and a new binding we called the ByteChannel binding (that has no metadata but provides a stream based interface to state data).
    • Mitch will work up some API code for bindings this week. Next week maybe we can have the group try the bindings on their favorite scenarios, and maybe share with other JSR EGs to get their feedback. Werner suggested running the ByteChannel API by the JSON EG (JSR 335?)
  • July 25
    • Attendees: Mitch, Mircea, Werner, Peter
    • Discussed Peter's work on using CDI (Weld) to inject StateManagementRegistry into a client app
      • Peter made good progress this week in implementing the injection and writing tests for it.
      • He'll continue fleshing out those tests this week.
    • Discussed how to do code reviews.
      • Mircea suggested using github, and will send an email this week about usage examples
      • The use of github will require us to move to git for source code control, but that's acceptable.
    • Discussed next steps. Mitch suggested:
      • We need to more clearly define what 'java binding' for State means
      • Example is that today we use a POJO as the contents of a State object, and give the Java class name as the metadata for the binding
      • This means that if I give Query.requiredScopeName("com.myco.Foo") that the contents of any State object given to me by a StateManager I get using that query will be of type Foo, and I'd use the methods on Foo to manipulate the object.
      • Another example of a java binding might be untyped XML, and I want to use XMLStreamReader/XMLStreamWriter to manipulate the contents of state objects.
      • The question is how a customer can declare how they want to represent the state contents and then put this declaration into the Query used to create the StateManager instance.
  • July 18
    • Attendees: Mitch, Werner, Peter
    • Discussed TODOs from last time
    • Mitch created the java-state-mgmt-exmp project (as a sub-project of the main API project) to host our example code (example provider and example client code)
    • Mitch will complete that project today, adding a copy of the current RI code as the seed code for the examples project
    • Verified that EG members have commit access (Pinnaki wasn't a member of the main API project, so I added him as a software developer)
    • Mitch will rename StateManagement to StateManagementRegistry, and add a unit test for it in the API project
    • Peter and Werner will collaborate to see if we can make StateManagementRegistry a pure interface
      • Suggestion is to use CDI injection in a client/provider to gain access to a concrete instance.
      • This avoids us having to include a concrete impl of StateManagementRegistry in the spec. Note, we'd ultimately want the RI to contain a default impl so people can actually use state management.
      • Note, this change should touch both the API and examples projects. Peter, I'd make the change to StateManagementRegistry, and add an EasyMock-based test there for it. Then, I'd add a CDI test in examples that tests the injection of a concrete StateManagentRegistry instance.
  • July 11
    • Attendees: Mitch, Pinaki, Peter, Werner
    • Discussed Pinaki's work on 'clean' alternate API. This lead to some decisions about how we'll move forward defining the API.
    • TODOs:
      • Remove all concrete classes from the API
      • Remove any mention of specific impls (like Map) from API
      • Clarify the provider query and state manager creation phases for state management (what does client provide at each step, etc.)
      • Open up commit access within the API project to the EG members
      • Add unit tests to API project
        • These will use a mocking framework (I prefer EasyMock) and no concrete classes
        • These unit tests will be the gating factor for individual developers when doing commits against the API code (i.e. they must add new unit tests for new APIs, and verify that old tests still pass.
      • Add an 'examples' subproject to take the place of the RI subproject.
        • This should help clarify any IP issues around the code in this project.
        • It should be assumed that all code in the examples project is Open Source and no exclusive rights are held for it (should have a license statement matching the Java.net project's license terms on each file).
  • June 20
    • Attendeed: Mitch, Pinaki, Peter
    • Discussed some of Pinaki's feedback on Overview section
      • Clarified that state lifetime can be arbitrarily long, and can outlive the application that created it (certainly can span instances/restarts of the application)
      • Talked about the justification for a State object as an envelope for an application specific state value.
        • Certain attributes of a state object cannot be expressed directly in the application specific value
        • For example, presence, locality of a state object are controlled at the provider level, and are not reflected in the value
    • Discussed the concepts of 'presence' and transaction isolation. Mitch updated the Wiki requirements section to reflect this discussion
    • Peter mentioned that he had made comments in the Requirements section using our new comments notation from last time. Good job Peter!
    • Let's go through Peter's comments next time, and then any that Pinaki has added this coming week.
  • June 13
    • Attendees: Mitch, Werner, Peter, Mircea
    • Werner made a suggestion that the javax.state.ext package might be broken out into separate modules to promote true modularity in StateManagement. Mitch agreed this would be a good idea.
    • More discussion on requirements
    • Peter raised a question, and we discussed how to add concerns to the requirements Wiki
      • Edit the Wiki page. Feel free!
      • Add an indented bullet for your question, prefixed with [your name]
      • If the question is more substantial, add it as a numbered item in the newly added Open Issues section
    • Werner wondered if we might have Java Content Repository (JCR) as a possible Java binding.
      • Mitch looked it over after the meeting, and it looks pretty interesting.
      • It seems to overlap a little (or at least has similar structure) to JAX-R
      • It might be possible that we'd support both JCR and JAX-R as Java bindings for StateManagement
      • We need to decide exactly what it means to 'support' a particular Java binding.
        • Does this mean we just call it out as a possibility?
        • Is the specific work to be done to add support?
    • Finally, we discussed how to get EG members more invested and involved. Mitch suggested that his role should be one of oversight, and he owns the 'single voice' presentation of the specification, but that beyond that he's just an engineer like the other folks on the EG. Eventually, I think EG members should find an area that interests them, and assume a lead role in developing the API/SPI in that area, prototyping its use, etc. Some examples of focus areas:
      • Capability API
      • Provider Query criteria matching
      • Serialization
      • Transactions
      • Versioning/Evolution of State Contents
      • Java binding support
      • CRUD APIs
      • Query APIs (pass-through, specific to Java binding?)
      • Sample providers (e.g. memory, JDBC)
  • June 6
    • Attendees: Mitch, Pinaki, Werner, Peter
    • Went over content of new overview and requirements sections on the Wiki
    • Discussion quickly focused on the idea of keys, namepaces, and scope
    • Clarified that we really need a client to define requirements, in the form of fields/data given in the initial query for:
      • a namespace to qualify the simple keys used to refer to state objects
      • namespace + simple key = globally unique key
      • namespace value is held in StateManager instance used by the client, and keys given to StateManager are simple keys
      • a Java binding that defines what the Java type for the state objects 'contents' will be.
    • For POJOs, the Java binding is simply the fully qualified class name for the POJO.
    • Thus, if a Java binding of 'com.myco.Foo' is given, the following code could be used by the client to access and manipulate the state object contents
      • StateManager<Foo> mgr = provider.getOrCreate(query);
      • State<Foo> fooState = mgr.getState("key1");
      • Foo foo = fooState.getContents();
      • ... use foo1 like any other Java object ...
    • So, our task for the next week is to think of other possible Java bindings and describe:
      • how useful a given binding might be across multiple providers. A binding that is truly proprietary to a specific provider isn't very useful. Remember Goal 1 in the Overview page, Goals of StateManagement JSR section.
      • how we'd indicate that binding in the initial client query
      • how we'd define the Java type of the state object contents when using that binding
      • whether there is some separate metadata facility associated with the binding (e.g. POJO binding is self-describing, but XML is not)
      • examples:
        • an XML binding might use org.w3c.dom.Document as the Java type of state contents
        • an XML binding might also use JAXB, but this is probably just a POJO binding as the XML isn't accessed via the XML information model
        • a proprietary text binding might define it's syntax using an LLR parser definition, and use java.lang.String as the type for state contents.
  • May 30
    • Attendees: Mitch, Pinaki, Mircea (pronounced Meer-sha), Werner
    • Discussed possible query approaches for a while
    • Decided that we needed to 'back up' and make sure to document what StateManagement is about, and our high-level requirements
    • Mitch seeded the overview and requirements content on the Wiki. See the Overview and Requirements pages from the Wiki home page.
  • May 23
    • No meeting
  • May 16
    • Attendees: Mitch, Peter, Pinaki
    • Mitch noted that he's consulting with other spec leads and dev teams about JSR347 before reaching out to the JSR347 spec lead. Stay tuned.
    • Peter is going to meet with his colleague about JSR347 next week
    • Peter began investigating JSR347's RI (Infinispan) and didn't readily see the tie in to JSR350
    • We worked up some diagrams to show where JSR350 'touches' JSR347. We'll post the diagrams on the Wiki.
    • Pinaki raised questions and some concerns about the use of 'capabilities-based provider discovery'
      • Discussed that JSR350 has really two modes for looking up a provider to be used
        • Via capabilities (makes the most sense when you are starting from scratch producing new data, or can easily migrate existing data)
        • Via direct provider name lookup (makes the most sense when your data is fixed in a given provider that you must use from your application)
    • Peter asked for suggestions on what to work on for the week. Mitch suggested writing a couple of 'dummy' providers with different capabilities, and writing a client to query for them and use them.
    • Pinaki will download the API/RI source and begin going through it this week. He should start by looking at StateManager interface.
    • Mitch is looking at the transaction APIs (TransactionalStateManager, etc.)
  • May 9
    • Attendees: Mitch, Peter, Werner
    • Said we need to coordinate early and directly with JSR347 (DataGrid) and JSR351. State Management may be a CacheStore for JSR347, and may use some query tech from JSR351
    • Peter said he'd contact a friend of his on JSR347.
    • Mitch to send a letter of introduction to JSR347 spec lead this week.
    • Wrote HelloWorld.java example (will be available in ri project under examples module, eg.examples package)
    • Gave 'Software Developer' role to EG members. Feel free to put your own examples under the eg.examples package
    • Capabilities Phases
      • Provider declared caps
      • Consumer requests caps
      • Consumer gets StateManager with caps
      • These are all in the same BasicQuery object today, but that seems confusing to me
    • Other Wierd Things
      • Required Scope Name (Confusing, it means what typeof object to manage)
      • The getOrCreateState() method takes Key, but others take String for key (how should keys be modeled?)
      • Used to have first-class concept of scope (session, request, app, global), but then we needed to handle POJOs too. How to reconcile the two cleanly.
      • In order to work, the type being managed today has to implement Serializable/Expirable. This should be pluggable
Difference compared to previous revision
Meeting Minutes * Jun 19 ** Attendees: Mitch, Paul ** Need to address security enforcement. Perhaps have the spec say that platform must secure the StateConnection but not dedicate any API to this specifically. ** Talked about configuration ID. Leaning toward app owning the ID and making it required that it is globally unique. Need more discussion on how to get app a globally unique namespace, and that namespace would then qualify all other IDs used between app and JSR 350 ** Suggested that 'platform implementor' (the party that implements the JSR-350 SPIs) will need to provide a 'default state management provider' that can be used to store StateConnection configuration using the configuration ID discussed above. *** NOTE: StateConnection configuration is connection-level config, like a database URL, user/password, etc. and is *NOT* deeper storage configuration like a database schema would be. *** This lead to a discussion of 'dynamic provisioning' of resources needed to support a StateConnection. An analogy would be how JPA allows the definition of an EntityManagerFactory where the provider's database schema can be dynamically created based on name/value metadata given at the JPA level. *** Some providers may support dynamic provisioning and some may not. This suggests we may want a DynamicProvisioningCapability as a standard capability in the JSR 350 spec. * Jun 12 ** Attendees: Mitch, Paul, Werner ** Went over Paul's flowchart updates. *** Goal of the flowchart is to define a 'roadmap' for how an application uses JSR 350.
 
 
Close
loading
Please Confirm
Close