[
https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin....
]
Ladislav Thon commented on WFLY-5850:
-------------------------------------
[~brian.stansberry] I think I understand what you're saying, but it seemed a bit
counterintuitive to me at first. So I think we must document this clearly. Here's my
take:
bq. Using the {{:migrate}} mgmt operations, you're able to move your EAP 6
configuration files to WildFly 10. Still, after the migration, the configuration files
will reflect the original EAP 6 configuration (e.g. {{remoting}} protocol instead of
WildFly's new {{http-remoting}}, port numbers, etc.) and will not contain new EE7
subsystems nor new WildFly features (e.g. batch processing, clustered singleton
deployments or graceful shutdown). To bring your configuration files fully up to date,
while keeping the essential EAP 6 configuration, you must use the WildFly Server Migration
tool.
Would something like that work for you? (I think that we should use a similar text in EAP
7 Migration Guide, for which I will create a separate JIRA once we get an agreement
here.)
Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
----------------------------------------------------------------
Key: WFLY-5850
URL:
https://issues.jboss.org/browse/WFLY-5850
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Ladislav Thon
Assignee: Stuart Douglas
Priority: Critical
Fix For: 10.1.0.Final
I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly
10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
{code}
git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
cd jboss-eap-quickstarts/
git checkout -b 6.4.x origin/6.4.x
cd ejb-remote/server-side/
mvn clean package -s ../../settings.xml
cd target
unzip .../jboss-eap-6.4.0.zip
unzip .../wildfly-10.0.0.CR4.zip
cp jboss-eap-6.4/standalone/configuration/standalone.xml
wildfly-10.0.0.CR4/standalone/configuration/test.xml
./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
# on a separate console
./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
/subsystem=threads:remove
/extension=org.jboss.as.threads:remove
/subsystem=web:migrate
shutdown
# on the original console
cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
{code}
What I get is this horrible stack trace:
{code}
15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001:
Failed to start service
jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE:
WFLYSRV0153: Failed to process phase POST_MODULE of deployment
"jboss-ejb-remote-server-side.jar"
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
[wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
[jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
[jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_66]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_66]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
Caused by: javax.validation.ValidationException: Unable to create a Configuration,
because no Bean Validation provider could be found. Add a provider like Hibernate
Validator (RI) to your classpath.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
at
org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[rt.jar:1.8.0_66]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
[rt.jar:1.8.0_66]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[rt.jar:1.8.0_66]
at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
at
org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
at
org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
at
org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
[wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
... 5 more
15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot
Thread) WFLYCTL0013: Operation ("deploy") failed - address:
([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure
description: {"WFLYCTL0080: Failed services" =>
{"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE"
=> "org.jboss.msc.service.StartException in service
jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE:
WFLYSRV0153: Failed to process phase POST_MODULE of deployment
\"jboss-ejb-remote-server-side.jar\"
Caused by: javax.validation.ValidationException: Unable to create a Configuration,
because no Bean Validation provider could be found. Add a provider like Hibernate
Validator (RI) to your classpath."}}
{code}
When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine.
This suggests that something (probably the EJB subsystem?) doesn't correctly
parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)