[JBoss JIRA] (DROOLS-1216) Ban commons-logging and log4j deps
by Petr Široký (JIRA)
Petr Široký created DROOLS-1216:
-----------------------------------
Summary: Ban commons-logging and log4j deps
Key: DROOLS-1216
URL: https://issues.jboss.org/browse/DROOLS-1216
Project: Drools
Issue Type: Task
Components: build
Affects Versions: 6.4.0.Final
Reporter: Petr Široký
Assignee: Petr Široký
We are using slf4j + logback for logging. Sometimes other logging libs like commons-logging or log4j creep into the dependency tree. Only way to make sure we get rid of them once and for all is to ban them explicitly via enforcer. There is a rule "bannedDependencies" which can be easily used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6682) Upgrade Hibernate to 5.2.0
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6682?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6682:
------------------------------------
Sounds like a good approach [~epbernard] ! I heard something about adding the hibernate java8/entitymanager maven dependencies back in 5.2.1, which I guess could help with application build time issues. Is that also the plan? If yes, the [https://github.com/wildfly/wildfly/pull/8961] pull request will need some adjustment to not delete those modules.
> Upgrade Hibernate to 5.2.0
> --------------------------
>
> Key: WFLY-6682
> URL: https://issues.jboss.org/browse/WFLY-6682
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Frank Langelage
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: 10.1.0.Final
>
> Attachments: screenshot-1.png
>
>
> Upgrade Hibernate to latest version 5.2.0.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1215?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1215:
-----------------------------------
Attachment: DROOLS-1215.zip
> import function(s) with collision on declared Pojo field names odd behavior and no warning
> ------------------------------------------------------------------------------------------
>
> Key: DROOLS-1215
> URL: https://issues.jboss.org/browse/DROOLS-1215
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Attachments: DROOLS-1215.zip
>
>
> Hello,
> not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype:
> {code}
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> WantToKeep( condition == "color" )
> Measurement( id == "color", $colorVal : val )
> then
> controlSet.add($colorVal);
> end
> declare WantToKeep
> condition : String
> end
> rule "kickstart"
> salience 999
> when
> eval( true )
> then
> insert(new WantToKeep( "color" ));
> end
> {code}
> This works as expected until adding the following import statement:
> {code}
> import function org.jooq.impl.DSL.*;
> {code}
> and then the test will fail.
> I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form.
> I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking.
> I will attach reproducer and workaround in the appropriate sections.
> Thank you,
> Ciao,
> MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1215:
--------------------------------------
Summary: import function(s) with collision on declared Pojo field names odd behavior and no warning
Key: DROOLS-1215
URL: https://issues.jboss.org/browse/DROOLS-1215
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Matteo Mortari
Assignee: Mario Fusco
Hello,
not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype:
{code}
global java.util.Set controlSet;
rule "will execute per each Measurement having ID color"
no-loop
when
WantToKeep( condition == "color" )
Measurement( id == "color", $colorVal : val )
then
controlSet.add($colorVal);
end
declare WantToKeep
condition : String
end
rule "kickstart"
salience 999
when
eval( true )
then
insert(new WantToKeep( "color" ));
end
{code}
This works as expected until adding the following import statement:
{code}
import function org.jooq.impl.DSL.*;
{code}
and then the test will fail.
I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form.
I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking.
I will attach reproducer and workaround in the appropriate sections.
Thank you,
Ciao,
MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-4316) InvalidBytecodeException when an EJB local interface declares static method
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4316?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4316:
-----------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1346242|https://bugzilla.redhat.com/show_bug.cgi?id=1346242] from ASSIGNED to POST
> InvalidBytecodeException when an EJB local interface declares static method
> ---------------------------------------------------------------------------
>
> Key: WFLY-4316
> URL: https://issues.jboss.org/browse/WFLY-4316
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jozef Hartinger
> Assignee: Jozef Hartinger
> Fix For: 9.0.0.Beta1
>
>
> {noformat}
> Caused by: org.jboss.classfilewriter.InvalidBytecodeException: Cannot load variable at 1. Local Variables: Local Variables: [StackEntry [descriptor=Ljava/lang/String;, type=OBJECT]]
> at org.jboss.classfilewriter.code.CodeAttribute.aload(CodeAttribute.java:185)
> at org.jboss.invocation.proxy.ProxyFactory$ProxyMethodBodyCreator.overrideMethod(ProxyFactory.java:150)
> at org.jboss.invocation.proxy.AbstractSubclassFactory.overrideMethod(AbstractSubclassFactory.java:106)
> at org.jboss.invocation.proxy.AbstractSubclassFactory.addInterface(AbstractSubclassFactory.java:363)
> at org.jboss.invocation.proxy.ProxyFactory.generateClass(ProxyFactory.java:286)
> at org.jboss.invocation.proxy.AbstractClassFactory.buildClassDefinition(AbstractClassFactory.java:207)
> at org.jboss.invocation.proxy.AbstractClassFactory.defineClass(AbstractClassFactory.java:160)
> at org.jboss.invocation.proxy.AbstractProxyFactory.getCachedMethods(AbstractProxyFactory.java:150)
> at org.jboss.as.ejb3.component.stateless.StatelessComponentDescription$3.configure(StatelessComponentDescription.java:150)
> at org.jboss.as.ee.component.DefaultComponentViewConfigurator.configure(DefaultComponentViewConfigurator.java:68)
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81)
> ... 6 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Marek Kopecký reassigned WFCORE-306:
------------------------------------
Assignee: Marek Kopecký (was: Darran Lofthouse)
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Marek Kopecký
> Fix For: 3.0.0.Alpha3
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Marek Kopecký reassigned WFCORE-306:
------------------------------------
Assignee: Darran Lofthouse (was: Marek Kopecký)
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha3
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months