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
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
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
Question on frozen management client
by Rob Stryker
Hey All:
I've been trying to dig into this for a while but really haven't gotten
very far. Glance at https://issues.jboss.org/browse/JBIDE-19641
It seems our client (jbosstools) appears to have frozen while sending a
large war over mgmt api for deployment. Unfortunately, looking at the
stacks doesn't show anything strange. In fact, it seems the transfer is
still in effect. However, our user indicates that disk activity (ie
transfer) has ceased, and yet the client jar classes have not indicated
the transfer was done or aborted.
The class we use to perform the mgmt publish is
https://github.com/jbosstools/jbosstools-server/blob/master/as/plugins/or...
It's pretty simple, but QE is indicating it freezes and after a short
while, nothing happens.
I was wondering if anyone here might have any insight? QE indicates
the transfer works fine over jboss-cli, but not in jbt.
Thanks in advance.
- Rob Stryker
9 years, 5 months
Capabilities and Requirements - Common Definitions
by Darran Lofthouse
Following on from PR https://github.com/wildfly/wildfly-core/pull/757
and my final comment in the PR we need to have a discussion on how we
coordinate capability and requirement definitions - especially where
multiple components need a common definition.
The first option is to do it all by convention and have no shared
constants, the down side of this is we now need to document this and
keep the document maintained. A document would also make it hard in the
future to flag certain capabilities as deprecated if preferred
alternatives are made available.
The second option would be to just define the Strings somewhere and use
Javadoc to specify if the capability is dynamic and it's service type.
The third option is defining the string and RuntimeCapability instances
in a central place so they can both be referenced as needed.
Any other options?
Where these live will be a second point to discuss but that is heavily
driven based on what we will share in the first place.
Regards,
Darran Lofthouse.
9 years, 5 months
HTTP API support for plain JBoss-CLI commands
by Jairo Junior
I've been working on a Puppet Module for Wildfly [1] that uses his HTTP
Management API to perform operations (manage resources/deploys and execute
commands), but my command execution code is a little bit limited cause I
have to transform from CLI syntax to JSON. e.g.:
:shutdown(restart=true)
becomes
{"operation" : "shutdown", "restart" : "true" }
Is there any specific reason to not support plain CLI commands through HTTP
API? I looked at the code and it didn't see hard to implement this...
[1] https://github.com/biemond/biemond-wildfly
9 years, 5 months
10.0.0.Alpha2 released & 9 status update
by Jason Greene
Hello Everyone,
WildFly 10.0.0.Alpha2 and WildFly Core 2.0.0.Alpha3 are released.
As a reminder, we are doing bi-weekly alpha releases of full, and weekly of core. Due to the high frequency, I am currently not publishing them to the website, so that it does not clutter the WildFly download page.
I plan to redesign the download site in the coming weeks to better fit this new approach.
In the meantime, you can download the Alpha stream from maven:
https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/w...
Next week we are hoping to release 9 CR2. The last blocker is an issue with IIOP shutdown (requires a Naryana update). If all goes well it will be the last CR.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
9 years, 5 months
