November 2008 - dna-issues - Jboss List Archives

[JBoss JIRA] Created: (DNA-235) Create a test case for the JPDL3Metadata

by Serge Emmanuel Pagop (JIRA)

Create a test case for the JPDL3Metadata ---------------------------------------- Key: DNA-235 URL: https://jira.jboss.org/jira/browse/DNA-235 Project: DNA Issue Type: Sub-task Components: Sequencers Affects Versions: Future Releases Reporter: Serge Emmanuel Pagop Assignee: Serge Emmanuel Pagop Fix For: Future Releases use TDD and BDD -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (DNA-258) Content Management Interoperability Services API (a.k.a CMIS) implementation

by Sergiy Litsenko (JIRA)

Content Management Interoperability Services API (a.k.a CMIS) implementation ---------------------------------------------------------------------------- Key: DNA-258 URL: https://jira.jboss.org/jira/browse/DNA-258 Project: DNA Issue Type: Feature Request Components: Web Application Environment: HTTP(S) WS/SOAP Reporter: Sergiy Litsenko http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services The Content Management Interoperability Services is an emerging standard and could be useful addition to JCR way to access content repositories of any sort based on Web Services. EMC, IBM, Microsoft, Alfresco, Open Text, SAP and Oracle have joined forces to propose CMIS, the first Web services technical specification for exchanging content with and between Enterprise Content Management (ECM) systems. It is already been supported by open source community - Alfresco CMIS - is an example). Basically, it completes the picture of the repository API - JCR, Atom Publishing Protocol, and WebDAV may work together to satisfy any customer needs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (DNA-259) Service auto discovery (zero configuration networking) implementation

by Sergiy Litsenko (JIRA)

Service auto discovery (zero configuration networking) implementation --------------------------------------------------------------------- Key: DNA-259 URL: https://jira.jboss.org/jira/browse/DNA-259 Project: DNA Issue Type: Feature Request Components: Server Reporter: Sergiy Litsenko Fix For: Future Releases Federated repository works with multiple resources that require some sort of configuration and automatic discovery of services on IP networks. While it is might be difficult to enable zeroconf for some external resources without prior deploying some agents - it worth to at least enable auto-discovery of JBoss DNA Federated repository - it might be very important for JBoss DNA clients and for JBoss DNA itself in a scenario where DNA repository might sit on top of hierarchy of other DNA repositories. It is very likely scenario for global companies that have distributed, independently managed offices but still want to benefit from federated repository features. http://www.apple.com/macosx/technology/bonjour.html Bonjour, formerly Rendezvous, is Apple Inc.'s trade name for its implementation of Zeroconf, a service discovery protocol. Bonjour locates devices such as printers, as well as other computers, and the services that those devices offer on a local network using multicast Domain Name System service records. This feature used in iTunes to advertise playlist. Bonjour for Windows includes a plug-in for Internet Explorer, so you can set up a Bonjour-enabled device without knowing its IP address. http://jmdns.sourceforge.net/ JmDNS as a pure Java implementation of mDNS/DNS-SD might help with implementing discovery of other instances of JBoss DNA repository. It is used by Apache ActiveMQ (http://activemq.apache.org/discovery.html) which implements Discovery Agent to detect remote services such as remote JMS brokers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (DNA-257) Open Search implementation and integration with REST-based API for remote access and usage

by Sergiy Litsenko (JIRA)

Open Search implementation and integration with REST-based API for remote access and usage ------------------------------------------------------------------------------------------ Key: DNA-257 URL: https://jira.jboss.org/jira/browse/DNA-257 Project: DNA Issue Type: Feature Request Components: Web Application Environment: HTTP(S) OpenSearch Reporter: Sergiy Litsenko Fix For: Future Releases It is difficult to imagine having any sort of repository without ability to search. It is not surprising that JCR API specification has at least ¼ of entire spec space allocated for search capability. But again, what about applications that built using technologies other than Java or those apps who wish to use REST-based API? The Open Search might be the answer together with Lucene Web Service implementation - which is a REST-compliant Java servlet capable of searching and managing multiple Lucene indices via the web. It is built upon the Atom Publishing Protocol and conforms to the OpenSearch 1.1 standard. The OpenSearch spec http://www.opensearch.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (DNA-37) Federate schema information from relational sources

by Sergiy Litsenko (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-37?page=com.atlassian.jira.plugin.... ] Sergiy Litsenko commented on DNA-37: ------------------------------------ >From Randall: Just to make sure we're on the same page, maybe it's worth describing what a connector does. The job of a connector is to respond to a request for content (e.g., get a node, get the children of a node, copy a node from A to B, delete a node, create a node, a composite request, etc.). Typically, connector would expose the nodes that represented their content, so for a SVN connector it will expose "nt:file" and "nt:folder" nodes that represent the files and folders in the Subversion repository. A relational database connector might expose the data in its records as nodes (e.g., for a database of customers and products, you might have nodes that represent each customer and each product). And very importantly, the connector doesn't get all the information all at once, but instead responds to individual requests. So, let's take the relational database (data) connector idea. Basically, the connector just sits there, waiting for requests. Consider a client application wants to navigate the products, so they issue a request to view the children of "/" node. The data connector receives this, and "knows" that there are two top-level children: "/products" and "/customers", so it returns those Locations in the request. The client gets the Locations, chooses to navigate down the "/products" node, and issues a second request for the children under "/products". Again, the data connector receives this request, and responds with "/products/Bar Stool", "/products/Lamp", and "/products/Sofa" Locations. This process continues with the client making other requests (e.g., get the subgraph of the "/products/Sofa" node, including all properties and nodes to a depth of 3, or creating a new "/products/Coat Rack" node given a set of properties). Now, the client application uses the Graph API to make the requests, or (more likely) the JCR API and our JCR implementation (which uses the Graph API). But, the communication between the client and the connector is interactive. The client doesn't have to load all of the product and customer information, but instead can interact with a repository that contains all of the product and customer information. Except that with DNA, the "repository" content can be dynamically loaded in bits and pieces from other sources using connectors. One more thing, the connector has to be prepared to receive requests interleaved from multiple clients, so the connector can't rely upon any client-specific state. > Federate schema information from relational sources > --------------------------------------------------- > > Key: DNA-37 > URL: https://jira.jboss.org/jira/browse/DNA-37 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Reporter: Randall Hauch > Assignee: Sergiy Litsenko > Priority: Minor > Fix For: 0.4 > > > Create a connector for the federation engine that contributes and exposes the database schema information for a relational database (via JDBC) into the federated repository. This would make it possible to have a repository provide information about the databases in an organization. One choice would be whether to import (and copy) the schema structure, or to provide access to it in real time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-255) JCA Resource Adapter - integration of JBoss DNA as EIS into JEE server environment

by Sergiy Litsenko (JIRA)

JCA Resource Adapter - integration of JBoss DNA as EIS into JEE server environment ---------------------------------------------------------------------------------- Key: DNA-255 URL: https://jira.jboss.org/jira/browse/DNA-255 Project: DNA Issue Type: Feature Request Components: Server Environment: JEE 5+ certified environment Reporter: Sergiy Litsenko Fix For: Future Releases Transparently integration JBoss DNA as EIS into JEE app server environment . The JCA specification is available here - http://jcp.org/en/jsr/detail?id=112 For instance, Apache JackRabbit has JCA connector -http://jackrabbit.apache.org/jackrabbit-jca-resource-adapter.html It's not neccesary the core of the system but it adds an extra level of support for more convenient deployments and access to the JCR based system that we may not neccesary anticipate or expect up front. http://java.sun.com/j2ee/connector/overview.html JEE Connector Architecture Overview In short the J2EE Connector architecture defines a standard architecture for connecting the J2EE platform to heterogeneous EIS systems. Examples of EIS systems include ERP, mainframe transaction processing, database systems, and legacy applications not written in the Java programming language. By defining a a set of scalable, secure, and transactional mechanisms, the J2EE Connector architecture enables the integration of EISs with application servers and enterprise applications. The J2EE Connector architecture enables an EIS vendor to provide a standard resource adapter for its EIS. The resource adapter plugs into an application server, providing connectivity between the EIS, the application server, and the enterprise application. If an application server vendor has extended its system to support the J2EE Connector architecture, it is assured of seamless connectivity to multiple EISs. An EIS vendor needs to provide just one standard resource adapter which has the capability to plug in to any application server that supports the J2EE Connector architecture. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
1
0 / 0

[JBoss JIRA] Commented: (DNA-37) Federate schema information from relational sources

by Sergiy Litsenko (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-37?page=com.atlassian.jira.plugin.... ] Sergiy Litsenko commented on DNA-37: ------------------------------------ I agree that the #1 approach is not flexible. As you've mentioned database metadata object types are pretty stuctured and stable (TABLE, VIEW, SP, etc). So, the #2 (node types + mixins) is my favorite choice too. Mixins could be very important for us for example, when representing graphs to clients (plus using business rules like DROOLS, etc) in different ways or projections. BTW, Jackrabbit has flexible and extensible way to define node types without worrying about fact is it it structured or not. An example: <nodeType name="my:RootObject" isMixin="false"> <supertypes> <supertype>nt:hierarchyNode</supertype> <supertype>mix:referenceable</supertype> </supertypes> </nodeType> <nodeType name="my:MyMixin" isMixin="true"> <propertyDefinition name="my:myProperty" requiredType="String" autoCreated="false" mandatory="false" onParentVersion="COPY" protected="false" multiple="false" /> </nodeType> <nodeType name="my:ChildObject" isMixin="false"> <supertypes> <supertype>my:RootObject</supertype> <supertype>my:MyMixin</supertype> </supertypes> <propertyDefinition name="*" requiredType="undefined" autoCreated="false" mandatory="false" onParentVersion="COPY" protected="false" multiple="false"/> <childNodeDefinition name="*" defaultPrimaryType="my:RootObject" autoCreated="false" mandatory="false" onParentVersion="COPY" protected="false" sameNameSiblings="false"> <requiredPrimaryTypes> <requiredPrimaryType>my:RootObject</requiredPrimaryType> </requiredPrimaryTypes> </nodeType> > Federate schema information from relational sources > --------------------------------------------------- > > Key: DNA-37 > URL: https://jira.jboss.org/jira/browse/DNA-37 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Reporter: Randall Hauch > Assignee: Sergiy Litsenko > Priority: Minor > Fix For: 0.4 > > > Create a connector for the federation engine that contributes and exposes the database schema information for a relational database (via JDBC) into the federated repository. This would make it possible to have a repository provide information about the databases in an organization. One choice would be whether to import (and copy) the schema structure, or to provide access to it in real time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (DNA-37) Federate schema information from relational sources

by Sergiy Litsenko (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-37?page=com.atlassian.jira.plugin.... ] Sergiy Litsenko commented on DNA-37: ------------------------------------ >From Randall: Let's table the data discussion for the moment. >From Sergiy: I agree - we have plenty of work to do with database metadata integration with Connector on its own. But before I forgot I'm posting the following reference links that might be ususeful for future discussions/decisions about data paging and sampling (may be similar to Google (search for 'java' term returns "Results 1 - 10 of about 368,000,000 for java") it is related to several layers - not just the connector for relational sources: - JCR spec and our implementation, REST access / Atom publishing. >From JBoss DNA Graph API prospective: package org.jboss.dna.graph.requests ReadBlockOfChildrenRequest startingIndex the index of the first child to be included in the block count the maximum number of children that should be included in the block ReadNextBlockOfChildrenRequest startingAfter the child that was the last child of the previous block of children read count the maximum number of children that should be included in the block >From JCR prospective, JSR-170: 6.2.3 Node Read Methods public interface Node extends Item { NodeIterator getNodes(); // Returns all child nodes of this node. } public interface NodeIterator extends RangeIterator {} public interface RangeIterator extends Iterator { public long getSize(); // the number of elements in the iterator public long getPosition(); // current position within the iterator public void skip(long skipNum); // Skip a number of elements in the iterator } 6.6.12 Query Results javax.jcr.query.QueryResult: RowIterator getRows(); // query result as an iterator public interface RowIterator extends RangeIterator {} >From Java Persistence 1.0 prospective (if persistence of graph implemented using JPA): public interface Query { setMaxResults(int maxResult);// Set the maximum number of results to retrieve. setFirstResult(int startPosition) ; // Set the position of the first result to retrieve. } >From Atom Syndication format prospective: While feed paging is not directly supported by http://www.ietf.org/rfc/rfc4287.txt (correct me if I wrong) it might be useful implementing data paging using 'rel' attribute of the <link>element. Some example described here: http://www.ibm.com/developerworks/library/x-tipatom2/ "Paging Atom: Create a multi-section Atom collection or feed". See an example below for Atom + OpenSearch combined. From Open Search prospective (http://www.opensearch.org/Specifications/OpenSearch/1.1 and http://en.wikipedia.org/wiki/OpenSearch): OpenSearch 1.1 parameters: The "count" parameter - Replaced with the number of search results per page desired by the search client. The "startIndex" parameter - Replaced with the index of the first search result desired by the search client. The "startPage" parameter - Replaced with the page number of the set of search results desired by the search client. An example for Atom + OpenSearch combined: <feed xmlns="http://www.w3.org/2005/Atom" xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/"> <opensearch:Query role="request" searchTerms="JBoss DNA" startPage="1"/> <opensearch:totalResults>12345</opensearch:totalResults> <opensearch:startIndex>21</opensearch:startIndex> <opensearch:itemsPerPage>10</opensearch:itemsPerPage> <link rel="self" type="application/atom+xml" href="http://www.jboss.org/dna/atomFeed"/> <link rel="first" href="http://www.jboss.org/dna/atomFeed"/> <link rel="next" href="http://www.jboss.org/dna/atomFeed?page=2"/> <link rel="last" href="http://www.jboss.org/dna/atomFeed?page=123"/> <entry>...</entry> <entry>...</entry> </feed> > Federate schema information from relational sources > --------------------------------------------------- > > Key: DNA-37 > URL: https://jira.jboss.org/jira/browse/DNA-37 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Reporter: Randall Hauch > Assignee: Sergiy Litsenko > Priority: Minor > Fix For: 0.4 > > > Create a connector for the federation engine that contributes and exposes the database schema information for a relational database (via JDBC) into the federated repository. This would make it possible to have a repository provide information about the databases in an organization. One choice would be whether to import (and copy) the schema structure, or to provide access to it in real time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (DNA-37) Federate schema information from relational sources

by Randall Hauch (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-37?page=com.atlassian.jira.plugin.... ] Randall Hauch commented on DNA-37: ---------------------------------- I think we have a couple of choices when it comes to designing the hierarchy for database metadata. 1) Do not use node types at all, but instead use some other mechanism (e.g., hierarchy with predefined names to connote the types of content under it). This would be a difficult approach, as it relies too much on convention and is not flexible (e.g., what happens when a node has multiple types). It also is neglecting several of the primary features of JCR. 2) Use node types, where the node type is used to identify the "primary type" of the node. JCR only allows one primary type, and it is a constant for the lifetime of the node. Other aspects can be captured as mixins and/or property values. The node types and mixins would define the properties and children that are allowed. 3) Use a generic node type (e.g., "nt:unstructured") and do all the interesting things with mixins. Since the node type really allows anything, it doesn't matter that it is constant throughout the node's lifetime. Mixins describing the various facets ("system-ness", "table-ness", "view-ness", "schema-ness" etc.) could be added an removed at will. So if we rule out #1, then the choice is between #2 and #3. Normally, I'd be in favor of #3, but database metadata is fairly structured, and it's usually not important to change from one type to another. The node type could also restrict the types and number of children. Therefore, #2 seems like a better approach to me. > Federate schema information from relational sources > --------------------------------------------------- > > Key: DNA-37 > URL: https://jira.jboss.org/jira/browse/DNA-37 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Reporter: Randall Hauch > Assignee: Sergiy Litsenko > Priority: Minor > Fix For: 0.4 > > > Create a connector for the federation engine that contributes and exposes the database schema information for a relational database (via JDBC) into the federated repository. This would make it possible to have a repository provide information about the databases in an organization. One choice would be whether to import (and copy) the schema structure, or to provide access to it in real time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (DNA-55) REST-based API for remote access and usage

by Sergiy Litsenko (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-55?page=com.atlassian.jira.plugin.... ] Sergiy Litsenko commented on DNA-55: ------------------------------------ Some of my thoughts on integration of JBoss DNA and Web technologies - https://www.jboss.org/community/docs/DOC-12952 > REST-based API for remote access and usage > ------------------------------------------ > > Key: DNA-55 > URL: https://jira.jboss.org/jira/browse/DNA-55 > Project: DNA > Issue Type: Feature Request > Components: Server, Web Application > Reporter: Randall Hauch > Fix For: 0.4 > > > Create a DNA server that uses a REST-based API, allowing client applications to access and use the repository using HTTP for protocol/transport. > AtomPub is also very interesting (as it is RESTful) for a message structure, but it doesn't currently support hierarchical data. And although one could build a repository to be flatter (or at least exposed though collections; see how Bento does it: http://www.filemaker.com/bento/), it may be difficult to have no way of interacting with the hierarchical data. Bento and iTunes both show how powerful user-defined collections (and "smart collections") can be, so maybe adopting a collection-only approach would work (at least for remote access). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

dna-issues November 2008