Re: [jbosstools-dev] ASTools Refactor (as always), advice required from consumers!

Thanks! The list of drivers is found when deploying a datasource to the teiid instance. Specifically, only for JDBC we do the following: 1. Get the 'driver-class' property from the connection profile 2. Interrogate the list of jboss installed drivers for the driver-class 3a. If there is a match to the driver-class then create the datasource 3b. No match then attempt to deploy the drivers using teiid instance from the jar-list contained in the connection profile So, we actually take the jdbc drivers from the user-created connection profile and deploy them as well as the data source, avoiding the separate activity of deploying these drivers on the teiid instance. Not sure whether this would help you. The connection profile points to a database, configured with a driver, eg. oracle. That driver is not distributable and the user will have added it in their own work. We take that driver and deploy it to teiid/jboss if not already installed. Regards PGR On 10/18/2013 11:06 AM, Max Rydahl Andersen wrote: > nice report. > > May I ask what you actually do with the response from list of drivers installed ? > > Do you actually somehow use them from eclipse or how ? > > asking since i've been pondering if we shouldn't get all the datasources configured on servers made > automatically or at least easily available from within eclipse wtp - that would be useful in many places. > > /max > > On Wed, Oct 16, 2013 at 02:58:04PM +0100, phantomjinx wrote: > Hey Rob, > > I would be especially interested in the split into systems and subsystems, > since Teiid is installed as a subsystem on JBoss. > > The summary of Designer's requirements: > > * Querying the JBoss server for Teiid support and its requisite components > > * Adapting an IServer instance to a JBoss7Server instance and then adapting that > to an ITeiidServer model, appending to the IServer's tree in the Server view > > The details of Designer's current requirements are attached. > > Cheers > > PGR > > On 10/16/2013 12:06 PM, Rob Stryker wrote: > >>> Hi All: > >>> > >>> OPENSHIFT, TEIID DESIGNER, CENTRAL, and others.... HEAR ME! > >>> > >>> I'm working on drawing out the beginning plans of a somewhat large refactor to astools, > >>> specifically to server behavior (module start / stop, deploy, server start / stop, management > >>> commands, etc). > >>> > >>> What I need from you all is a comprehensive list of how you're all interacting with astools as > >>> of now, and what things you'd LIKE to see in the future. This will be a major version bump when > >>> complete, and while I will do my best to not severely break api, I will. I know I will, because > >>> it's about time thats been done and the old cruft gets cleaned. > >>> > >>> Obviously existing servers will continue to function. That would be a critical breakage and > >>> even I won't do that, but, I would like to make all consumers of astools' migrations as easy as > >>> possible. > >>> > >>> Even though most of these changes will be to classes that should have been internal but never > >>> were, the changes will necessarily bleed into utility classes etc. I'll do my best to avoid > >>> that, but it's not always possible. > >>> > >>> The idea here is to split the server behavior into systems and subsystems, with different > >>> implementations that can be mixed and matched. > >>> > >>> How far this refactor goes depends on how you guys are using astools currently. Odds are most > >>> of the changes will be to internal stuff, but that's the problem, since astools never had > >>> properly hidden internal packages. So odds are you're all reaching in and using code all over > >>> the place. > >>> > >>> If you don't tell me what you're using now, odds are I'll break it with impunity. If you do > >>> tell me, I'll try my best to keep those classes and methods there, mark them as deprecated, > >>> provide helpful javadoc for transitioning, and, in the very end, once everyone converts, I'd > >>> clean up the cruft. But, if you dont tell me, I'll probably break you when I commit it, and it > >>> won't be my fault ;) > >>> > >>> (If we're being honest, I'll probably break you a little even if you do tell me, but that'll be > >>> my fault, not yours) > >>> > >>> The current ideas for systems is: publish, moduleController, serverState (previously > >>> pollers), startup, shutdown, etc. I'm also trying to work in the idea of extenders able to > >>> contribute their own systems or subsystems for various configurations or server types, but I'm > >>> not at that point yet. I am at the point, though, where my desired new interfaces conflict with > >>> the old poorly designed ones. > >>> > >>> Things to tell me that you depend on: 1) Internal Classes 2) CONSTANTS > >>> (IJBossToolingConstants.xyz, or others) 3) API classes 4) depending on server mode (local vs > >>> rse) 5) basically everything which could break > >>> > >>> Most string constants will not change, but their LOCATIONS might change, as many should be > >>> internal but aren't. > >>> > >>> Anyway, consider this the 'gathering requirements' phase. Let me know, or bear the > >>> consequences! > >>> > >>> - Rob Stryker I cause problems _______________________________________________ jbosstools-dev > >>> mailing list jbosstools-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > >>> > > >> ################ Use of org.jboss.ide.eclipse.as plugins in Teiid Designer ###################### >> >> org.teiid.8.4.x >> org.teiid.8.3.x >> * ExecutionAdmin - Querying the datasource subsystem for the list of installed drivers >> ** Constant ModelDescriptionConstants.OP >> ** Constant ModelDescriptionConstants.OP_ADDR >> ** Constant ModelDescriptionConstants.SUBSYSTEM >> ** Constructs new AS7ManagementDetails >> ** JBoss7ManagerUtil.getService >> >> >> org.teiid.designer.dqp >> * TeiidServerAdapterFactory - Adapting an IServer to an ITeiidServer. The IServer is adapted to either >> a JBossServer or JBoss7Server and these are queried for teiid subsystem >> ** IServer.loadAdapter(JBoss7Server.class, null) >> ** IServer.loadAdapter(JBossServer.class, null) >> ** JBoss7Server.getManagementPort() >> ** JBoss7Server.getUsername() >> ** JBoss7Server.getPassword() >> >> * JBossServerUtil - Utility methods for requesting information from pre-7 jboss server >> ** JBossServer.getHost() >> ** JBossServer.getJBossWebPort() >> >> * JBoss7ServerUtil - Utility methods for requesting information from jboss 7 server using json model node requests >> ** Constant ModelDescriptionConstants.NAME >> ** Constant ModelDescriptionConstants.READ_ATTRIBUTE_OPERATION >> ** Constant ModelDescriptionConstants.READ_CHILDREN_NAMES_OPERATION >> ** Constant ModelDescriptionConstants.SUBSYSTEM >> ** Constant ModelDescriptionConstants.CHILD_TYPE >> ** Constant ModelDescriptionConstants.SOCKET_BINDING_GROUP >> ** Constant ModelDescriptionConstants.SOCKET_BINDING >> ** Constant ModelDescriptionConstants.OP_ADDR >> ** Constant ModelDescriptionConstants.PORT >> ** Constructs new AS7ManagementDetails >> ** Constructs new ModelNode >> ** ModelNode.toJSONString(boolean) >> ** ModelNode.fromJSONString(String) >> ** ModelNode.asList() >> ** ModelNode.asString() >> ** ModelNode.get(String) >> ** ModelNode.add(String, String) >> ** ModelNode.set(String) >> ** JBoss7ManagerUtil.getService >> ** JBoss7Server.getServer() >> ** JBoss7Server.getHost() >> ** JBoss7Server.getManagementPort() >> >> org.teiid.designer.dqp.ui >> * TeiidServerContentProvider - Use of the org.jboss.tools.as.wst.server.ui.xpl.ServerToolTip >> ** Constructs new ServerToolTip for each node in Teiid Server tree >> ** ServerToolTip.deactivate() >> ** ServerToolTip.activate() >> ** ServerToolTip.setShift(Point) >> ** ServerToolTip.setPopupDelay(int) >> ** ServerToolTip.setHideOnMouseDown(boolean) > >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- Paul Richardson * p.g.richardson(a)phantomjinx.co.uk * p.g.richardson(a)redhat.com * pgrichardson(a)linux.com "I know exactly who reads the papers ... * The Daily Mirror is read by people who think they run the country. * The Guardian is read by people who think they ought to run the country. * The Times is read by people who do actually run the country. * The Daily Mail is read by the wives of the people who run the country. * The Financial Times is read by the people who own the country. * The Morning Star is read by the people who think the country ought to be run by another country. * The Daily Telegraph is read by the people who think it is." Jim Hacker, Yes Minister