[jboss-jira] [JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158275#comment-13158275 ] 

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 at 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)