1:06 p.m.
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
3:58 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
- --
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJem2EACgkQcthLMIwdEb0v9ACg3bv5m73BtOt638x2F6D5xOQX
h10AoKYmYnx1Q8jTEhCeVf0T4kMasduJ
=MZkj
-----END PGP SIGNATURE-----
12:06 p.m.
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:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
>
- --
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJem2EACgkQcthLMIwdEb0v9ACg3bv5m73BtOt638x2F6D5xOQX
h10AoKYmYnx1Q8jTEhCeVf0T4kMasduJ
=MZkj
-----END PGP SIGNATURE-----
################
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
1:13 p.m.
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
2:37 p.m.
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(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
3850
days inactive
3852
days old
jbosstools-dev@lists.jboss.org
4 comments
3 participants
participants (3)
-
Max Rydahl Andersen -
phantomjinx -
Rob Stryker