March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-656) The blessed repo's should not accept a git force push

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-656?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on DROOLS-656: ----------------------------------------- Yes, James Dennes told me it's done on all repo's of https://github.com/droolsjbpm on all branches (but not forks of course) on 20-JAN-2015. No idea if it automatically applies to new repo's in that same github organization... > The blessed repo's should not accept a git force push > ----------------------------------------------------- > > Key: DROOLS-656 > URL: https://issues.jboss.org/browse/DROOLS-656 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > If someone ever git forces pushes to a blessed repo all hell will break loose. > We can prevent git forces pushes, as explained here: > http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-gi... > Force pushing on blessed repo's is very bad, but force pushing on forks is very common. > Requirements: > - Enable this on 1 new dummy blessed repository > - Prove you cannot force push to > - Prove you can fork it and force push to your fork. > - Delete the dummy blessed repository > - If that works well, enable it on the real blessed repositories -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-656) The blessed repo's should not accept a git force push

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-656?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer commented on DROOLS-656: ----------------------------------------------- AFAIK this was done? I am not sure about this. Geoffrey, If you know that this werd done please resolve and close this Jira. > The blessed repo's should not accept a git force push > ----------------------------------------------------- > > Key: DROOLS-656 > URL: https://issues.jboss.org/browse/DROOLS-656 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > If someone ever git forces pushes to a blessed repo all hell will break loose. > We can prevent git forces pushes, as explained here: > http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-gi... > Force pushing on blessed repo's is very bad, but force pushing on forks is very common. > Requirements: > - Enable this on 1 new dummy blessed repository > - Prove you cannot force push to > - Prove you can fork it and force push to your fork. > - Delete the dummy blessed repository > - If that works well, enable it on the real blessed repositories -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-706) Clean-up utility/release scripts in build-bootstrap

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-706?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-706. ------------------------------------------- Resolution: Done > Clean-up utility/release scripts in build-bootstrap > --------------------------------------------------- > > Key: DROOLS-706 > URL: https://issues.jboss.org/browse/DROOLS-706 > Project: Drools > Issue Type: Task > Reporter: Petr Široký > Assignee: Michael Biarnes Kiefer > > The scripts in {{https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/tree/master/script}} need to be reviewed and cleaned-up a bit. They contain some legacy logic that is not needed anymore. For example the {{withoutJbpm}} and {{withoutUberfire}} should not be needed anymore. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-491) drools-karaf-features should avoid declaring its own dependency versions

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-491?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-491. ------------------------------------------- Resolution: Done the used versions are the one from jboss-ip-bom: <karaf.version.org.apache.camel>${version.org.apache.camel}</karaf.version.org.apache.camel> <karaf.version.org.apache.cxf>${version.org.apache.cxf}</karaf.version.org.apache.cxf> <karaf.version.org.apache.helix>${version.org.apache.helix}</karaf.version.org.apache.helix> <karaf.version.com.google.protobuf>${version.com.google.protobuf}</karaf.version.com.google.protobuf> <karaf.version.joda-time>${version.joda-time}</karaf.version.joda-time> <karaf.version.org.jboss.solder>${version.org.jboss.solder}</karaf.version.org.jboss.solder> <karaf.version.org.jboss.seam>${version.org.jboss.seam}</karaf.version.org.jboss.seam> <karaf.version.org.jboss.weld>${version.org.jboss.weld.weld}</karaf.version.org.jboss.weld> <karaf.version.org.mvel>${version.org.mvel}</karaf.version.org.mvel> <karaf.version.javax.enterprise.cdi>${version.javax.enterprise}</karaf.version.javax.enterprise.cdi> > drools-karaf-features should avoid declaring its own dependency versions > ------------------------------------------------------------------------ > > Key: DROOLS-491 > URL: https://issues.jboss.org/browse/DROOLS-491 > Project: Drools > Issue Type: Task > Affects Versions: 6.1.0.Beta3 > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > At the top of this file: > https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-o... > We find: > {code} >  >  >  >  >  >  >  >  >  >  >  >  > <karaf.version.org.apache.camel>2.10.3</karaf.version.org.apache.camel> > <karaf.version.org.apache.cxf>2.6.6</karaf.version.org.apache.cxf> > <karaf.version.org.apache.helix>0.6.1-incubating</karaf.version.org.apache.helix> > <karaf.version.com.google.protobuf>2.5.0</karaf.version.com.google.protobuf> > <karaf.version.joda-time>1.6.2</karaf.version.joda-time> > <karaf.version.org.jboss.solder>3.2.0.Final</karaf.version.org.jboss.solder> > <karaf.version.org.jboss.seam>3.1.0.Final</karaf.version.org.jboss.seam> > <karaf.version.org.jboss.weld>1.1.13.Final</karaf.version.org.jboss.weld> > <karaf.version.org.mvel>2.1.6.Final</karaf.version.org.mvel> > {code} > That TODO "TODO Because these properties moved into the jboss-integration-platform-bom, we can't use them directly" is *no longer valid*. We now have the jboss-integration-platform-parent as a parent, so we do have those versions available, so there's no need to hardcode those versions. > As for the other versions > {code} >  > <karaf.version.commons-codec>1.7</karaf.version.commons-codec> > <karaf.version.javax.enterprise.cdi>1.0-SP4</karaf.version.javax.enterprise.cdi> > <karaf.version.javax.inject>1.0</karaf.version.javax.inject> > <karaf.version.org.codehaus.janino>2.6.1</karaf.version.org.codehaus.janino> > <karaf.version.org.eclipse.jdt.core.compiler>4.2.1</karaf.version.org.eclipse.jdt.core.compiler> >  > <karaf.servicemix.version.com.google.protobuf>2.4.1_1</karaf.servicemix.version.com.google.protobuf> > <karaf.servicemix.version.com.sun.xml.bind.jaxb>2.2.1.1_2</karaf.servicemix.version.com.sun.xml.bind.jaxb> > <karaf.servicemix.version.com.thoughtworks.xstream>1.4.3_1</karaf.servicemix.version.com.thoughtworks.xstream> > <karaf.servicemix.version.javax.xml.bind.jaxb>1.9.0</karaf.servicemix.version.javax.xml.bind.jaxb> > <karaf.servicemix.version.org.antlr>3.5_1</karaf.servicemix.version.org.antlr> > <karaf.servicemix.version.org.apache.poi>3.9_2</karaf.servicemix.version.org.apache.poi> > <karaf.servicemix.version.org.codehaus.woodstox>3.2.9_3</karaf.servicemix.version.org.codehaus.woodstox> > <karaf.servicemix.version.org.quartz-scheduler>2.1.6_1</karaf.servicemix.version.org.quartz-scheduler> >  > <karaf.servicemix.version.scripting-api>2.4.0</karaf.servicemix.version.scripting-api> >  > <karaf.version.org.apache.aries.jpa>1.0.1</karaf.version.org.apache.aries.jpa> > {code} > figure out if any of those can be removed from being hard coded... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-478) Biuld: Felix (OSGi) plugin confgs: remove invalid version strings and unneeded imports statements from pom

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-478?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-478. ------------------------------------------- Resolution: Done now it is: <instructions> <Bundle-SymbolicName>org.jbpm.bpmn2</Bundle-SymbolicName> <Bundle-Activator>org.jbpm.osgi.bpmn2.Activator</Bundle-Activator> <Import-Package> !org.jbpm.compiler org.drools.core*, org.drools.compiler*, org.kie.api*, * </Import-Package> <Export-Package> * </Export-Package> </instructions> > Biuld: Felix (OSGi) plugin confgs: remove invalid version strings and unneeded imports statements from pom > ---------------------------------------------------------------------------------------------------------- > > Key: DROOLS-478 > URL: https://issues.jboss.org/browse/DROOLS-478 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > Some osgi-enabled modules's felix configuration hasn't been cleaned up yet. Find and fix all pom files which follow the bad pattern below. > Bad: > {code} > <instructions> > <Bundle-SymbolicName>org.jbpm.bpmn2</Bundle-SymbolicName> > <Bundle-Activator>org.jbpm.osgi.bpmn2.Activator</Bundle-Activator> > <Import-Package> > !org.jbpm.compiler > org.drools.core*;version=6.0.0, > org.drools.compiler*;version=6.0.0, > org.kie.api*;version=6.0.0, > * > </Import-Package> > <Export-Package> > * > </Export-Package> > </instructions> > {code} > https://github.com/droolsjbpm/jbpm/blob/master/jbpm-bpmn2/pom.xml#L147 > The above instructions are bad, because: > - *"version=6.0.0" is plain wrong*: this is master, this is 6.1 already and soon 6.2 (and we don't want to have to change that constantly). > - *Import of org.drools.core, org.drools.compiler, etc is redundant.* The pom file should depend on those (which it already does transitively, but it might need to be direct for felix to work) and then felix will automatically add them for osgi. > Note: The felix plugin now activates during compilation and checks osgi boundaries. This means that if it compiles, it's relatively safe to assume that osgi isn't broken. (A year ago, felix have no such assurances and osgi was broken without anyone noticing). > Ideal (low maintenance): > {code} > <instructions> > <Bundle-SymbolicName>org.optaplanner.core</Bundle-SymbolicName> > <Export-Package> > org.optaplanner.core.* > </Export-Package> > </instructions> > {code} > https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-core/po... > Reasonable: > {code} > <instructions> > <Bundle-SymbolicName>org.drools.compiler</Bundle-SymbolicName> > <Import-Package> > com.sun.tools.xjc.*;resolution:=optional, > com.sun.codemodel;resolution:=optional, > javax.enterprise.*;resolution:=optional, > org.antlr.*;resolution:=optional, > org.codehaus.janino.*;resolution:=optional, > org.eclipse.jdt.*;resolution:=optional, > org.osgi.*;resolution:=optional, > org.kie.spring*;resolution:=optional, > * > </Import-Package> > <Export-Package> > * > </Export-Package> > <Bundle-Activator>org.drools.compiler.osgi.Activator</Bundle-Activator> > <_removeheaders>Private-Package</_removeheaders> > </instructions> > {code} > https://github.com/droolsjbpm/drools/blob/master/drools-compiler/pom.xml#... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-685) ip-bom should be releasable with maven 3.2 too (including doing the deploy to nexus)

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-685?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-685. ------------------------------------------- Resolution: Done jboss-ip-bom is building and deploying with Maven 3.2.3 > ip-bom should be releasable with maven 3.2 too (including doing the deploy to nexus) > ------------------------------------------------------------------------------------ > > Key: DROOLS-685 > URL: https://issues.jboss.org/browse/DROOLS-685 > Project: Drools > Issue Type: Bug > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > Probably a matter of upgrading the jboss-parent to the next version so a newer maven-release-plugin version is used. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-735) Remove unwanted OptaPlanner references from website sources

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-735?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer commented on DROOLS-735: ----------------------------------------------- Hmm, I think it would be good to have Geoffrey in the boat as he knows exactly what keywords etc. are referring to OptaPlanner. For me it is nearly impossible find keywords that are OptaPlanner related when not every reference is unwanted. > Remove unwanted OptaPlanner references from website sources > ----------------------------------------------------------- > > Key: DROOLS-735 > URL: https://issues.jboss.org/browse/DROOLS-735 > Project: Drools > Issue Type: Bug > Reporter: Petr Široký > Assignee: Michael Biarnes Kiefer > > There are still some unwanted references to OptaPlanner in the Drools website sources. For example the https://github.com/droolsjbpm/drools-website/blob/master/_config/site.yml contains keywords related to OptaPlanner rather than Drools. > There are probably others. We need to fix those. > Note: not every reference is necessarily unwanted. There may be some links or other info about OptaPlanner that we want to keep there. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4406) Undertow which uses ECJ 4.4.1 Compiler crash with ArrayIndexOutOfBoundsException when there is unused double or long

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4406?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-4406. ---------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done > Undertow which uses ECJ 4.4.1 Compiler crash with ArrayIndexOutOfBoundsException when there is unused double or long > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4406 > URL: https://issues.jboss.org/browse/WFLY-4406 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > ECJ compiler crashes with ArrayIndexOutOfBoundsException when it contains unused long or double, for details see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=448112]. > Note: this issue is fixed in ECJ 4.4.2. > The error log: > {noformat} > 11:19:49,861 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jsp-cast-to-double-test/cast-to-double.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP > at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:616) > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:769) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.ArrayIndexOutOfBoundsException: -1 > at org.eclipse.jdt.internal.compiler.codegen.StackMapFrame.addStackItem(StackMapFrame.java:92) > at org.eclipse.jdt.internal.compiler.ClassFile.traverse(ClassFile.java:5546) > at org.eclipse.jdt.internal.compiler.ClassFile.generateStackMapTableAttribute(ClassFile.java:4305) > at org.eclipse.jdt.internal.compiler.ClassFile.completeCodeAttribute(ClassFile.java:1380) > at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:338) > at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:270) > at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:566) > at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:635) > at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:368) > at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:781) > at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:470) > at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:449) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) > at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604) > ... 32 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4016) Memory leak on undeploy caused by ejb client

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-4016?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-4016: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6869, https://github.com/wildfly/wildfly/pull/7234 (was: https://github.com/wildfly/wildfly/pull/6869) > Memory leak on undeploy caused by ejb client > -------------------------------------------- > > Key: WFLY-4016 > URL: https://issues.jboss.org/browse/WFLY-4016 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > EJB client application deployed with jboss-ejb-client.xml, when undeployed the classloader is not being released leading to a memory leak. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-735) Remove unwanted OptaPlanner references from website sources

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-735?page=com.atlassian.jira.plugin... ] Petr Široký updated DROOLS-735: ------------------------------- Description: There are still some unwanted references to OptaPlanner in the Drools website sources. For example the https://github.com/droolsjbpm/drools-website/blob/master/_config/site.yml contains keywords related to OptaPlanner rather than Drools. There are probably others. We need to fix those. Note: not every reference is necessarily unwanted. There may be some links or other info about OptaPlanner that we want to keep there. was: There are still some unwanted references to OptaPlanner in the Drools website sources. For example the https://github.com/droolsjbpm/drools-website/blob/master/_config/site.yml contains keywords related to OptaPlanner rather than Drools. There probably others. We need to fix those. Note: not every reference is necessarily unwanted. There may be some links or other info about OptaPlanner that we want to keep there. > Remove unwanted OptaPlanner references from website sources > ----------------------------------------------------------- > > Key: DROOLS-735 > URL: https://issues.jboss.org/browse/DROOLS-735 > Project: Drools > Issue Type: Bug > Reporter: Petr Široký > Assignee: Michael Biarnes Kiefer > > There are still some unwanted references to OptaPlanner in the Drools website sources. For example the https://github.com/droolsjbpm/drools-website/blob/master/_config/site.yml contains keywords related to OptaPlanner rather than Drools. > There are probably others. We need to fix those. > Note: not every reference is necessarily unwanted. There may be some links or other info about OptaPlanner that we want to keep there. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2015