[jbosstools-dev] ASTools Refactor (as always), advice required from consumers!
Max Rydahl Andersen
manderse at redhat.com
Fri Oct 18 08:37:21 EDT 2013
If i understand that right this is the opposite direction (deploying DTP connection profile in eclipse *to* JBoss)
which in itself is interesting to do too for sure.
Optimally what I could find nice is that when we start a server we would have a way to keep the server side datasources
in "sync" with DTP connection profiles....but I don't know how to get the driver jar from the server in a reliable fashion.
/max
On Fri, Oct 18, 2013 at 12:13:18PM +0100, phantomjinx wrote:
>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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
>--
>
>Paul Richardson
>
> * p.g.richardson at phantomjinx.co.uk
> * p.g.richardson at redhat.com
> * pgrichardson at 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
>
>
More information about the jbosstools-dev
mailing list