WFLY-4200 WAR MDB cannot obtain superclass on module classpath
by Eduardo Sant´Ana da Silva
I was looking at :WFLY-4200 WAR MDB cannot obtain superclass on module
classpath
This is what I posted about it:
"I believe that the problem is because
AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the
parse phase:
Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS
Since the dependencies will be resolved at Phase.DEPENDENCIES, your build
will not work.
Regarding WFLY, my suggestion is not throw the
EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass)
only bring up some flag that the required interfaces were not yet resolved,
some attachment could be useful, just to retain the super class name. When
the dependencies were solved, the class will be present on the class index
and the test against the annotation should be performed again. Since that
work will be done twice, to verify the required interfaces, this requires
some experts advice."
Thanks,
--
__________________________
Eduardo Sant'Ana da Silva
8 years, 11 months
SimpleRoleGroup#roles
by Philippe Marschall
Hi
I’m aware this may no technically be the right list to discuss this but
this list is impacted by this and fairly active.
During load testing of our application we found a case we spend 10% of
your CPU time in SimpleRole#equals (see attachment). This is because
SimpleRoleGroup uses an ArrayList to maintain a unique set of roles. As
a result it has to call ArrayList#contains a lot, which is itself O(n).
In fact because that’s done when iterating over all the roles it becomes
O(n^2). In our case our principals can have up to 200 roles. I don’t
know if this is exceptionally many or a common case.
We would like to work on a patch but we need your guidance. There are
several possible solutions and it all comes down to whether we can
change the List in the RoleGroup interface to a Collection. All the
users we searched for in WildFly only used the return value for
iterating over, nobody used the index. In fact they all used it an a
for-each loop so the change would even be source compatible but
unfortunately not binary compatible. If we can change the interface then
we can just change the ArrayList in SimpleRoleGroup to a HashSet and be
done with it. If the order is important the we can either use a TreeSet
or a LinkedHashSet.
If changing the RoleGroup interface is not possible then there are two
other possibilities. The first is only internally using a Set but in
getRoles perform a copy. This would produce more garbage. The second
option would be a having a Set and List (to avoid having to do copies)
in SimpleRoleGroup. This would avoid having to do a copy and the Set can
be used for contains checks. Only removeRole would still be O(n) due to
the scan over ArrayList. The only user we found was
OptionsRoleMappingProvider.
All of these would change the serialized form. If it is important to
support reading old instances that could be added as well.
Cheers
Philippe
8 years, 12 months
Using a custom module to preview "next-gen" Hibernate versions on WildFly 9
by Sanne Grinovero
Hi all,
I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1
to use a preview of Hibernate ORM version 5.
It seems the JPA deployer isn't allowing me to run such experiments:
# First experiment - providerModule set to custom module
In my first attempt, I create a custom set of jboss modules which
include the snapshot builds of ORM 5, add them to my standalone WF9
instance and set the persistence.xml property:
jboss.as.jpa.providerModule = my-custom-module-name
and then get:
Caused by: java.util.ServiceConfigurationError:
org.hibernate.integrator.spi.Integrator: Provider
org.hibernate.envers.boot.internal.EnversIntegrator not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51]
at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51]
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
[rt.jar:1.7.0_51]
at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51]
at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341)
at org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57)
at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188)
at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45)
at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57)
at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38)
at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173)
at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243)
at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60)
at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118)
... 7 more
Clearly it looks like I'm being served classes from the bundled
Hibernate 4.x implementation - on top of those from the module I'm
requesting. This isn't what the deployer should be doing, right?
# Second experiment - use the "application provided"
In this case I hope to hint the JPA deployer to not add the default
implementor but look for a JPA implementation within my deployment,
but still package my custom Hibernate build as a module.
- use the same custom module containing Hibernate ORM 5 (a preview snapshot)
- Add a "Dependency:" section to the manifest to import (and export)
my custom module
- set the "jboss.as.jpa.providerModule" property to value "application"
This gets me:
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException:
WFLYJPA0027: Persistence provider module load error application (class
org.hibernate.jpa.HibernatePersistenceProvider)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131)
at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
[wildfly-server-1.0.0.CR1.jar:1.0.0.CR1]
... 5 more
Caused by: org.jboss.modules.ModuleNotFoundException: application:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
[jboss-modules.jar:1.4.3.Final]
at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978)
... 10 more
Remarks:
- it's attempting to load the "application:main" module?! that's not
what I'd expect from reading [1]
- the provider should be available to the deployment classpath, so
I'm not sure why it's not finding the Provider? (I'm even exporting
it, although I'm not sure if that was required).
Any suggestions to get this running please?
Also I wonder if some of these should warrant opening a JIRA, but I'm
not sure how far I misunderstood the intentions of these JPA deployer
properties.
Thanks,
Sanne
[1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere...
9 years, 3 months
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
9 years, 4 months
Wildfly start-up as service script depends on console log to determinate start result
by Chao Wang
Hi all,
The Wildfly start-up as service scripts wildfly-init-redhat.sh and
wildfly-init-debian.sh currently depend on a grep action of key message
'WFLYSRV0025:' in console log to determinate whether service start is
successful. The log message indication is accurate, however, it's not
that robust since user can always remove console handler from logging
subsystem. I have opened a WFCORE enhancement jira
https://issues.jboss.org/browse/WFCORE-747 for it.
For the moment, I have tried three options, they're all not that perfect
to implement
1. Stay with exact log message, users need to define their jboss log
directory such as $JBOSS_HOME/standalone/log/server.log for standalone
and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
searching in console log. This is more like another workaround since it
is also volatile once we update log message in future release.(EAP has
'JBAS015874:')
2. Use service pid, this is not precise because a long start-up can
crash in the last second. It needs to wait a suitable seconds before
checking pid existence. and still it can not avoid fake success in rare
case just before timeout.
3. Use read-attribute server-state through CLI connection as I did in
Pull Request on Jira. This is declined as it is possible that
authentication is required before connection. In such case, any non
encrypted password is not advised in configuration files.
Therefore, I would like to listen for your opinions for them. Any other
suggestion is certainly welcomed in mail or on jira.
Best regards,
Chao
9 years, 4 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ž
9 years, 4 months
WFLYCTL0218: A node is already registered at '/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc'
by Frank Langelage
I have a Deja-Vu, I'm very I saw this some months ago. Not it reappears.
Possibly due to the commit #7605 with changes for "WFLY-4429 Refactor
JCA subsystem".
26.06. 00:25:37,390 INFO
[org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer#deployXADataSource]
IJ020018: Enabling <validate-on-match> for
java:jboss/datasources/maj2e-langfr-dev
26.06. 00:25:37,445 INFO
[org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001:
Bound data source [java:jboss/datasources/DefaultDS]
26.06. 00:25:37,501 INFO
[org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue]
IJ020018: Enabling <validate-on-match> for
java:/eis/maj2e-langfr-dev/ControllerConnector
26.06. 00:25:37,509 INFO
[org.jboss.as.connector.deployment#bindConnectionFactory] WFLYJCA0007:
Registered connection factory java:/eis/maj2e-langfr-dev/ControllerConnector
26.06. 00:25:37,514 INFO
[org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue]
IJ020002: Deployed:
file:/mbi/tools/jboss/10.0/standalone/tmp/vfs/temp/temp91b455ac091637f0/content-9d63fac1b393fd1c/contents/
26.06. 00:25:37,801 INFO
[org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001:
Bound data source [java:jboss/datasources/maj2e-langfr-dev]
26.06. 00:25:37,990 ERROR [org.jboss.msc.service.fail#startFailed]
MSC000001: Failed to start service
jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics:
org.jboss.msc.service.StartException in service
jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics:
Failed to start service
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: WFLYCTL0218: A node is
already registered at
'/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc'
at
org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:147)
at
org.jboss.as.connector.services.datasources.statistics.DataSourceStatisticsService.start(DataSourceStatisticsService.java:83)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
9 years, 4 months
Capability naming conventions
by Brian Stansberry
The capability and requirement stuff[1] is far enough along that real
usage is happening, so actual capability names are being created.[2] I
wanted to get some input regarding naming conventions for capability
names so it doesn't devovle into chaos, and so I don't end up making up
a lot of names people hate.
The key thing is capabilities need to be namespaced to avoid collisions
between capability creators. Beyond that the names should be "good",
whatever that means (user friendly, properly targeted, not overly tied
to implementation, etc).
My initial thinking on this was:
1) The WildFly family projects own the "org.wildfly" namespace. So all
capabilities we create fit in that namespace, and no one else puts
things there. This I think is a must.
2) Capabilities not used by or provided by the WildFly kernel go in
subspace org.wildfly.extension.<name_of_extension>. Idea there was just
to avoid naming collisions between different extensions.
I don't think 2) is such a great idea any more. A given capability be
provided by more than one extension, so there isn't a clean conceptual
mapping. And the word "extension" is really an implementation detail.
So, I'm inclined to drop the "extension" bit.
Any thoughts on this, or other aspects of how to name capabilities?
FYI, see [3] for some names of capabilities that will be used by the kernel.
[1] The "Runtime" aspect of https://developer.jboss.org/docs/DOC-52712
[2] https://github.com/wildfly/wildfly/pull/7596
[3] https://developer.jboss.org/docs/DOC-53383
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 4 months
Wildfly 9 BOM changes
by Thomas Segismont
Hi everyone,
While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed
that the Wildfly BOM now declares provided scope for some dependencies.
I guess the goal is to help users which forget to set the provided scope
in their POM to end up with all the libraries in their WAR.
On the other hand, if you use some libraries in your tests, then
dependency resolution can be broken. For example, if you add
org.jboss.resteasy::resteasy-client in test scope, your tests fail due
to a missing class from commons-io, because commons-io should be
resolved as a transitive dependency of
org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided,
instead of test.
Have you considered this use case? Are there other motivations than
helping Maven beginners?
Best regards,
Thomas
9 years, 4 months
