[JBoss JIRA] (JBLOGGING-113) OSGi header declares non-optional dependency to Log4j packages
by Gunnar Morling (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-113?page=com.atlassian.jira.plu... ]
Gunnar Morling commented on JBLOGGING-113:
------------------------------------------
Sent pull request https://github.com/jboss-logging/jboss-logging/pull/19
> OSGi header declares non-optional dependency to Log4j packages
> --------------------------------------------------------------
>
> Key: JBLOGGING-113
> URL: https://issues.jboss.org/browse/JBLOGGING-113
> Project: JBoss Logging
> Issue Type: Bug
> Affects Versions: 3.2.1.Final
> Reporter: Gunnar Morling
> Assignee: James Perkins
>
> Currently the following packages are specified via the {{Import-Package}} header:
> {code}
> org.apache.log4j;resolution:=optional,
> org.apache.logging.log4j;version="[2.0,3)";resolution:=optional,
> org.apache.logging.log4j.message;version="[2.0,3)",
> org.apache.logging.log4j.spi;version="[2.0,3)",
> org.jboss.logmanager;version="[1.5,2)";resolution:=optional,
> org.slf4j;version="[1.7,2)";resolution:=optional,
> org.slf4j.spi;version="[1.7,2)";resolution:=optional
> {code}
> I think it should be this instead:
> {code}
> org.apache.log4j;resolution:=optional,
> org.apache.logging.log4j;version="[2.0,3)";resolution:=optional,
> org.apache.logging.log4j.message;version="[2.0,3)";resolution:=optional,
> org.apache.logging.log4j.spi;version="[2.0,3)";resolution:=optional,
> org.jboss.logmanager;version="[1.5,2)";resolution:=optional,
> org.slf4j;version="[1.7,2)";resolution:=optional,
> org.slf4j.spi;version="[1.7,2)";resolution:=optional
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JBLOGGING-113) OSGi header declares non-optional dependency to Log4j packages
by Gunnar Morling (JIRA)
Gunnar Morling created JBLOGGING-113:
----------------------------------------
Summary: OSGi header declares non-optional dependency to Log4j packages
Key: JBLOGGING-113
URL: https://issues.jboss.org/browse/JBLOGGING-113
Project: JBoss Logging
Issue Type: Bug
Affects Versions: 3.2.1.Final
Reporter: Gunnar Morling
Assignee: James Perkins
Currently the following packages are specified via the {{Import-Package}} header:
{code}
org.apache.log4j;resolution:=optional,
org.apache.logging.log4j;version="[2.0,3)";resolution:=optional,
org.apache.logging.log4j.message;version="[2.0,3)",
org.apache.logging.log4j.spi;version="[2.0,3)",
org.jboss.logmanager;version="[1.5,2)";resolution:=optional,
org.slf4j;version="[1.7,2)";resolution:=optional,
org.slf4j.spi;version="[1.7,2)";resolution:=optional
{code}
I think it should be this instead:
{code}
org.apache.log4j;resolution:=optional,
org.apache.logging.log4j;version="[2.0,3)";resolution:=optional,
org.apache.logging.log4j.message;version="[2.0,3)";resolution:=optional,
org.apache.logging.log4j.spi;version="[2.0,3)";resolution:=optional,
org.jboss.logmanager;version="[1.5,2)";resolution:=optional,
org.slf4j;version="[1.7,2)";resolution:=optional,
org.slf4j.spi;version="[1.7,2)";resolution:=optional
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-2627) EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-2627?page=com.atlassian.jira.plugin.... ]
Hynek Švábek resolved WFLY-2627.
--------------------------------
Resolution: Done
https://github.com/wildfly/wildfly/pull/4640
Pull request for test https://github.com/wildfly/wildfly/pull/7164
> EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-2627
> URL: https://issues.jboss.org/browse/WFLY-2627
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Environment: jdk1.7.0_45_x64, Windows 7
> Reporter: Norbert Bumm
> Assignee: David Lloyd
> Attachments: arquillian-jpa.zip, wildfly-src-7.2.0.Final-TransactionBug.patch
>
>
> If there is a global transaction declaration for “Supports” and a “Required” declaration for a specific Method the “Required” gets ignored. I first encountered the problem with an old 2.1 EJB, but the problem is also there with a 3.1 EJB with deployment descriptor. It works correct with annotations.
> ejb-jar.xml snippet
> {code:xml}
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Supports</trans-attribute>
> </container-transaction>
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>createUser</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4344) Upgrade Infinispan to 7.1.1.Final
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-4344:
----------------------------------
Summary: Upgrade Infinispan to 7.1.1.Final
Key: WFLY-4344
URL: https://issues.jboss.org/browse/WFLY-4344
Project: WildFly
Issue Type: Component Upgrade
Components: Clustering
Affects Versions: 9.0.0.Alpha1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 9.0.0.Beta1
Needed to pull in changes for ISPN-5173.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4343) Upgrade JGroups to 3.6.2.Final
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-4343:
----------------------------------
Summary: Upgrade JGroups to 3.6.2.Final
Key: WFLY-4343
URL: https://issues.jboss.org/browse/WFLY-4343
Project: WildFly
Issue Type: Component Upgrade
Components: Clustering
Affects Versions: 9.0.0.Alpha1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 9.0.0.Beta1
Needed to pull in fix for JGRP-1905.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-2627) EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2627?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2627:
-----------------------------------------------
hsvabek(a)redhat.com changed the Status of [bug 1180556|https://bugzilla.redhat.com/show_bug.cgi?id=1180556] from ON_QA to VERIFIED
> EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-2627
> URL: https://issues.jboss.org/browse/WFLY-2627
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Environment: jdk1.7.0_45_x64, Windows 7
> Reporter: Norbert Bumm
> Assignee: David Lloyd
> Attachments: arquillian-jpa.zip, wildfly-src-7.2.0.Final-TransactionBug.patch
>
>
> If there is a global transaction declaration for “Supports” and a “Required” declaration for a specific Method the “Required” gets ignored. I first encountered the problem with an old 2.1 EJB, but the problem is also there with a 3.1 EJB with deployment descriptor. It works correct with annotations.
> ejb-jar.xml snippet
> {code:xml}
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Supports</trans-attribute>
> </container-transaction>
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>createUser</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JBRULES-2640) Implement support for group-by (if an explicit construct is necessary) and distinct
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/JBRULES-2640?page=com.atlassian.jira.plug... ]
Matteo Mortari edited comment on JBRULES-2640 at 2/13/15 4:16 AM:
------------------------------------------------------------------
Is this a {{group-by}} intended to be in conjunction with {{accumulate}} ?
IFF so, normally I try to normalize it as per the below example; possibly doesn't cover all possible use-cases, but I thought maybe could be helpful in the time being.
{code}
declare GroupByString
groupId : String
groups : String[]
end
rule "init Metro hash of my interest"
no-loop
when
then
GroupByString grp = new GroupByString();
grp.setGroupId("metroHash");
grp.setGroups(new String[]{"#M1", "#M2"});
insert(grp);
end
rule "Multiple tweets about a metro line hash"
no-loop
when
$group : GroupByString( groupId == "metroHash")
$metroHash : String() from $group.groups
accumulate ( $tweet : Status( text contains $metroHash, inReplyToUserId == -1 ) over window:time( 5m ) ;
$list : collectList( $tweet ),
$count : count( $tweet );
$count >= 2
)
not Alert( condition == "Multiple tweets about a metro line hash "+$metroHash ) over window:time( 5m )
then
Status[] theTweets = new Status[$list.size()];
$list.toArray(theTweets); // TODO check: I've tried more concise one-liner syntax but fail KB compilation.
Alert<Status[]> alert = new Alert<Status[]>(sessionCurrentTime(kcontext),
"Multiple tweets about a metro line hash "+$metroHash,
AlertType.INFO,
theTweets);
insert(alert);
LOG.info("Multiple tweets for " + $metroHash + " count " + $count + " list: " + $list);
end
{code}
taken from here https://github.com/tarilabs/reex2014-rules/blob/master/src/main/resources...
was (Author: tari_manga):
Is this a {{group-by}} intended to be in conjunction with {{accumulate}} ?
IFF so, normally I try to normalize it as per the below example; possibly doesn't cover all possibly use-case, but I thought maybe could be helpful in the time being.
{code}
declare GroupByString
groupId : String
groups : String[]
end
rule "init Metro hash of my interest"
no-loop
when
then
GroupByString grp = new GroupByString();
grp.setGroupId("metroHash");
grp.setGroups(new String[]{"#M1", "#M2"});
insert(grp);
end
// Remember see JSON 'in_reply_to_user_id' if null actually will be -1 by convention of method getLong(String str) of Maven-Central / org.twitter4j / twitter4j-core / 3.0.5 / twitter4j.internal.json.z_T4JInternalParseUtil
rule "Multiple tweets about a metro line hash"
no-loop
when
$group : GroupByString( groupId == "metroHash")
$metroHash : String() from $group.groups
accumulate ( $tweet : Status( text contains $metroHash, inReplyToUserId == -1 ) over window:time( 5m ) ;
$list : collectList( $tweet ),
$count : count( $tweet );
$count >= 2
)
not Alert( condition == "Multiple tweets about a metro line hash "+$metroHash ) over window:time( 5m )
then
Status[] theTweets = new Status[$list.size()];
$list.toArray(theTweets); // TODO check: I've tried more concise one-liner syntax but fail KB compilation.
Alert<Status[]> alert = new Alert<Status[]>(sessionCurrentTime(kcontext),
"Multiple tweets about a metro line hash "+$metroHash,
AlertType.INFO,
theTweets);
insert(alert);
LOG.info("Multiple tweets for " + $metroHash + " count " + $count + " list: " + $list);
end
{code}
> Implement support for group-by (if an explicit construct is necessary) and distinct
> -----------------------------------------------------------------------------------
>
> Key: JBRULES-2640
> URL: https://issues.jboss.org/browse/JBRULES-2640
> Project: JBRULES
> Issue Type: Feature Request
> Components: All
> Affects Versions: 5.1.0.FINAL
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Labels: fusion_roadmap
> Fix For: FUTURE
>
>
> Implement support for group-by (if an explicit construct is necessary) and distinct
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JBRULES-2640) Implement support for group-by (if an explicit construct is necessary) and distinct
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/JBRULES-2640?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on JBRULES-2640:
-----------------------------------------
Is this a {{group-by}} intended to be in conjunction with {{accumulate}} ?
IFF so, normally I try to normalize it as per the below example; possibly doesn't cover all possibly use-case, but I thought maybe could be helpful in the time being.
{{
declare GroupByString
groupId : String
groups : String[]
end
rule "init Metro hash of my interest"
no-loop
when
then
GroupByString grp = new GroupByString();
grp.setGroupId("metroHash");
grp.setGroups(new String[]{"#M1", "#M2"});
insert(grp);
end
// Remember see JSON 'in_reply_to_user_id' if null actually will be -1 by convention of method getLong(String str) of Maven-Central / org.twitter4j / twitter4j-core / 3.0.5 / twitter4j.internal.json.z_T4JInternalParseUtil
rule "Multiple tweets about a metro line hash"
no-loop
when
$group : GroupByString( groupId == "metroHash")
$metroHash : String() from $group.groups
accumulate ( $tweet : Status( text contains $metroHash, inReplyToUserId == -1 ) over window:time( 5m ) ;
$list : collectList( $tweet ),
$count : count( $tweet );
$count >= 2
)
not Alert( condition == "Multiple tweets about a metro line hash "+$metroHash ) over window:time( 5m )
then
Status[] theTweets = new Status[$list.size()];
$list.toArray(theTweets); // TODO check: I've tried more concise one-liner syntax but fail KB compilation.
Alert<Status[]> alert = new Alert<Status[]>(sessionCurrentTime(kcontext),
"Multiple tweets about a metro line hash "+$metroHash,
AlertType.INFO,
theTweets);
insert(alert);
LOG.info("Multiple tweets for " + $metroHash + " count " + $count + " list: " + $list);
end
}}
> Implement support for group-by (if an explicit construct is necessary) and distinct
> -----------------------------------------------------------------------------------
>
> Key: JBRULES-2640
> URL: https://issues.jboss.org/browse/JBRULES-2640
> Project: JBRULES
> Issue Type: Feature Request
> Components: All
> Affects Versions: 5.1.0.FINAL
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Labels: fusion_roadmap
> Fix For: FUTURE
>
>
> Implement support for group-by (if an explicit construct is necessary) and distinct
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JBRULES-2640) Implement support for group-by (if an explicit construct is necessary) and distinct
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/JBRULES-2640?page=com.atlassian.jira.plug... ]
Matteo Mortari edited comment on JBRULES-2640 at 2/13/15 4:15 AM:
------------------------------------------------------------------
Is this a {{group-by}} intended to be in conjunction with {{accumulate}} ?
IFF so, normally I try to normalize it as per the below example; possibly doesn't cover all possibly use-case, but I thought maybe could be helpful in the time being.
{code}
declare GroupByString
groupId : String
groups : String[]
end
rule "init Metro hash of my interest"
no-loop
when
then
GroupByString grp = new GroupByString();
grp.setGroupId("metroHash");
grp.setGroups(new String[]{"#M1", "#M2"});
insert(grp);
end
// Remember see JSON 'in_reply_to_user_id' if null actually will be -1 by convention of method getLong(String str) of Maven-Central / org.twitter4j / twitter4j-core / 3.0.5 / twitter4j.internal.json.z_T4JInternalParseUtil
rule "Multiple tweets about a metro line hash"
no-loop
when
$group : GroupByString( groupId == "metroHash")
$metroHash : String() from $group.groups
accumulate ( $tweet : Status( text contains $metroHash, inReplyToUserId == -1 ) over window:time( 5m ) ;
$list : collectList( $tweet ),
$count : count( $tweet );
$count >= 2
)
not Alert( condition == "Multiple tweets about a metro line hash "+$metroHash ) over window:time( 5m )
then
Status[] theTweets = new Status[$list.size()];
$list.toArray(theTweets); // TODO check: I've tried more concise one-liner syntax but fail KB compilation.
Alert<Status[]> alert = new Alert<Status[]>(sessionCurrentTime(kcontext),
"Multiple tweets about a metro line hash "+$metroHash,
AlertType.INFO,
theTweets);
insert(alert);
LOG.info("Multiple tweets for " + $metroHash + " count " + $count + " list: " + $list);
end
{code}
was (Author: tari_manga):
Is this a {{group-by}} intended to be in conjunction with {{accumulate}} ?
IFF so, normally I try to normalize it as per the below example; possibly doesn't cover all possibly use-case, but I thought maybe could be helpful in the time being.
{{
declare GroupByString
groupId : String
groups : String[]
end
rule "init Metro hash of my interest"
no-loop
when
then
GroupByString grp = new GroupByString();
grp.setGroupId("metroHash");
grp.setGroups(new String[]{"#M1", "#M2"});
insert(grp);
end
// Remember see JSON 'in_reply_to_user_id' if null actually will be -1 by convention of method getLong(String str) of Maven-Central / org.twitter4j / twitter4j-core / 3.0.5 / twitter4j.internal.json.z_T4JInternalParseUtil
rule "Multiple tweets about a metro line hash"
no-loop
when
$group : GroupByString( groupId == "metroHash")
$metroHash : String() from $group.groups
accumulate ( $tweet : Status( text contains $metroHash, inReplyToUserId == -1 ) over window:time( 5m ) ;
$list : collectList( $tweet ),
$count : count( $tweet );
$count >= 2
)
not Alert( condition == "Multiple tweets about a metro line hash "+$metroHash ) over window:time( 5m )
then
Status[] theTweets = new Status[$list.size()];
$list.toArray(theTweets); // TODO check: I've tried more concise one-liner syntax but fail KB compilation.
Alert<Status[]> alert = new Alert<Status[]>(sessionCurrentTime(kcontext),
"Multiple tweets about a metro line hash "+$metroHash,
AlertType.INFO,
theTweets);
insert(alert);
LOG.info("Multiple tweets for " + $metroHash + " count " + $count + " list: " + $list);
end
}}
> Implement support for group-by (if an explicit construct is necessary) and distinct
> -----------------------------------------------------------------------------------
>
> Key: JBRULES-2640
> URL: https://issues.jboss.org/browse/JBRULES-2640
> Project: JBRULES
> Issue Type: Feature Request
> Components: All
> Affects Versions: 5.1.0.FINAL
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Labels: fusion_roadmap
> Fix For: FUTURE
>
>
> Implement support for group-by (if an explicit construct is necessary) and distinct
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months