December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3707) ObjectDataCompiler converter does not compile all template rules

by Guy Baharav (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3707?page=com.atlassian.jira.plug... ] Guy Baharav updated JBRULES-3707: --------------------------------- Labels: Commpiler Templates (was: ) Description: When trying to compile a rule template with a datasource of a lot of rows (more than 1000), the compilers only compiles the first 1286 lines in the datasource. Here is the code I am using: //50,000 classes are created in the collection Collection<FRTRule> freights = FilesLoader.GetFreightRules(); ObjectDataCompiler converter = new ObjectDataCompiler(); //a very simple rule template is loaded. final InputStream templateStream = new Object().getClass().getResourceAsStream( "/Rules/Freight.drl" ); //only 1286 rules are created in the drl string. String drl = converter.compile( freights, templateStream ); Here is the rules template syntax: template header pol package com.zim.pricing.rules import com.zim.PricingPOC.PricingUI.FRTRule; template Pricing rule "Pricing_(a){row.rowNumber}" when m : FRTRule(pol == "@{pol}") then m.setPol("1"); end end template What could the reason be that the compiler only compiles 1286 rules? Thanks, Guy was: When trying to compile a rule template with a datasource of a lot of rows (more than 1000), the compilers only compiles the first 1286 lines in the datasource. Here is the code I am using: //50,000 classes are created in the collection Collection<FRTRule> freights = FilesLoader.GetFreightRules(); ObjectDataCompiler converter = new ObjectDataCompiler(); //a very simple rule template is loaded. final InputStream templateStream = new Object().getClass().getResourceAsStream( "/Rules/Freight.drl" ); //only 1286 rules are created in the drl string. String drl = converter.compile( freights, templateStream ); Here is the rules template syntax: > ObjectDataCompiler converter does not compile all template rules > ---------------------------------------------------------------- > > Key: JBRULES-3707 > URL: https://issues.jboss.org/browse/JBRULES-3707 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-compiler (expert) > Affects Versions: 5.3.0.Final > Environment: Windows 7 32 bit > Reporter: Guy Baharav > Assignee: Mark Proctor > Labels: Commpiler, Templates > > When trying to compile a rule template with a datasource of a lot of rows (more than 1000), the compilers only compiles the first 1286 lines in the datasource. > Here is the code I am using: > //50,000 classes are created in the collection > Collection<FRTRule> freights = FilesLoader.GetFreightRules(); > ObjectDataCompiler converter = new ObjectDataCompiler(); > //a very simple rule template is loaded. > final InputStream templateStream = new Object().getClass().getResourceAsStream( "/Rules/Freight.drl" ); > //only 1286 rules are created in the drl string. > String drl = converter.compile( freights, templateStream ); > Here is the rules template syntax: > template header > pol > package com.zim.pricing.rules > import com.zim.PricingPOC.PricingUI.FRTRule; > template Pricing > rule "Pricing_(a){row.rowNumber}" > when > m : FRTRule(pol == "@{pol}") > then > m.setPol("1"); > end > end template > What could the reason be that the compiler only compiles 1286 rules? > Thanks, > Guy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (JBRULES-3707) ObjectDataCompiler converter does not compile all template rules

by Guy Baharav (JIRA)

Guy Baharav created JBRULES-3707: ------------------------------------ Summary: ObjectDataCompiler converter does not compile all template rules Key: JBRULES-3707 URL: https://issues.jboss.org/browse/JBRULES-3707 Project: JBRULES Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.3.0.Final Environment: Windows 7 32 bit Reporter: Guy Baharav Assignee: Mark Proctor When trying to compile a rule template with a datasource of a lot of rows (more than 1000), the compilers only compiles the first 1286 lines in the datasource. Here is the code I am using: //50,000 classes are created in the collection Collection<FRTRule> freights = FilesLoader.GetFreightRules(); ObjectDataCompiler converter = new ObjectDataCompiler(); //a very simple rule template is loaded. final InputStream templateStream = new Object().getClass().getResourceAsStream( "/Rules/Freight.drl" ); //only 1286 rules are created in the drl string. String drl = converter.compile( freights, templateStream ); Here is the rules template syntax: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1802) Sending MapMessage with large String value is broken

by Justin Bertram (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1802?page=com.atlassian.jira.... ] Justin Bertram commented on JBMESSAGING-1802: --------------------------------------------- [~jsightler], did you see the code comment in Howard's previous comment? It says: {noformat} We DO NOT support Strings written to BytesMessages or StreamMessages or written as keys or values in MapMessages, or as String properties or other String fields having serialized length >= 64K {noformat} > Sending MapMessage with large String value is broken > ---------------------------------------------------- > > Key: JBMESSAGING-1802 > URL: https://issues.jboss.org/browse/JBMESSAGING-1802 > Project: JBoss Messaging > Issue Type: Feature Request > Affects Versions: 1.4.0.SP3.CP10, 1.4.6.GA > Reporter: Justin Bertram > Assignee: Yong Hao Gao > Fix For: 1.4.8.SP10 > > > Sending a javax.jms.MapMessage that has a String value >= 65536 characters fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1802) Sending MapMessage with large String value is broken

by Jess Sightler (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1802?page=com.atlassian.jira.... ] Jess Sightler commented on JBMESSAGING-1802: -------------------------------------------- I believe that this same issue also impacts StreamMessages. Messages that have had writeString called on them fail when the string is over 65535 characters. writeList is called, but the "longStrings" parameter is not passed to it. Then it calls writeObject with longStrings set to false. To my view, this is a bug, as longStrings is being set by the caller, but not passed all the way down the callstack to the writeList method (and its subsequent method calls). > Sending MapMessage with large String value is broken > ---------------------------------------------------- > > Key: JBMESSAGING-1802 > URL: https://issues.jboss.org/browse/JBMESSAGING-1802 > Project: JBoss Messaging > Issue Type: Feature Request > Affects Versions: 1.4.0.SP3.CP10, 1.4.6.GA > Reporter: Justin Bertram > Assignee: Yong Hao Gao > Fix For: 1.4.8.SP10 > > > Sending a javax.jms.MapMessage that has a String value >= 65536 characters fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6204) Upgrade Infinispan to 5.2.0.Beta6

by Paul Ferraro (JIRA)

Paul Ferraro created AS7-6204: --------------------------------- Summary: Upgrade Infinispan to 5.2.0.Beta6 Key: AS7-6204 URL: https://issues.jboss.org/browse/AS7-6204 Project: Application Server 7 Issue Type: Component Upgrade Components: Clustering Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6179) Upgrade Hibernate Validator to 4.3.1.Final

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-6179?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-6179: ----------------------------------- org.hibernate.validator.engine.ConstraintValidatorFactoryImpl is now org.hibernate.validator.internal.engine.ConstraintValidatorFactoryImpl. > Upgrade Hibernate Validator to 4.3.1.Final > ------------------------------------------ > > Key: AS7-6179 > URL: https://issues.jboss.org/browse/AS7-6179 > Project: Application Server 7 > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1 > Reporter: Juergen Zimmermann > Assignee: Scott Marlow > Fix For: 7.2.0.Alpha1 > > > JBossAS currently contains 4.2.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6179) Upgrade Hibernate Validator to 4.3.1.Final

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-6179?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-6179: ----------------------------------- If I ignore the above build failure, I also get the following compile error when attempting to build as7/testsuite/integration/basic. See http://pastie.org/5544053 > Upgrade Hibernate Validator to 4.3.1.Final > ------------------------------------------ > > Key: AS7-6179 > URL: https://issues.jboss.org/browse/AS7-6179 > Project: Application Server 7 > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1 > Reporter: Juergen Zimmermann > Assignee: Scott Marlow > Fix For: 7.2.0.Alpha1 > > > JBossAS currently contains 4.2.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6203) WebSSLDefinition NAME attribute is read-write

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6203: ------------------------------------- Summary: WebSSLDefinition NAME attribute is read-write Key: AS7-6203 URL: https://issues.jboss.org/browse/AS7-6203 Project: Application Server 7 Issue Type: Bug Components: Domain Management, Web Affects Versions: 7.1.3.Final (EAP) Reporter: Brian Stansberry Priority: Minor Fix For: 7.3.0.Alpha1 WebSSLDefinition has a read-write attribute NAME that AFAICT merely stores the name of an xml element. If the attribute represents part of a resource address it should be read-only. If it's just some cruft (which appears to be the case), it should be deprecated and removed in some later release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6186) Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations

by Marek Schmidt (JIRA)

[ https://issues.jboss.org/browse/AS7-6186?page=com.atlassian.jira.plugin.s... ] Marek Schmidt updated AS7-6186: ------------------------------- Attachment: AS7-6186-viewMap.tar reproducer source > Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations > ----------------------------------------------------- > > Key: AS7-6186 > URL: https://issues.jboss.org/browse/AS7-6186 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: 7.1.4.Final (EAP) > Environment: Current 7.1.4.Final-SNAPSHOT (2012-12-15), Mojarra 2.1.16, Seam2.3.0.Final > Reporter: Marek Schmidt > Assignee: Stan Silvert > Priority: Critical > Attachments: AS7-6186-viewMap.tar, AS7-6186-viewMap.war, seam-booking.ear > > > Recent Mojarra upgrade seems to break Seam 2.3.0 conversations. > Not exactly sure yet what has changed and whether it is a Mojarra bug or Seam depending on something it shouldn't. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-711) LdapExtAdLoginModule proposal for inclusion

by Anil Saldhana (JIRA)

[ https://issues.jboss.org/browse/SECURITY-711?page=com.atlassian.jira.plug... ] Anil Saldhana commented on SECURITY-711: ---------------------------------------- Peter - I am unsure if you have been following on the latest security work we are doing for PicketLink v3. There is a lot of LDAP related stuff ongoing. http://lists.jboss.org/pipermail/security-dev/ To subscribe: https://lists.jboss.org/mailman/listinfo/security-dev We hope you can become a valuable contributor. :) Regarding this JIRA issue, I am going to sit on it until we get AD testing in place. > LdapExtAdLoginModule proposal for inclusion > ------------------------------------------- > > Key: SECURITY-711 > URL: https://issues.jboss.org/browse/SECURITY-711 > Project: PicketBox > Issue Type: Patch > Security Level: Public(Everyone can see) > Components: PicketBox, Security SPI > Affects Versions: PicketBox_4_0_14.Final > Environment: jboss7, active directory authentication > Reporter: Péter Radics > Assignee: Anil Saldhana > Priority: Minor > Labels: LdapExtLoginModule, active-directory, security > Attachments: picketbox-r359-LdapExtLoginModule.patch, picketbox-r362-LdapExtAdLoginModule.patch, picketbox-r363-LdapExtAdLoginModule-with-history.patch > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Please consider including the attached LdapExtAdLoginModule into the official release. This login module is based on r362 of LdapExtLoginModule, but it's better suited for deeply nested Active Directory domains: it only uses one search for the userDN then it's resolving the roles recursively by querying attributes on DNs only. (as a side-effect, it doesn't trigger AS7-5737) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

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 December 2012