[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
[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
[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
[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
[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
[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