August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3085) Update license related information

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3085?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-3085. -------------------------------------- Fix Version/s: 3.0.0.Beta29 (was: 3.0.0.Final) Resolution: Done I'm re-resolving this against Beta29. I forgot it was reopened and opened WFCORE-3202 for the other work. > Update license related information > ---------------------------------- > > Key: WFCORE-3085 > URL: https://issues.jboss.org/browse/WFCORE-3085 > Project: WildFly Core > Issue Type: Task > Affects Versions: 3.0.0.Beta28 > Reporter: Petr Sakař > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta29 > > > Please change name of license in root pom file licenses tag to comply with the name from the first column of the license list https://spdx.org/licenses/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1341) Mapping between kind and callback instances should be documented

by Jan Kalina (JIRA)

Jan Kalina created ELY-1341: ------------------------------- Summary: Mapping between kind and callback instances should be documented Key: ELY-1341 URL: https://issues.jboss.org/browse/ELY-1341 Project: WildFly Elytron Issue Type: Enhancement Components: Authentication Client Affects Versions: 1.1.0.Final Reporter: Jan Kalina Assignee: Jan Kalina Requested in https://github.com/wildfly/wildfly-core/pull/2713#discussion_r133396472 ??How can we know that we are listing all the supported callbacks and not missing some? A comment that would detail the mapping between kind and callback instances could help.?? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9231) Wildfly wildfly-ejb3 - 10.1.0.Final EJBComponentDescription - not useful exception when class for mdb not found

by Nuno Godinho de Matos (JIRA)

[ https://issues.jboss.org/browse/WFLY-9231?page=com.atlassian.jira.plugin.... ] Nuno Godinho de Matos commented on WFLY-9231: --------------------------------------------- Having a proper exception with more metadata would really be useful. I am now configuring a relatively big projec to be deployed against wildfly. And as I am trying to automate the generation of the jboss-ejb3.xml from a weblogic-ejb.xml, one thing that is different in wildfly is that we are forced to declare destinationLookup for every mdb. e.g. while producing metadata such as follows {code} <message-driven> <ejb-name>SomeMdb</ejb-name> <resource-ref> <res-ref-name>JmsXA</res-ref-name> <res-type>javax.jms.ConnectionFactory</res-type> <lookup-name>java:/JmsXA</lookup-name> </resource-ref> <activation-config> <activation-config-property> <activation-config-property-name>maxSession</activation-config-property-name> <activation-config-property-value>1</activation-config-property-value> </activation-config-property> <activation-config-property> <activation-config-property-name>destinationLookup</activation-config-property-name> <activation-config-property-value>java:/queue/SomeMdbQueue</activation-config-property-value> </activation-config-property> </activation-config> </message-driven> {code} During deployment I came again against this component class is null. I go to debug and I see an specific mdb in there in the component name. The deployment folder of wildfly was OK with the class this time. So I check the annotations on the MdB and and see that the ejbName on the annotation was the same name as the queue. The Ejb has a copy paste mistake, essentially, and the component class for the component name could not be figured out. If I am not told what component in the xml file is buggy, I cannot fix my deployment issue. And it is way to easy to have configuration errors in the jboss-ejb3.xml. This issue really slows down development time. Kindest regards. > Wildfly wildfly-ejb3 - 10.1.0.Final EJBComponentDescription - not useful exception when class for mdb not found > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9231 > URL: https://issues.jboss.org/browse/WFLY-9231 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Environment: windows 7, but it is immaterial > Reporter: Nuno Godinho de Matos > Priority: Minor > > While opening a WAR project on eclipse, for some unkown reason, the project / jboss tooling integration was not working properly. > In particular, when deploying a small sample application there was an Mdb class that was not getting copied over to the deploymnet folder. > e.g. > C:\dev\Widlfly10\wildfly-10.1.0.Final\user_projects\domains\standalone-orcl\deployments\wildfly-jta-commit-reproducebug.war\WEB-INF\classes\entrypoint\mdb > The above folder was empty. > The deployment would fail because the Mdb class was not withing that folder. > Now the fix for this problem was to close and re-open the project. > Ater which whatever glitch was going on eclipse got resolved and the deployment process started working properly. > With that said, this issue is about the exception that wildfly was firing during the deployment: > Namely: > {panel} > 2017-08-16 14:08:00,203 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."wildfly-jta-commit-reproducebug.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-jta-commit-reproducebug.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "wildfly-jta-commit-reproducebug.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalArgumentException: WFLYEE0078: componentClassName is null > at org.jboss.as.ee.component.ComponentDescription.<init>(ComponentDescription.java:114) > at org.jboss.as.ejb3.component.EJBComponentDescription.<init>(EJBComponentDescription.java:269) > at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription.<init>(MessageDrivenComponentDescription.java:96) > at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processMessageDrivenBeanMetaData(MessageDrivenComponentDescriptionFactory.java:244) > at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processBeanMetaData(MessageDrivenComponentDescriptionFactory.java:88) > at org.jboss.as.ejb3.deployment.processors.AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.processBeanMetaData(AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.java:64) > at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.processDeploymentDescriptor(AbstractDeploymentUnitProcessor.java:138) > at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.deploy(AbstractDeploymentUnitProcessor.java:79) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) > ... 5 more > {panel} > The above exception is not very useful, because it does not say what component is the point of origin for the above exception. > Before I could go investigate the folder in the deployment dir, I thought there must be something wrong in the project (there wasn't). > So I had to wonder what component was bugy. > It was necessary to add to the project the following dependency: > {panel} > <dependency> > <groupId>org.wildfly</groupId> > <artifactId>wildfly-ejb3</artifactId> > <version>10.1.0.Final</version> > <scope>provided</scope> > </dependency> > {panel} > Debug the class: > org.jboss.as.ejb3.component.EJBComponentDescription > {panel} > public EJBComponentDescription(final String componentName, final String componentClassName, final EjbJarDescription ejbJarDescription, final ServiceName deploymentUnitServiceName, final EnterpriseBeanMetaData descriptorData) { > super(componentName, componentClassName, ejbJarDescription.getEEModuleDescription(), deploymentUnitServiceName); > {panel} > To figure out the compnent name that was the cause of the issue. > Then I finally added the ejb-class extra metadata to the jboss-ejb3.xml. > {panel} > <message-driven> > <ejb-name>ReproduceBugMdb</ejb-name> >  > <ejb-class>entrypoint.mdb.ReproduceBugMdb</ejb-class> > <resource-ref> > <res-ref-name>JmsXA</res-ref-name> > <res-type>javax.jms.ConnectionFactory</res-type> > <lookup-name>java:/JmsXA</lookup-name> > </resource-ref> > <activation-config> > <activation-config-property> > <activation-config-property-name>maxSession</activation-config-property-name> > <activation-config-property-value>1</activation-config-property-value> > </activation-config-property> > <activation-config-property> > <activation-config-property-name>destinationLookup</activation-config-property-name> > <activation-config-property-value>java:/queue/ReproduceBugQueue</activation-config-property-value> > </activation-config-property> > </activation-config> > </message-driven> > {panel} > And only then could I get the "class not found exception" that lead me to go take a peek at the deployment folder and see that the folder was empty of any classes. > Which lead me to close and open the project. > I believe that the firing up an exception that reports that component class is null does not help anybody. > The exception should give as much context as possible to help the user identify the point of origing of the problem. > In this case, it should at least refer the mdb whose class could not be figured out during deployment. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3202) Clean up license issues

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3202: ---------------------------------------- Summary: Clean up license issues Key: WFCORE-3202 URL: https://issues.jboss.org/browse/WFCORE-3202 Project: WildFly Core Issue Type: Task Components: Server Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Final Do some housekeeping related to reporting of license information. Background: from a layman's POV, WildFly Core is an LGPL 2.1 project (since it contains lots of LGPL 2.1 code) but we would like at some point to make it ASL 2. To further that, new code for a long time now has had ASL 2.0 file headers, and we have reviewed the LGPL 2.1 code and feel we could convert the headers on those to ASL 2 when we have time. Component dependencies are another matter, but are not directly relevant to this issue. So, we have a mix of code, some with LGPL 2.1 and some with ASL 2.0. Per our understanding we are meant to report both licenses in "automated" reporting locations like the project root pom.xml and the core-feature-pack-licenses.xml file. This fix will do that. Also, we want to ship a LICENSE.txt file that includes the formal license text referred to in the file headers. That's just good practice for any OSS project. Since files refer to both LGPL 2.1 and ASL 2, the file will include the text from both. Finally, the pom.xml and the core-feature-pack-licenses.xml file will refer to LGPL 2.1 "or later" rather than "only" as that is the typical way LPGL is handled and it conforms with what is said in the file headers. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7345) Fix big jboss-beans.xml files truncation

by Leonardo Penczek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7345?page=com.atlassian.jira.plugin.... ] Leonardo Penczek commented on WFLY-7345: ---------------------------------------- I created a test case. You can see that some properties will have a truncated value when the bean is deployed. > Fix big jboss-beans.xml files truncation > ---------------------------------------- > > Key: WFLY-7345 > URL: https://issues.jboss.org/browse/WFLY-7345 > Project: WildFly > Issue Type: Bug > Components: POJO > Affects Versions: 10.1.0.Final > Reporter: Leonardo Penczek > Assignee: Ales Justin > Attachments: Test.java, TestMBean.java, test-jboss-beans.xml > > > If the jboss-beans.xml file is big enough, the value of a property.may be truncated, > Fix for this problem: > In the org.jboss.as.pojo.KernelDeploymentParsingProcessor constructor, add this line of code: > inputFactory.setProperty("javax.xml.stream.isCoalescing", Boolean.valueOf(true)); > It prevents the truncation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7345) Fix big jboss-beans.xml files truncation

by Leonardo Penczek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7345?page=com.atlassian.jira.plugin.... ] Leonardo Penczek updated WFLY-7345: ----------------------------------- Attachment: Test.java TestMBean.java > Fix big jboss-beans.xml files truncation > ---------------------------------------- > > Key: WFLY-7345 > URL: https://issues.jboss.org/browse/WFLY-7345 > Project: WildFly > Issue Type: Bug > Components: POJO > Affects Versions: 10.1.0.Final > Reporter: Leonardo Penczek > Assignee: Ales Justin > Attachments: Test.java, TestMBean.java, test-jboss-beans.xml > > > If the jboss-beans.xml file is big enough, the value of a property.may be truncated, > Fix for this problem: > In the org.jboss.as.pojo.KernelDeploymentParsingProcessor constructor, add this line of code: > inputFactory.setProperty("javax.xml.stream.isCoalescing", Boolean.valueOf(true)); > It prevents the truncation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7345) Fix big jboss-beans.xml files truncation

by Leonardo Penczek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7345?page=com.atlassian.jira.plugin.... ] Leonardo Penczek updated WFLY-7345: ----------------------------------- Attachment: test-jboss-beans.xml > Fix big jboss-beans.xml files truncation > ---------------------------------------- > > Key: WFLY-7345 > URL: https://issues.jboss.org/browse/WFLY-7345 > Project: WildFly > Issue Type: Bug > Components: POJO > Affects Versions: 10.1.0.Final > Reporter: Leonardo Penczek > Assignee: Ales Justin > Attachments: Test.java, TestMBean.java, test-jboss-beans.xml > > > If the jboss-beans.xml file is big enough, the value of a property.may be truncated, > Fix for this problem: > In the org.jboss.as.pojo.KernelDeploymentParsingProcessor constructor, add this line of code: > inputFactory.setProperty("javax.xml.stream.isCoalescing", Boolean.valueOf(true)); > It prevents the truncation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1340) IBM java, 401 is returned instead of 403, when client send invalid ticket

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1340?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1340: ---------------------------- Labels: (was: eap72) > IBM java, 401 is returned instead of 403, when client send invalid ticket > ------------------------------------------------------------------------- > > Key: ELY-1340 > URL: https://issues.jboss.org/browse/ELY-1340 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.0.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > > In JBEAP-9945 new behaviour was introduced to return 403 when only SPNEGO http mechanismus is configured and client provides invalid ticket. However with IBM java 401 is returned instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1340) IBM java, 401 is returned instead of 403, when client send invalid ticket

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1340?page=com.atlassian.jira.plugin.s... ] Jan Kalina moved JBEAP-12813 to ELY-1340: ----------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1340 (was: JBEAP-12813) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: HTTP (was: Security) Affects Version/s: 1.1.0.Final (was: 7.1.0.ER2) > IBM java, 401 is returned instead of 403, when client send invalid ticket > ------------------------------------------------------------------------- > > Key: ELY-1340 > URL: https://issues.jboss.org/browse/ELY-1340 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.0.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: eap72 > > In JBEAP-9945 new behaviour was introduced to return 403 when only SPNEGO http mechanismus is configured and client provides invalid ticket. However with IBM java 401 is returned instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9248) Incorrect licenses.xml entry for org.jboss:jboss-ejb-client-legacy

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9248?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9248: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10444 (was: https://github.com/wildfly/wildfly/pull/10442) > Incorrect licenses.xml entry for org.jboss:jboss-ejb-client-legacy > ------------------------------------------------------------------ > > Key: WFLY-9248 > URL: https://issues.jboss.org/browse/WFLY-9248 > Project: WildFly > Issue Type: Bug > Components: Build System, EJB > Reporter: Nikoleta Žiaková > Assignee: Brian Stansberry > Fix For: 11.0.0.CR1 > > > licenses.xml contains: > {code} > <dependency> > <groupId>org.jboss</groupId> > <artifactId>jboss-ejb-client-legacy</artifactId> > <version>3.0.0.Beta7-redhat-1</version> > <licenses> > <license> > <name>Public Domain</name> > <url>http://repository.jboss.org/licenses/cc0-1.0.txt</url> > <distribution>repo</distribution> > </license> > </licenses> > </dependency> > {code} > However, the POM and source files contain {{GNU Lesser General Public License}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 August 2017