Re: [teiid-designer-dev] [teiid-dev] Teiid In JCA Container
by Ted Jones
Ramesh,
Here is a working doc we have regarding Jopr for Teiid: https://docspace.corp.redhat.com/clearspace/docs/DOC-20809
It's sort of open-ended since the direction is dependent on the ever-evolving direction of Teiid, but it should give you a good idea of Jopr capabilities we plan on leveraging. This doc was written with the expectation that the Admin API was going to be around moving forward, but that assumption seems to be in question now??
> Based on the discussions so far, a Teiid "connector" will be replaced
> with JCA connector. There are already ways to create/manage the JCA
> connector through profile service (look at JBoss AS JOPR plug-in).
> Now for Teiid how can we use this? Do we really need a separate place
> where we can manage this? or what offered through JBossAS plug-in
> sufficient?, if not what we need in there to satisfy our needs?
We can re-use/extend plugins so we should be able to take what the JBossAS plugin is doing and make it our own.
> VDB management is something we still need to do though the Teiid JOPR
> plugin. If deploying a VDB is similar to deploying WAR file how can we
> accomplish this? Because it would be no different than that.
We can re-use the war deployment logic and add VDB verbiage in our Teiid plugin.
> What kind of support that JBossAs JOPR plugin provide for the creating
> the security domains or mapping roles because we are going to make use
> of those, if not can we contribute? are these planned for Teiid plug-in?
That's something Van and I have on our list for discussion. If we can assume that we are going to be deployed in JBossAs and ONLY JBossAS, then the Jopr plugin DOES have Tomcat user/group/role management capabilities that we could utilize.
Thanks,
Ted
14 years, 6 months
Re: [teiid-designer-dev] [teiid-dev] Teiid In JCA Container
by Ted Jones
Ramesh,
Up until now, Van and I were under the impression that Teiid discovery in 6.3 for Jopr (Teiid Console) may and likely WOULD change, but the core functionality made available through the Admin API would not. Based on this thread it sounds like both discovery and configuration will be completely different. Instead of doing a lot of work on the console that will get tossed, we need to put the Teiid console development on hold until all the design decisions are made regarding deployment and configuration of Teiid for 6.3. We need to be included in any decisions made regarding the final approaches. Also, Van and I can be used as resources for implementing the configuration approach which will allow us to more easily add the necessary hooks to the Teiid Jopr plugin.
Thanks,
Ted
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: teiid-dev(a)lists.jboss.org
Cc: teiid-designer-dev(a)lists.jboss.org
Sent: Thursday, October 22, 2009 9:19:46 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Teiid In JCA Container
Jesper's Response..
-----------------------------------------------------------------------------------
Hi Ramesh.
On Wednesday 21 October 2009 18:15:20 Ramesh Reddy wrote:
> Jasper,
>
Its J*e*sper ;)
> Thanks again for very valuable comments. If you do not mind I will
post these on WIKI page to share with others.
>
Feel free, we should have this discussion on the Teiid design forum
really...
> (2) I understand. In Teiid we call this mode as embedded "File-path
> profile" in current release. We have to sacrifice the
> "classpath-profile" now for the benefits. see
> https://www.jboss.org/community/wiki/ConnectingtoTeiidEmbedded
>
Ok.
People have different definitions of embedded ;)
> Do MC beans provide the configuration functionality, where profile
> service is not? i.e. teiid-jboss-beans.xml through @ManagedObject, if
> that is case I need to think about bringing in MC as core dependency
for
> Teiid. Then, how are these available through JMX?
>
Different concepts.
A MC bean is just a Plain Old Java Object (POJO) managed by the JBoss
Microcontainer. The MC projects provides various APIs/SPIs to do
integration.
http://www.jboss.org/index.html?module=bb&op=viewforum&f=228
Lead: Ales Justin
Profile Service handles "profiles" of a server -- e.g. "give me a
configuration with logging, naming, transaction, jca, messaging and
ejb3". The profile service selects the MC beans that will provide such a
profile.
http://www.jboss.org/index.html?module=bb&op=viewforum&f=160
Lead: Emanuel Muckenhuber (and Scott Stark)
@ManagedObject identifies POJOs which have a management view - they
don't have to be registered as MC beans.
http://www.jboss.org/index.html?module=bb&op=viewforum&f=160
Lead: Emanuel Muckenhuber (and Scott Stark)
@ManagedObject <-> MBean is handled by a 'bridge'.
http://www.jboss.org/index.html?module=bb&op=viewforum&f=160
Lead: Emanuel Muckenhuber (and Scott Stark)
> Committing to single platform does make things simpler.
You'll need various layers to deal with container (and kernel) specific
details - in order to run on various EE servers.
> Can you explain your comments on (34)?
>
When Teiid is running as part of the JBoss Application Server it should
use Profile Service) Create the server configuration for the Teiid
platform @ManagedObject) To identify management objects Other servers
uses other mechanisms. You'll have to evaluate each technology before
you bring it in - "do I want a hard dependency on this project ?", "do
the project have the performance profile we need ?", ... Good idea is to
use
http://jboss.org/tattletale/
to get an overview of the projects you are working with - yes, that was
a shame-less plug ;)
I keep the documentation for JBJCA up-to-date for each release here:
http://docs.jboss.org/jca/
But *note*, that certain parts of JBJCA != JBossAS... and there is
still
development to do before the first stable release.
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years, 6 months
metadata changes
by Steven Hawkins
As per a previous email about further cleaning up metadata (primarily the removal of the index connector), I am ready to move forward with the commit set to address TEIID-871 TEIID-792 TEIID-102 TEIID-254 TEIID-869 TEIID-875.
A few notes on the initial changes:
- It leaves out the ODBC OA views - these need more work and can be added back when we add optional support (including the JDBC bridge code) for OA.
- It marginally slows down the unit tests - vdb metadata is fully loaded on first use - the loading is not-optimal and the object model is not cached. Both will be addressed.
- It does not yet change JDBC metadata representation of catalog/schema/table names.
Also this will change the System.vdb. Since the metadata project has forked, the System.vdb will need to be manually added to the Designer metadata project.
Steve
14 years, 6 months
Re: [teiid-designer-dev] Teiid In JCA Container
by John Doyle
I like the vision. I'll need to read all this again and think it through, but I do have a couple of immediate questions and thoughts.
Has there been any discussion concerning how these changes effect the attractiveness embedded of Teiid? I'm concerned that it will be less attractive in OEM opportunities, and not necessarily in any specific technical sense, but that it's more 'heavyweight' because it requires a container.
I know you mentioned JBJCA for future embedded deployments, can that replace all the services of the container or our current implementations, or would there be some loss of functionality?
I need to read up on JCA, but there are some unique connection management concerns with the SalesForce connector (close one and they all close) that might have to be resolved.
Thanks for writing this up, this is just the kind of detail I need to see to really understand the future vision of Teiid and see the implications.
~jd
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> Following through the 6.3
> features(http://lists.jboss.org/pipermail/teiid-dev/2009-September/000218...,
> I have taken time to write a simple proof of concept prototype of JCA
> based Teiid use case using JBoss Embedded container. The results have
> been very positive.
>
> I have put together my brain dump on this subject as
> requirements/design
> document. Please take time to read, as this proposes a shift in Teiid
> architecture that affects all areas of Teiid.
>
> http://www.jboss.org/community/wiki/TeiidInJCAContainer
>
> If you would like keep up with progress of this project watch
> https://jira.jboss.org/jira/browse/TEIID-833
>
> Please let me know if you have any suggestions and comments to make
> this
> even better.
>
> Thank you.
>
> Ramesh..
>
>
>
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 6 months
Re: [teiid-designer-dev] [teiid-users] removing system physical
by Ramesh Reddy
Designer also uses the System.vdb, are there implications there? I am
not sure what is Designer's usage pattern. Seem though, Designer does
not need to depend on it. Somebody please explain, how it is being used
in the Designer?
On Thu, 2009-10-08 at 17:27 -0400, Steven Hawkins wrote:
> Hello all,
>
> I would like to float the idea of removing SystemPhysical from the 6.3 release and converting System to a physical model. System as a virtual model needlessly introduces lookup tables and joins between the SystemPhysical tables. Also SystemPhysical is filled with a lot of modeling and indexing concepts that would be best not to expose. Since SystemPhysical is marked as non-visible, not documented for use (from within transformations), and has all of its relevant information exposed through System anyway the impact and potential workarounds for this removal are minimal. Let me know if there are any concerns.
>
> Steve
> _______________________________________________
> teiid-users mailing list
> teiid-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-users
14 years, 6 months
