February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6246) Cannot use corbaname:ssliop protocol to inject remote EJB bean

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created WFLY-6246: ---------------------------------------------- Summary: Cannot use corbaname:ssliop protocol to inject remote EJB bean Key: WFLY-6246 URL: https://issues.jboss.org/browse/WFLY-6246 Project: WildFly Issue Type: Bug Components: IIOP Reporter: Bartosz Spyrko-Śmietanko Assignee: Tomasz Adamski When trying to inject a remote EJB bean using a ejb-jar ejb-ref/lookup-name attribute following exception is thrown: {noformat} Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/statelessHome at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319) at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) ... 202 more Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/statelessHome [Root exception is java.lang.RuntimeException: javax.naming.NamingException: WFLYIIOP0032: Invalid IOR or URL: corbaloc:ssliop:127.0.0.1:3629/NameService [Root exception is org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 603 completed: No]] at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316) ... 213 more Caused by: java.lang.RuntimeException: javax.naming.NamingException: WFLYIIOP0032: Invalid IOR or URL: corbaloc:ssliop:127.0.0.1:3629/NameService [Root exception is org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 603 completed: No] at org.jboss.as.ejb3.deployment.processors.EjbLookupInjectionSource$1.getReference(EjbLookupInjectionSource.java:99) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143) ... 218 more Caused by: javax.naming.NamingException: WFLYIIOP0032: Invalid IOR or URL: corbaloc:ssliop:127.0.0.1:3629/NameService [Root exception is org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 603 completed: No] at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.setOrbAndRootContext(CNCtx.java:370) at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingCorbanameUrl(CNCtx.java:335) at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingUrl(CNCtx.java:268) at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:233) at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99) at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53) at org.wildfly.iiop.openjdk.naming.jndi.WrapperInitialContext.lookup(WrapperInitialContext.java:72) at javax.naming.InitialContext.lookup(InitialContext.java:417) at javax.naming.InitialContext.lookup(InitialContext.java:417) at org.jboss.as.ejb3.deployment.processors.EjbLookupInjectionSource$1.getReference(EjbLookupInjectionSource.java:81) ... 219 more Caused by: org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 603 completed: No at com.sun.corba.se.impl.logging.NamingSystemException.insBadAddress(NamingSystemException.java:148) at com.sun.corba.se.impl.logging.NamingSystemException.insBadAddress(NamingSystemException.java:166) at com.sun.corba.se.impl.naming.namingutil.CorbalocURL.badAddress(CorbalocURL.java:122) at com.sun.corba.se.impl.naming.namingutil.CorbalocURL.<init>(CorbalocURL.java:95) at com.sun.corba.se.impl.naming.namingutil.INSURLHandler.parseURL(INSURLHandler.java:59) at com.sun.corba.se.impl.resolver.INSURLOperationImpl.operate(INSURLOperationImpl.java:134) at com.sun.corba.se.impl.orb.ORBImpl.string_to_object(ORBImpl.java:825) at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.setOrbAndRootContext(CNCtx.java:349) ... 228 more {noformat} Similar scenatrio works correctly on EAP 6.4 ejb-jar.xml configuration: {noformat} <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" version="3.1"> <enterprise-beans> <session> <ejb-name>ClientEjb</ejb-name> <session-type>Stateless</session-type> <ejb-ref> <ejb-ref-name>statelessHome</ejb-ref-name> <injection-target> <injection-target-class>org.jboss.as.test.iiopssl.basic.ClientEjb</injection-target-class> <injection-target-name>statelessHome</injection-target-name> </injection-target> <lookup-name>corbaname:ssliop:${node1}:3629#IIOPSslStatelessBean</lookup-name> </ejb-ref> </session> </enterprise-beans> </ejb-jar> {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6245) Upgrade to Hibernate Search 5.5.2.Final

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6245?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-6245: ------------------------------- Summary: Upgrade to Hibernate Search 5.5.2.Final (was: Upgrade to Hibernate Search 5.5.1.Final) > Upgrade to Hibernate Search 5.5.2.Final > --------------------------------------- > > Key: WFLY-6245 > URL: https://issues.jboss.org/browse/WFLY-6245 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.Final > > > For performance improvement -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6245) Upgrade to Hibernate Search 5.5.1.Final

by Scott Marlow (JIRA)

Scott Marlow created WFLY-6245: ---------------------------------- Summary: Upgrade to Hibernate Search 5.5.1.Final Key: WFLY-6245 URL: https://issues.jboss.org/browse/WFLY-6245 Project: WildFly Issue Type: Task Components: JPA / Hibernate Affects Versions: 10.0.0.Final Reporter: Scott Marlow Assignee: Scott Marlow Priority: Blocker Fix For: 10.1.0.Final For performance improvement -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5734) Upgrade to Hibernate Search 5.5.1.Final and Apache Lucene to 5.3.1

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-5734?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-5734. ------------------------------ > Upgrade to Hibernate Search 5.5.1.Final and Apache Lucene to 5.3.1 > ------------------------------------------------------------------ > > Key: WFLY-5734 > URL: https://issues.jboss.org/browse/WFLY-5734 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 10.0.0.CR5 > > > Contains several performance improvements. > Full list of changes: > - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6244) Create common module for all JGroups protocols

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6244?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6244: --------------------------------- Summary: Create common module for all JGroups protocols (was: Create common module for JGroups protocols) > Create common module for all JGroups protocols > ---------------------------------------------- > > Key: WFLY-6244 > URL: https://issues.jboss.org/browse/WFLY-6244 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Create a new jgroups protocol module that depends on all modules that supply jgroups protocol classes. Then we can change the default module to load protocols from to the newly created one. Prevents pulling unnecessary classes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6244) Create common module for JGroups protocols

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6244?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6244: --------------------------------- Description: Create a new jgroups protocol module that depends on all modules that supply jgroups protocol classes. Then we can change the default module to load protocols from to the newly created one. Prevents pulling unnecessary classes. (was: This change the protocol default module to the newly created one. Prevents pulling unnecessary classes.) > Create common module for JGroups protocols > ------------------------------------------ > > Key: WFLY-6244 > URL: https://issues.jboss.org/browse/WFLY-6244 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Create a new jgroups protocol module that depends on all modules that supply jgroups protocol classes. Then we can change the default module to load protocols from to the newly created one. Prevents pulling unnecessary classes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6158) Integrate AZURE_PING discovery protocol

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6158?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6158: --------------------------------- Description: Code to integrate is https://github.com/jgroups-extras/jgroups-azure (was: Code to integrate is https://github.com/rhusar/jgroups-azure) > Integrate AZURE_PING discovery protocol > --------------------------------------- > > Key: WFLY-6158 > URL: https://issues.jboss.org/browse/WFLY-6158 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 10.1.0.Final > > > Code to integrate is https://github.com/jgroups-extras/jgroups-azure -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR

by Dimitris Andreadis (JIRA)

[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ] Dimitris Andreadis reassigned WFCORE-761: ----------------------------------------- Assignee: Dimitris Andreadis (was: Lin Gao) > Not possible to overlay non existing file in WAR > ------------------------------------------------ > > Key: WFCORE-761 > URL: https://issues.jboss.org/browse/WFCORE-761 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Bartosz Baranowski > Assignee: Dimitris Andreadis > Priority: Critical > > It is either bug in how deployments are treated or how overlay/vfs work. > Steps to reproduce: > 1. deploy undexploded war with jar inside > 2. add overlay that will add non existing file in jar > Result: exception: > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt > Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}} > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67) > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37) > at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76) > at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67) > Expectation: > should work. It actually does work, if war is really exploded or > 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly

by James Strachan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ] James Strachan commented on WFCORE-433: --------------------------------------- The original motivation for this issue was to be able to provision WildFly containers using a shared configuration in a git repo; such as if being used with fabric8 version 1.x - so that changes to the configuration are stored in a shared space which on change can be replicated to many containers. Actually now Kubernetes has introduced ConfigMap, so a better Cloud First approach for WildFly when using Kubernetes / OpenShift / Atomic / Fabric8 version 2.x would be for it to store all configuration files inside a ConfigMap: https://github.com/eBay/Kubernetes/blob/master/docs/proposals/configmap.md then each WildFly docker container would mount each ConfigMap entry (e.g. one for “standalone.xml" or whatever files WildFly needs for its config) as a volume (file) on the file system; then WildFly would watch the file as usual to detect changes and reload etc. But when the file is changed via the Admin Console, rather than writing directly to the file system, we’d write to the ConfigMap REST API. e.g. if you have a cluster of 5 containers and you want to add, say, a DataSource; writing to the single ConfigMap resource inside Kubernetes would then automatically update the standalone.xml on each of the 5 wildfly containers. So the only real change thats required is that whenever standalone.xml is about to be written, its not written to the local file system, instead we GET the ConfigMap resource from the kubernetes REST API, then update the ‘standalone.xml” entry in that object, then POST the change back to the ConfigMap. This would provide “Domain Controller” like behaviour for configuration of a cluster of WildFly containers while just relying on standard kubernetes semantics > git backend for loading/storing the configuration XML for wildfly > ----------------------------------------------------------------- > > Key: WFCORE-433 > URL: https://issues.jboss.org/browse/WFCORE-433 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: James Strachan > Assignee: Jason Greene > > when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like: > * git pull > * write the, say, standalone.xml file > * git commit -a -m "some comment" > * git push > (with a handler to deal with conflicts; such as last write wins). > Then an optional periodic 'git pull' and reload configuration if there is a change. > This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git) > Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6244) Create common module for JGroups protocols

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6244: ------------------------------------ Summary: Create common module for JGroups protocols Key: WFLY-6244 URL: https://issues.jboss.org/browse/WFLY-6244 Project: WildFly Issue Type: Feature Request Components: Clustering Reporter: Radoslav Husar Assignee: Radoslav Husar This change the protocol default module to the newly created one. Prevents pulling unnecessary classes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016