January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1907) ENCRYPT: asymmetric encryption fails on merge

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1907?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1907: --------------------------- Attachment: encrypt.xml encrypt.xml: asymmetric encryption (fails) > ENCRYPT: asymmetric encryption fails on merge > --------------------------------------------- > > Key: JGRP-1907 > URL: https://issues.jboss.org/browse/JGRP-1907 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.2 > > Attachments: encrypt.xml, EncryptKeyStore.xml > > > {{ENCRYPT}} fails to communicate after a network split and subsequent merge with asymmetric encryption. This works with symmetric encryption. > To reproduce: > * Members A and B > * Add {{<DISCARD use_gui="true"/>}} on top of {{UDP}} > * Form cluster {{(A,B)}} > * Create a network split: {{(A)}} and {{(B)}} > * Remove the network split > * Observe that with both symmetric and asymmetric encryption, the merge forms cluster {{(A,B)}} > * However, with asymmetric encryption, {{ENCRYPT}} fails to process any messages and rejects all messages, whereas with symmetric encryption, this works. > * Symmetric encryption: {{EncryptKeyStore.xml}} > * Asymmetric encryption: {{encrypt.xml}} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1907) ENCRYPT: asymmetric encryption fails on merge

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1907?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1907: --------------------------- Attachment: EncryptKeyStore.xml EncryptKeyStore.xml: symmetric encryption (works fine) > ENCRYPT: asymmetric encryption fails on merge > --------------------------------------------- > > Key: JGRP-1907 > URL: https://issues.jboss.org/browse/JGRP-1907 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.2 > > Attachments: encrypt.xml, EncryptKeyStore.xml > > > {{ENCRYPT}} fails to communicate after a network split and subsequent merge with asymmetric encryption. This works with symmetric encryption. > To reproduce: > * Members A and B > * Add {{<DISCARD use_gui="true"/>}} on top of {{UDP}} > * Form cluster {{(A,B)}} > * Create a network split: {{(A)}} and {{(B)}} > * Remove the network split > * Observe that with both symmetric and asymmetric encryption, the merge forms cluster {{(A,B)}} > * However, with asymmetric encryption, {{ENCRYPT}} fails to process any messages and rejects all messages, whereas with symmetric encryption, this works. > * Symmetric encryption: {{EncryptKeyStore.xml}} > * Asymmetric encryption: {{encrypt.xml}} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1907) ENCRYPT: asymmetric encryption fails on merge

by Bela Ban (JIRA)

Bela Ban created JGRP-1907: ------------------------------ Summary: ENCRYPT: asymmetric encryption fails on merge Key: JGRP-1907 URL: https://issues.jboss.org/browse/JGRP-1907 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.2 {{ENCRYPT}} fails to communicate after a network split and subsequent merge with asymmetric encryption. This works with symmetric encryption. To reproduce: * Members A and B * Add {{<DISCARD use_gui="true"/>}} on top of {{UDP}} * Form cluster {{(A,B)}} * Create a network split: {{(A)}} and {{(B)}} * Remove the network split * Observe that with both symmetric and asymmetric encryption, the merge forms cluster {{(A,B)}} * However, with asymmetric encryption, {{ENCRYPT}} fails to process any messages and rejects all messages, whereas with symmetric encryption, this works. * Symmetric encryption: {{EncryptKeyStore.xml}} * Asymmetric encryption: {{encrypt.xml}} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFLY-4250?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on WFLY-4250: ------------------------------------------- Hey [~jharting], [~swd847]! Any updates on this one? > Manually created CDI producer methods in the Extension are not injected > ----------------------------------------------------------------------- > > Key: WFLY-4250 > URL: https://issues.jboss.org/browse/WFLY-4250 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 8.2.0.Final > Environment: Happened on Linux environment > Reporter: Sebastian Łaskawiec > Assignee: Jozef Hartinger > > h2. Issue description: > During migration from Wildfly 8.1 to 8.2 (Weld 2.1.2.Final -> 2.2.6.Final) in Infinispan we discovered a problem with injecting beans created programmatically in Infinispan-cdi integration module. The problem appeared in {{GreetingServiceIT}} and {{GreetingCacheManagerIT}} test. Both those tests use the following modules integrated into Wildfly: > * org.infinispan.cdi (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" export="true") > * org.infinispan.jcache (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" and "org.infinispan.cdi" slot="ispn-7.1" services="import") > [Infinispan's CDI Extension|https://github.com/infinispan/infinispan/blob/master/cdi/src/ma...] invokes [{{embeddedExtension.registerCacheBeans(event, beanManager)}}|https://github.com/infinispan/infinispan/blob/master/cdi/s...], which registers custom {{Cache}} and {{AdvancedCache}} producer beans. Those beans are being successfully added to {{BeanManager}} but are never chosen for injection. All tests fail because of unsatisfied dependencies for {{Cache<CacheKey, String>}} with qualifiers {{@GreetingCache}}. > h2. Steps to reproduce: > * Download and unzip [https://github.com/slaskawi/infinispan/archive/upgrade_to_wf_8_2_failed_t...] > * Run {{./build.sh clean install -pl cdi,as-modules/embedded,integrationtests/as-integration-embedded -am -DskipTests}} > * Modify Arquillian xml if breakpoint is needed {{./integrationtests/as-integration-embedded/src/test/resources/arquillian.xml}} > * Run test (using IDE or Maven: {{./build.sh test -pl integrationtests/as-integration-embedded -Dtest=GreetingServiceIT}}) > h2. Finding during debugging: > At first I would suggest creating conditional breakpoints: > * {{org.jboss.weld.bootstrap.Validator}} line 370 (WF 8.2) or 366 (WF 8.1), condition {{"[BackedAnnotatedField] @Inject @GreetingCache private org.infinispan.test.integration.as.cdi.GreetingServiceIT.greetingCache".equals(ij.toString())}} - this will stop debugger when validating injection points for {{{GreetingCache}}. > * {{org.jboss.weld.resolution.TypeSafeResolver.ResolvableToBeanCollection}} line 51, condition {{from.toString().startsWith("Types: [org.infinispan.Cache<javax.cache.annotation.CacheKey, java.lang.String>]") || from.toString().contains("org.infinispan.Cache")}} - this stops debugger on loading {{Cache}} producer methods (created in Infinispan CDI Extension) to {{resolved}} Loading Cache in Wildfly 8.1. > During debugging session we discovered that the beans from Infinispan's CDI Extension are created but never used for injection. This is because {{beanManager.getBeans(ij)}} in {{Validator.java}} always return empty list. In Wildfly 8.1 beans are properly resolved using {{ResolvableToBeanCollection#load}} method, but for some reason it never happens in Wildfly 8.2, because those beans are already preset in {{resolved}} Loading Cache with empty collection value. Unfortunately we couldn't find answer why. > h2. Workaround: > In order to fix CDI Producer Beans accessibility we need to add a new dependency to our test: {{META-INF/MANIFEST.MF: Dependencies: org.infinispan:ispn-7.1}}. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-516) jboss-deployment-structure-1_0.xsd Error: 'Attribute name is not allowed to appear in element 'sub-deployment'

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/WFCORE-516?page=com.atlassian.jira.plugin... ] Rob Stryker commented on WFCORE-516: ------------------------------------ While AS7-1345 fixed the issue in version 1,.1 of the schema, the fact is that several example projects are still using the 1.0 schema file in their various descriptors. We can't force the example projects to update, and even if we could, it would make those example projects no longer valid for older versions of wildfly. Assuming there's no issue with changing this (ie backwards compatability), I think it should still be fixed in the 1.0 version of the schema. If there *is* an issue with the schema, then there's not much we can do aside from try to strong-arm the various example projects to use the newer schema. We in JBoss Tools could also just update our copy of the schema, but this would make it no longer match the official version and I think that's the wrong path to go. > jboss-deployment-structure-1_0.xsd Error: 'Attribute name is not allowed to appear in element 'sub-deployment' > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-516 > URL: https://issues.jboss.org/browse/WFCORE-516 > Project: WildFly Core > Issue Type: Bug > Components: Modules > Reporter: Rob Stryker > Assignee: David Lloyd > > When the projects > mail-ear from the Seam example mail [1] > tasks-ear from the Seam example tasks [2] > are imported into JBDS the error > Attribute 'name' is not allowed to appear in element 'sub-deployment' > will be shown for the file jboss-deployment-structure.xml. > It is caused by the bug in jboss-deployment-structure-1_0.xsd; see AS7-1345 > This bug should be IMHO ignored and the error shouldn't be shown. > [1] https://github.com/seam2/jboss-seam/tree/Seam_2_3/examples/mail > [2] https://github.com/seam2/jboss-seam/tree/Seam_2_3/examples/tasks > https://github.com/wildfly/wildfly-core/pull/442/files -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-517) Update schema at web url: http://www.jboss.org/schema/jbossas

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/WFCORE-517?page=com.atlassian.jira.plugin... ] Rob Stryker commented on WFCORE-517: ------------------------------------ To be more clear, if the PR at https://issues.jboss.org/browse/WFCORE-516 is accepted, the http://www.jboss.org/schema/jbossas/jboss-deployment-structure-1_0.xsd file must be updated with the fixed copy. > Update schema at web url: http://www.jboss.org/schema/jbossas > -------------------------------------------------------------- > > Key: WFCORE-517 > URL: https://issues.jboss.org/browse/WFCORE-517 > Project: WildFly Core > Issue Type: Sub-task > Components: Modules > Reporter: Rob Stryker > Assignee: David Lloyd > > If the primary jira and PR are accepted, the web url must be updated with the more up-to-date schema file. > https://issues.jboss.org/browse/WFCORE-516 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-516) jboss-deployment-structure-1_0.xsd Error: 'Attribute name is not allowed to appear in element 'sub-deployment'

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/WFCORE-516?page=com.atlassian.jira.plugin... ] Rob Stryker commented on WFCORE-516: ------------------------------------ Linking JBIDE issue. > jboss-deployment-structure-1_0.xsd Error: 'Attribute name is not allowed to appear in element 'sub-deployment' > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-516 > URL: https://issues.jboss.org/browse/WFCORE-516 > Project: WildFly Core > Issue Type: Bug > Components: Modules > Reporter: Rob Stryker > Assignee: David Lloyd > > When the projects > mail-ear from the Seam example mail [1] > tasks-ear from the Seam example tasks [2] > are imported into JBDS the error > Attribute 'name' is not allowed to appear in element 'sub-deployment' > will be shown for the file jboss-deployment-structure.xml. > It is caused by the bug in jboss-deployment-structure-1_0.xsd; see AS7-1345 > This bug should be IMHO ignored and the error shouldn't be shown. > [1] https://github.com/seam2/jboss-seam/tree/Seam_2_3/examples/mail > [2] https://github.com/seam2/jboss-seam/tree/Seam_2_3/examples/tasks > https://github.com/wildfly/wildfly-core/pull/442/files -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-517) Update schema at web url: http://www.jboss.org/schema/jbossas

by Rob Stryker (JIRA)

Rob Stryker created WFCORE-517: ---------------------------------- Summary: Update schema at web url: http://www.jboss.org/schema/jbossas Key: WFCORE-517 URL: https://issues.jboss.org/browse/WFCORE-517 Project: WildFly Core Issue Type: Sub-task Components: Modules Reporter: Rob Stryker Assignee: David Lloyd If the primary jira and PR are accepted, the web url must be updated with the more up-to-date schema file. https://issues.jboss.org/browse/WFCORE-516 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-516) jboss-deployment-structure-1_0.xsd Error: 'Attribute name is not allowed to appear in element 'sub-deployment'

by Rob Stryker (JIRA)

Rob Stryker created WFCORE-516: ---------------------------------- Summary: jboss-deployment-structure-1_0.xsd Error: 'Attribute name is not allowed to appear in element 'sub-deployment' Key: WFCORE-516 URL: https://issues.jboss.org/browse/WFCORE-516 Project: WildFly Core Issue Type: Bug Components: Modules Reporter: Rob Stryker Assignee: David Lloyd When the projects mail-ear from the Seam example mail [1] tasks-ear from the Seam example tasks [2] are imported into JBDS the error Attribute 'name' is not allowed to appear in element 'sub-deployment' will be shown for the file jboss-deployment-structure.xml. It is caused by the bug in jboss-deployment-structure-1_0.xsd; see AS7-1345 This bug should be IMHO ignored and the error shouldn't be shown. [1] https://github.com/seam2/jboss-seam/tree/Seam_2_3/examples/mail [2] https://github.com/seam2/jboss-seam/tree/Seam_2_3/examples/tasks https://github.com/wildfly/wildfly-core/pull/442/files -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib

by Nick . (JIRA)

[ https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin.... ] Nick . commented on WFLY-4205: ------------------------------ Hi Stuart, As i mentioned WebApplicationInitializer implementations are there inside EAR/lib/ since its an EAR project we don't want to package it under WEB-INF/lib. For a single war project discovering from classes folder is true but not sure why @HandlesTypes is not falling back to EAR/lib class loader. > Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib > -------------------------------------------------------------------------------- > > Key: WFLY-4205 > URL: https://issues.jboss.org/browse/WFLY-4205 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04 > Reporter: Nick . > Assignee: Stuart Douglas > Labels: EAR, servlet3.0, spring-mvc > > Hi, > I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All my spring mvc related jar's are in my EAR/lib, i'm using SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as follows > {code} > @HandlesTypes(WebApplicationInitializer.class) > public class SpringServletContainerInitializer implements ServletContainerInitializer { > @Override > public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext) > throws ServletException { > List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>(); > if (webAppInitializerClasses != null) { > for (Class<?> waiClass : webAppInitializerClasses) { > // Be defensive: Some servlet containers provide us with invalid classes, > // no matter what @HandlesTypes says... > if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) && > WebApplicationInitializer.class.isAssignableFrom(waiClass)) { > try { > initializers.add((WebApplicationInitializer) waiClass.newInstance()); > } > catch (Throwable ex) { > throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex); > } > } > } > } > if (initializers.isEmpty()) { > servletContext.log("No Spring WebApplicationInitializer types detected on classpath"); > return; > } > AnnotationAwareOrderComparator.sort(initializers); > servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers); > for (WebApplicationInitializer initializer : initializers) { > initializer.onStartup(servletContext); > } > } > } > {code} > But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the EAR/lib > Even i have tried adding the extracted the SPI from spring-web jar and added inside my war's WEB-INF/lib as a jar > WEB-INF/lib/web-init-spi.jar which contains > META-INF/services/javax.servlet.ServletContainerIntializer file with org.springframework.web.SpringServletContainerInitializer as an entry. This time its detecting SpringServletContainerInitializer but not detecting what defined in @HandlesTypes > Its only working If i package all those spring mvc jars inside WEB-INF/lib then everything started working. > I have no idea this is how the servlet specification works or its a wildfly issue but i see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR deployment structure. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 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 January 2015