[
https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin....
]
Brian Stansberry commented on WFLY-5850:
----------------------------------------
Yes, text like that makes sense to me.
I think any documentation of the subsystem :migrate ops outside of any migration guide
should be fairly low key and should start with text that drives people toward a migration
guide. And text like yours above is a good part of that. I don't consider these
:migrate ops to be internal details, but directly using them is a bit of an advanced use
case, and our docs should not be steering the ordinary user toward direct use without
first steering them toward the migration tool.
A bit of further explanation just FYI:
To have the server itself bring in new subsystems like batch-jberet, etc, there would have
to be a *kernel* level :migrate op, as opposed to the current subsystem level ones. And
that would present a number of problems:
1) It's contrary to the architecture of WildFly, as it entails the kernel having a lot
of complex knowledge about subsystem details. What are the new extensions? When were they
"new"? How do they relate? What's the default config for each that should be
added? Does one new one require another new one? Either we hard code that data in the
kernel, which would be a maintenance nightmare plus would not cover extensions unknown to
us, e.g. other dists built on WildFly Core, including non-EAP Red Hat products; or we
impose a new requirement on extension authors to provide the kernel with ??? needed data.
Without breaking the Extension SPI. And then run around policing those extension authors
to get them to comply with what will certainly be a low priority for them.
2) The existing subsystem :migrate ops are owned by the legacy subsystems. Those subsystem
are legacy, and therefore essentially fixed in what they offer. So, we write those ops
once, and then largely leave them alone. Perhaps enhance them a bit if we find ways to
migrate stuff that previously we could only warn about. Conceptually simple.
A kernel :migrate op would be completely different. It would encompass the entire
distribution. It's never stable, it's always moving. Anything at all we miss is
arguably a bug.
A bespoke external migration tool need not have these problems. It can be built for a
custom, clearly documented purpose, perform that purpose well, and clearly not be useful
for unrelated purposes.
All this, BTW, is an argument against trying to merge the migration tool into the CLI. On
the surface it sounds great to just have one tool, but bolting custom purpose tools onto a
general purpose tool like the CLI is likely to lead to a lot of problems.
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)