WFLY-2422 or simplifying the remote outbound connection configuration for server to server communication
by Wolf-Dieter Fink
I start a request for simplifying the configuration for "in EE
application" clients and get rid of extra cluster configuration and
repeat properties many times.
Also the client should not need to have knowledge about the server
topology, there is no need to know how many servers there are or whether
they are clustered or not.
Starting point in EAP6/WF8 is a application configuration like this:
https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-ma...
and a server side configuration like this:
<subsystem xmlns="urn:jboss:domain:remoting:3.0">
<endpoint worker="default"/>
<http-connector name="http-remoting-connector"
connector-ref="default" security-realm="ApplicationRealm"/>
<outbound-connections>
<remote-outbound-connection
name="remote-ejb-connection-1"
outbound-socket-binding-ref="remote-ejb-1" username="quickuser1"
security-realm="ejb-security-realm-1" protocol="http-remoting">
<properties>
<property name="SASL_POLICY_NOANONYMOUS"
value="false"/>
<property name="SSL_ENABLED" value="false"/>
</properties>
</remote-outbound-connection>
<remote-outbound-connection
name="remote-ejb-connection-2"
outbound-socket-binding-ref="remote-ejb-2" username="quickuser2"
security-realm="ejb-security-realm-2" protocol="http-remoting">
<properties>
<property name="SASL_POLICY_NOANONYMOUS"
value="false"/>
<property name="SSL_ENABLED" value="false"/>
</properties>
</remote-outbound-connection>
</outbound-connections>
</subsystem>
Tomasz did some refactoring (WF9) to use a profile from the application
perspective. The configuration is like this:
jboss-ejb-client.xml
<client-context>
<profile name="main-app"/>
</client-context>
server profile:
<remote connector-ref="http-remoting-connector"
thread-pool-name="default">
<profiles>
<profile name="main-app">
<remoting-ejb-receiver name="AppOneA"
outbound-connection-ref="remote-ejb-connection-1"/>
<remoting-ejb-receiver name="AppTwoA"
outbound-connection-ref="remote-ejb-connection-2"/>
</profile>
</profiles>
</remote>
....
<subsystem xmlns="urn:jboss:domain:remoting:3.0">
<outbound-connections>
<remote-outbound-connection
name="remote-ejb-connection-1"
outbound-socket-binding-ref="remote-ejb-1" username="quickuser1"
security-realm="ejb-security-realm-1" protocol="http-remoting">
<properties>
<property name="SASL_POLICY_NOANONYMOUS"
value="false"/>
<property name="SSL_ENABLED" value="false"/>
</properties>
</remote-outbound-connection>
<remote-outbound-connection
name="remote-ejb-connection-2"
outbound-socket-binding-ref="remote-ejb-2" username="quickuser2"
security-realm="ejb-security-realm-2" protocol="http-remoting">
<properties>
<property name="SASL_POLICY_NOANONYMOUS"
value="false"/>
<property name="SSL_ENABLED" value="false"/>
</properties>
</remote-outbound-connection>
</outbound-connections>
</subsystem>
With the current implementation there are some issues or
concerns/enhancements
- profile does not work with clusters
- not possible to have multiple profiles
- the properties/user must be still repeated
From my point of view
- a cluster need to have the same property configuration, also different
users make no sense. Might work, but at least the cluster view will use
the same user
- a similar group of servers for the same application should not have
different properties/users as this will be error prone
- configuration should be as small and intuitive as possible
My initial idea was to have a jboss-ejb-client.xml which reference
'applications' to connect, that is similar to profiles
The server side as followed (don't care about the exact XML elements or
names)
<subsystem xmlns="urn:jboss:domain:remoting:3.0">
<outbound-connections>
<profile name="App1" username="quickuser1"
security-realm="ejb-security-realm-1" protocol="http-remoting">
<properties>
<property name="SASL_POLICY_NOANONYMOUS"
value="false"/>
<property name="SSL_ENABLED" value="false"/>
</properties>
<outbound-sockets>remote-ejb-1,remote-ejb2</outbound-sockets> <!--
repeated elements seems better -->
</remote-outbound-connection>
<remote-outbound-connection
name="remote-ejb-connection-X"
outbound-socket-binding-ref="remote-ejb-X" username="quickuser2"
security-realm="ejb-security-realm-2" protocol="http-remoting">
<properties>
<property name="SASL_POLICY_NOANONYMOUS"
value="false"/>
<property name="SSL_ENABLED" value="false"/>
</properties>
</remote-outbound-connection>
</outbound-connections>
</subsystem>
In this case the profile use the user/security and properties for all
connections and the cluster as well. In this it is necessary to have the
same configuration for all the servers in the profile-bunch.
Another option I thought about is to use the user/properties in
<profile> as default and have the possibility to use a inner element
remote-outbound-connection, or a reference to remote-outbound-connection
which can override these, but I'm not sure whether this is needed.
We (Tomasz Adamski and me) had a discussion about this and, technically
there is no problem with each approach.
But ...
I know that all the ejb-client stuff is subject to change and to prevent
from incompatible changes which are changed in every version
and from unnecessary work if the code will be changed before it will be
used at all
I think it will need to be discussed with others because of this.
cheers
Wolf
10 years, 6 months
Dropping legacy XSD schemas & its parsers
by Tomaž Cerar
Hi folks,
we discussed on team meeting in Brno about dropping support for old legacy
host controllers
when running in mixed domain mode (having DC of newer version managing
older version HCs)
We also discussed dropping old xsd sachems & parsers as it would help us
cleanup and simplify code
in many subsystems as there are cases where we support and maintain 5 and
more different
versions of parser. For example currently web subsystem has 8, infinispan
7, ejb & jackorb have 6, ...
We still have parsers that that ware shipped back in 7.0.0 and became
obsolete in later 7.0.x releases.
Given that we decided that we are dropping support for running mixed domain
mode for host controller
that are older than 7.3.0 (EAP 6.2) as is tracked by
https://issues.jboss.org/browse/WFLY-3564
I would also like to suggest that we do the same for xml schemas & parsers.
*What is the downside?*
Automatic upgrading from JBoss AS 7.1.x/EAP < 6.2 version with using same
standalone.xml won't work anymore.
User would need to upgrade to WildFly 8.x and from there to 9 or 10
(depending when we drop this)
Because of replacement of web subsystem with undertow and introduction of
few other subsystems (io, SM)
this already doesn't work for 7.x-->8+, but we do have plans how to improve
that.
So, are there any objections against this?
--
Tomaž
10 years, 7 months
Proposal for improving handling complex types in CLI
by Tomaž Cerar
Hi guys,
there ware some discussions on how we should improve handling complex types
of attribute bit better in CLI.
For most part that was about Map & List types.
After some discussions with few of you I came up with plan / ideas what all
options are there for us to improve on.
you can see current state of proposed enhancements at
https://gist.github.com/ctomc/91055a6f4e7502dcd130
In short, I propose to add set of map-* and list-* global operations and
improve :read-attribute & :write-attribute
with EL like syntax for reading / updating map, list and generic complex
attributes.
Let me know what you think about it, especially Console & CLI folks.
--
tomaz
10 years, 9 months
WildFly 9 Beta on OpenShift
by Farah Juma
The OpenShift WildFly cartridge has now been updated to provide support for WildFly 9 Beta in addition to the existing support for 8.2.0.Final. Since JDK 8 is now available on OpenShift Online, the WildFly cartridge has been updated to use it directly instead of installing JDK 8 during instance creation. As a result, you should now notice slightly faster instance creation times and there is more quota available for your app.
For details on how to get started with the Beta release, check out the documentation here:
https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/...
Enjoy!
10 years, 10 months
WFLY-4169 Wildfly doesn't fail on deployment EJB with CDI @Transactional
by Eduardo Sant´Ana da Silva
I'm looking at this issue:
https://issues.jboss.org/browse/WFLY-4169
In the ejb-3_2 specification :
It is illegal to associate JTA transactional interceptors (see [8]) with
Enterprise JavaBeans. The EJB Container should fail deployment of such
applications.[39]
@Transaction annotation was introduced in JTA 1.2,
As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it was introduced on
Wildfly since version WildFly 8.0.0.Beta1, what should be done?
Because this restriction could be removed in the future versions:
[39] This restriction may be removed in a future release of this
specification
If this is needed, how to proceed? Should be done on Weld subsystem,
something similar with the annotations markers, just to log the problem or
it will be more tricky, since the deployment should be rolled back (by the
specification)?
--
__________________________
Eduardo Sant'Ana da Silva
10 years, 10 months
How does clustering and session replication work in wildfly?
by Norbert Bányai
Hi,
I'm Norbert Bányai a graduate student at University of Debrecen from
Hungary. I write my thesis about clusters and load-balancing.
I have already set up a cluster working fine, so my question is the next
(as already mentioned in the subject field):
How does the clustering and session replication work in Wildfly?
I would highly appriciate any information. I believe every pinch of new
information would be a great help. Thank you in advance. :)
Yours sincerely,
Norbert Bányai
10 years, 10 months
Preparation for requirements and capabilities.
by Darran Lofthouse
Assuming the title still covers the scenarios I have in mind is there
anything we can be doing now to prepare for requirements and
capabilities support to make transitioning easier once it is available.
As an example within Elytron we will have a number of services that
define either standard types or types defined by API that we want to
inject - is there anything we can do today for subsystems that want to
say "I want a type X, named Y injected here" whilst minimising
interaction with and knowledge of the Elytron subsystem.
Secondly is there anything we can do at the model level regarding
assisting the user with referential integrity, as an example say I am
writing an attribute using the CLI called 'keystore', this is going to
be a reference to a named KeyStore - how about some form of op
associated with that attribute that can dynamically generate the list of
accepted values on demand, e.g. by querying the model and finding out
which KeyStores are actually available.
Regards,
Darran Lofthouse.
10 years, 10 months
