[teiid-issues] [JBoss JIRA] (TEIID-4748) Provide translator/connector for calling Java api

[Steven Hawkins (JIRA)]

     [ https://issues.jboss.org/browse/TEIID-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins reassigned TEIID-4748:
-------------------------------------

    Assignee: Van Halbert  (was: Steven Hawkins)


There needs to be a lot more details here.

> calling a java method on an API that returns an object (or collection)

If we're talking about static logic, this can already be provided by a UDF.

If it's not static, then the question of the statefulness is likely to be a resource adapter issue (overlapping with the last bullet).  Without additional metadata this would likely be a readonly case.

> the return object should be exposed as a table

This can be done either in the translator layer or with objecttable.

> the resource adapter should be able to provide the connection to the java api (either remote or local)

Can you clarify what this means - unless you are talking about a standard access mechanism, such as an EJB.  There isn't a generic notion of local vs remote connectivity.

> The object translator has, at its core, the base for handling all the reflection logic for reading and writing on a java object. It may make sense to refactor out the core logic for reuse.

It already has been - it's the objecttable table function.

> Provide translator/connector for calling Java api
> -------------------------------------------------
>
>                 Key: TEIID-4748
>                 URL: https://issues.jboss.org/browse/TEIID-4748
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Misc. Connectors
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>
> Provide a translator/connector for doing the following:
> -  calling a java method on an API that returns an object (or collection)
> -  the return object should be exposed as a table 
> -  the resource adapter should be able to provide the connection to the java api (either remote or local)
> This scenario doesn't  work with the current object translator, as its based on reading from a cache (map) and the connection methods are exposed based on that scenario.
> The object translator has, at its core, the base for handling all the reflection logic for reading and writing on a java object.   It may make sense to refactor out the core logic for reuse.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)