February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1400) Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1400: ---------------------------------------- Summary: Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability Key: WFCORE-1400 URL: https://issues.jboss.org/browse/WFCORE-1400 Project: WildFly Core Issue Type: Task Components: Domain Management, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-422) Default SSLContext?

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-422: ------------------------------------ Summary: Default SSLContext? Key: ELY-422 URL: https://issues.jboss.org/browse/ELY-422 Project: WildFly Elytron Issue Type: Task Components: SSL Reporter: Darran Lofthouse Fix For: 1.1.0.Beta5 We know we want one, what we don't know is exactly that it means and is it an Elytron concern or subsystem concern. One issue is within Elytron our SSLContext implementations are either server side specific or client side specific - we may even want to review if there is any way to review what it is being used for and act accordingly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6248) Obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-6248: -------------------------------------- Summary: Obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability Key: WFLY-6248 URL: https://issues.jboss.org/browse/WFLY-6248 Project: WildFly Issue Type: Enhancement Components: Web (Undertow) Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6248) Obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6248?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-6248: ----------------------------------- Issue Type: Task (was: Enhancement) > Obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability > --------------------------------------------------------------------------------- > > Key: WFLY-6248 > URL: https://issues.jboss.org/browse/WFLY-6248 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6248) Obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6248?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-6248: ----------------------------------- Labels: affects_elytron (was: ) > Obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability > --------------------------------------------------------------------------------- > > Key: WFLY-6248 > URL: https://issues.jboss.org/browse/WFLY-6248 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5274) EJB IOR contains wrong port (non-SSL port) information when SSL is required

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5274?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5274: ----------------------------------------------- Bartek Spyrko-Smietanko <bspyrkos(a)redhat.com> changed the Status of [bug 1259902|https://bugzilla.redhat.com/show_bug.cgi?id=1259902] from POST to ASSIGNED > EJB IOR contains wrong port (non-SSL port) information when SSL is required > --------------------------------------------------------------------------- > > Key: WFLY-5274 > URL: https://issues.jboss.org/browse/WFLY-5274 > Project: WildFly > Issue Type: Bug > Components: IIOP > Reporter: Derek Horton > Assignee: Tomasz Adamski > > Description of problem: > - Configure JBoss to only allow IIOP connections over SSL > - It is possible to do this, but the configuration is confusing (possibly a bug) > Details of the setup/issue: > - When enabling SSL for jacorb, it normally listens on both the non-ssl port and the ssl port > - Setting server-requires="ServerAuth" causes the server to stop listening on non-ssl port > - However, the IOR tells client to connect to non-ssl port ...even though its not listening on it > String lookup = "corbaname:iiop:" + host + ":" + port +"#" + ejbLookupPath; > // lookup the IIOP EJB > Object iiopObj = ctx.lookup(lookup); > // the call to the EJB will fail due to the port being wrong non-ssl vs ssl > - The workaround is to use the following ior-setting to correct the port settings in the IOR > /subsystem=jacorb/ior-settings=default/setting=transport-config:add(confidentiality=required) > - Shouldn't setting "server-requires=ServerAuth" change the port info in the IOR? -- 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 Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6244?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6244: ------------------------------------ Just to say - for the change of attribute default, we should *not* transform this (as we normally would for change of attribute default value), as old versions won't have the new default module. > 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] (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: --------------------------------------- Sorry I was referring to the WildFly Admin Console. So yeah, WF Admin Console is totally in charge of loading/saving data however it wishes; the only change is we make changes to ConfigMap (or a git repo - both approaches are valid). The great thing about ConfigMap is there's no dependency on a remote git repository (which ends up being a single point of failure), so it'll just work on any kubernetes cluster. The great thing about git is versioning and allows things like pull request / approvals for merging changes from one branch to another (e.g. changes from Test -> Production branches). So both approaches have value really. > 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] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-433: ----------------------------------------- What Admin Console are you referring to? A central console in an overall cloud admin tool, or the WF Admin Console? My interpretation is the former, which means there's a central admin point and the WildFly containers are just reacting to changes, not making them themselves. > 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-6247) Cannot use corbaname:ssliop protocol to inject remote EJB bean

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created WFLY-6247: ---------------------------------------------- Summary: Cannot use corbaname:ssliop protocol to inject remote EJB bean Key: WFLY-6247 URL: https://issues.jboss.org/browse/WFLY-6247 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

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