[JBoss JIRA] (WFLY-4271) Wildfly BOM wrong dependencies
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4271?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4271:
-----------------------------
Fix Version/s: 9.0.0.Final
> Wildfly BOM wrong dependencies
> ------------------------------
>
> Key: WFLY-4271
> URL: https://issues.jboss.org/browse/WFLY-4271
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0.Final, BOM org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final
> Reporter: Vsevolod Golovanov
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.Final
>
>
> 1. The BOM {{org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final}} (indirectly) imports {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} that has the following dependencies:
> {code}
> <version.io.undertow>1.0.1.Final</version.io.undertow>
> ...
> <dependency>
> <groupId>io.undertow</groupId>
> <artifactId>undertow-servlet</artifactId>
> <version>${version.io.undertow}</version>
> </dependency>
> <dependency>
> <groupId>io.undertow</groupId>
> <artifactId>undertow-core</artifactId>
> <version>${version.io.undertow}</version>
> </dependency>
> {code}
> The version should be 1.1.0.Final. The wrong version ends up being the effective one in dependencyManagement, messes up debugging in Eclipse, and probably compiling in Eclipse.
> 2. {{org.wildfly.bom:jboss-bom-parent:8.2.1.Final}}:
> {code}
> <version.org.hibernate-jpamodelgen>4.3.5.Final</version.org.hibernate-jpamodelgen>
> {code}
> , which affects {{org.wildfly.bom:jboss-javaee-7.0-with-hibernate:8.2.1.Final}}:
> {code}
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-jpamodelgen</artifactId>
> <version>${version.org.hibernate-jpamodelgen}</version>
> </dependency>
> {code}
> Hibernate 4.3.7.Final from SourceForge has jpamodelgen 4.3.7.Final supplied.
> 3. {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} specifies a managed version 3.0.0 for {{org.glassfish:javax.el}}. The actual version supplied with Wildfly 8.2.0.Final is javax.el-3.0.1-b05. Maybe {{resteasy-jaxrs-all}} shouldn't export this managed version at all?
> Hoping for a BOM 8.2.2.Final release, because our project POMs are complex enough without workarounds for such errors.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-856) Error "Null Path" during VFS get virtual file
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-856?page=com.atlassian.jira.plugin.s... ]
Kabir Khan updated WFLY-856:
----------------------------
Fix Version/s: 9.0.0.Final
> Error "Null Path" during VFS get virtual file
> ---------------------------------------------
>
> Key: WFLY-856
> URL: https://issues.jboss.org/browse/WFLY-856
> Project: WildFly
> Issue Type: Bug
> Components: VFS
> Reporter: Zhang Lan
> Assignee: David Lloyd
> Labels: jboss
> Fix For: 9.0.0.Final
>
>
> I have a jar file ,in which have "seam.properties" to load the seam components in it.
> I put the jar file as a module.
> But I got the following error when I start jboss.
> java.lang.IllegalArgumentException: Null path
> at org.jboss.vfs.VFS.getChild(VFS.java:187) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final]
> at org.jboss.vfs.VFS.getChild(VFS.java:173) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final]
> at org.jboss.vfs.VFS.getChild(VFS.java:154) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final]
> at org.jboss.seam.integration.jbossas.vfs.VFSScanner.getRoot(VFSScanner.java:36) [jboss-seam-int.jar:6.0.0.GA]
> VFS.java:187 is following source.
> return getChild(uri.getPath());
> But in my case ,the uri pattern is create by org.jboss.modules.JarFileResourceLoader#getJarURI use the following method.
> return new URI("jar", b.toString(), null);
> It is the [scheme:]scheme-specific-part[#fragment] pattern 's URI.it's path is null.
> So when I change the VFS.java:187 to the following ,my problem is ok.IT's a bug?
> public static VirtualFile getChild(URI uri) {
> if(uri.getPath() != null){
> return getChild(uri.getPath());
> }else{
> return getChild(uri.getSchemeSpecificPart());
> }
> }
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-3661) PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3661?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-3661:
-----------------------------
Fix Version/s: 9.0.0.Final
> PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
> -------------------------------------------------------------------------------
>
> Key: WFLY-3661
> URL: https://issues.jboss.org/browse/WFLY-3661
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 8.0.0.Final
> Reporter: Jess Holle
> Assignee: Kabir Khan
> Fix For: 9.0.0.Final
>
>
> According to the Javadoc on MBeanRegistration.preRegister(), one may register an MBean with a null ObjectName and let the MBean's preRegister() method compute the ObjectName.
> Unfortunately, org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegateForNewObject() violates this contract -- throwing an exception when the incoming ObjectName is null.
> This is a clear bug which breaks numerous JMX MBeans I've authored, which compute their own ObjectNames within preRegister().
> Ideally the result of preRegister would be used as an input to findDelegateForNewObject(), but unfortunately one of the inputs to preRegister() is the MBeanServer, which is, of course, what findDelegateForNewObject() is looking up. Given this circularity, it would seem that findDelegateForNewObject() should simply return rootMBeanServer for null ObjectName inputs. In any case it should not entirely fail to register such MBeans.
> Fortunately, I have a utility wrapper around MBean registration, so I've added the following hack immediately prior to actually registering the MBean to workaround this issue:
> /* Hack to work around JBoss Wildfly bug (https://issues.jboss.org/browse/WFLY-3661).
> This isn't really quite correct, of course, since this means preRegister() will get called twice,
> but it appears to be about the best we can do.
> */
> if ( objectName == null )
> if ( mbean instanceof MBeanRegistration )
> if ( "org.jboss.as.jmx.PluggableMBeanServerImpl".equals( mbeanserver.getClass().getName() ) )
> objectName = ((MBeanRegistration)mbean).preRegister( mbeanserver, objectName );
> where mbeanserver is obtained via ManagementFactory.getPlatformMBeanServer().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-2706) ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2706?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-2706:
-----------------------------
Fix Version/s: 9.0.0.Final
> ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
> ------------------------------------------------------------------
>
> Key: WFLY-2706
> URL: https://issues.jboss.org/browse/WFLY-2706
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: CentOS, OpenJDK7
> Reporter: Andre Pankraz
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Final
>
>
> javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
> "Undertow" and not with JBoss or Wildfly. Is this intentional?
> Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.
> So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?
> I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)
> JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):
> void initServletContext(ServletContext context) {
> assert context != null;
> this.servletContext = context;
> final String serverInfo = servletContext.getServerInfo();
> jboss = serverInfo.contains("JBoss") ;
> glassfish = serverInfo.contains("GlassFish")
> || serverInfo.contains("Sun Java System Application Server");
> weblogic = serverInfo.contains("WebLogic");
> jonas = System.getProperty("jonas.name") != null;
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-3166) can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-3166:
-----------------------------
Fix Version/s: 9.0.0.Final
> can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-3166
> URL: https://issues.jboss.org/browse/WFLY-3166
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Web Console
> Affects Versions: 8.0.0.Final
> Environment: Red Hat Enterprise Linux Server release 5.5
> Reporter: Fai Gao
> Assignee: Stefano Maestri
> Fix For: 9.0.0.Final
>
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but the lable of enabled didn't turn to √(enabled).
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
> "rolled-back" => true
> }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1] ("subsystem" => "datasources"),
> [Server:fserver1] ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]
> I tried in the standalone mode,it worked.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-1621) JPA view in management console is getting "No resource definition is registered for address..."
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-1621?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-1621:
-----------------------------
Fix Version/s: 9.0.0.Final
> JPA view in management console is getting "No resource definition is registered for address..."
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-1621
> URL: https://issues.jboss.org/browse/WFLY-1621
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate, Web Console
> Affects Versions: 8.0.0.Alpha2
> Reporter: Scott Marlow
> Assignee: Heiko Braun
> Fix For: 9.0.0.Final
>
>
> Reported by ehsavoie on IRC:
> {quote}
> <ehsavoie> it looks like wildfly is looking for a "hibernate-persistence-unit" element in the jpa subsystem which creates an error 500 on the jpa tab in the admin console with the standalone default configuration. Shouldn't there be a default working config there ?
> <smarlow> ehsavoie: sounds like a bug, which build of WildFly?
> <ehsavoie> master from this morning
> <ehsavoie> the 500 error: http://fpaste.org/22146/
> <ehsavoie> smarlow: commit b5367674f6b3efb778fee8baa2739ff8fda4b4a5
> <smarlow> ehsavoie: okay, another question, is this with a JPA application deployed?
> <ehsavoie> nope, blank standalone from the build
> <smarlow> ehsavoie: I'll try to recreate after my (master) build finishes. I usually have some JPA application deployed when I use the management console so I probably missed this
> <ehsavoie> smarlow: the error is 'logical' as there are no resource so the context.getFailureDescription().set(MESSAGES.noSuchResourceType(stepAddress)); is not surprising
> <smarlow> ehsavoie: thanks, i reproduced it
> * fharms has quit (Quit: This computer has gone to sleep)
> <ehsavoie> smarlow: you're welcome
> {quote}
> Internal Server Error
> "JBAS014883: No resource definition is registered for address [
> (\"deployment\" => \"*\"),
> (\"subsystem\" => \"jpa\"),
> (\"hibernate-persistence-unit\" => \"*\")
> ]"
> https://gist.github.com/scottmarlow/5902551
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months