April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBUILD-348) Figure out a way to warn the user if the deploy repository variables are not set.

by Paul Gier (JIRA)

Figure out a way to warn the user if the deploy repository variables are not set. --------------------------------------------------------------------------------- Key: JBBUILD-348 URL: http://jira.jboss.com/jira/browse/JBBUILD-348 Project: JBoss Build System Issue Type: Feature Request Reporter: Paul Gier Assigned To: Paul Gier Fix For: jboss-deploy-maven-plugin-1.2.GA There are two deployment variables. One for the local checkout of the jboss repository, and one for the maven repository. It would be nice if the build scripts could give some warning if either of these are not set when calling "mvn deploy" and then point the user to some explanation about how to set these either in settings.xml or from the command line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBBUILD-74) Validatable Build Files

by Paul Gier (JIRA)

[ http://jira.jboss.com/jira/browse/JBBUILD-74?page=all ] Paul Gier closed JBBUILD-74. ---------------------------- Resolution: Done Created an xsd file for component-info. Added a check in the jboss deploy plugin to run the verification. > Validatable Build Files > ----------------------- > > Key: JBBUILD-74 > URL: http://jira.jboss.com/jira/browse/JBBUILD-74 > Project: JBoss Build System > Issue Type: Feature Request > Affects Versions: JBossBuild-1.1 DR1 > Reporter: Ryan Campbell > Assigned To: Paul Gier > Fix For: jboss-deploy-maven-plugin-1.2.GA > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Create xsd schemas for the component, componentdef, and build elements so that developers can validate their component-info.xml and jbossbuild.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBAS-1955) XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions

by Magesh Kumar B (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1955?page=all ] Magesh Kumar B resolved JBAS-1955. ---------------------------------- Fix Version/s: JBossAS-4.2.0.GA JBossAS-4.0.5.SP1 (was: JBossAS-4.2.0.CR1) Resolution: Done Fixed and available in their respective branches Branch_4_0 Branch_4_2 trunk > XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions > ----------------------------------------------------------------------------------- > > Key: JBAS-1955 > URL: http://jira.jboss.com/jira/browse/JBAS-1955 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Management services > Affects Versions: JBossAS-4.0.2 Final > Environment: jmx, twiddle > Reporter: Fabiano C. de Oliveira > Assigned To: Magesh Kumar B > Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.GA, JBossAS-4.0.5.SP1 > > Attachments: JBAS-1955a.zip > > Time Spent: 3 days, 3 hours > Remaining Estimate: 0 minutes > > This patch add a Interceptor to org.jboss.jmx.connector.invoker.InvokerAdaptorService besides AuthenticationInterceptor that is responsable for prevent remote clients to launch NonSerializable exception. > The interception have 3 types of action: Invisible, Null and Wrapper. > In the Invisible mode all NonSerializable fields are ignored so if you call getMBeanInfo all NonSerializable will be remove and returned to your remote client(twiddle, MC4J, etc). This mode is more tested so it is recommended. > In the null mode NonSerializable fields are visible but always return Null. > The wraper mode is not implemented, but the idea is replace the NonSerializable Class for another > The interceptor is only a class. The tests are in the patch too. Only test for invisible mode. I´m still doing tests for the other modes. > Any idea is very appreciated. I dont have sufficient time to work more in this code. But I hope to do soon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-1955) XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions

by Magesh Kumar B (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1955?page=comments#action_12358653 ] Magesh Kumar B commented on JBAS-1955: -------------------------------------- Most of Fabiano C. de Oliveira's code helped again. Kudos for his work and our bad that we did not implement his complete works! > XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions > ----------------------------------------------------------------------------------- > > Key: JBAS-1955 > URL: http://jira.jboss.com/jira/browse/JBAS-1955 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Management services > Affects Versions: JBossAS-4.0.2 Final > Environment: jmx, twiddle > Reporter: Fabiano C. de Oliveira > Assigned To: Magesh Kumar B > Fix For: JBossAS-4.2.0.CR1, JBossAS-5.0.0.Beta2 > > Attachments: JBAS-1955a.zip > > Time Spent: 3 days > Remaining Estimate: 0 minutes > > This patch add a Interceptor to org.jboss.jmx.connector.invoker.InvokerAdaptorService besides AuthenticationInterceptor that is responsable for prevent remote clients to launch NonSerializable exception. > The interception have 3 types of action: Invisible, Null and Wrapper. > In the Invisible mode all NonSerializable fields are ignored so if you call getMBeanInfo all NonSerializable will be remove and returned to your remote client(twiddle, MC4J, etc). This mode is more tested so it is recommended. > In the null mode NonSerializable fields are visible but always return Null. > The wraper mode is not implemented, but the idea is replace the NonSerializable Class for another > The interceptor is only a class. The tests are in the patch too. Only test for invisible mode. I´m still doing tests for the other modes. > Any idea is very appreciated. I dont have sufficient time to work more in this code. But I hope to do soon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBAS-1955) XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions

by Magesh Kumar B (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1955?page=all ] Magesh Kumar B reopened JBAS-1955: ---------------------------------- Assignee: Magesh Kumar B (was: Dimitris Andreadis) It seems that when you run twiddle, the getAttributes method is called and the NotSerializableException still exists. > XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions > ----------------------------------------------------------------------------------- > > Key: JBAS-1955 > URL: http://jira.jboss.com/jira/browse/JBAS-1955 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Management services > Affects Versions: JBossAS-4.0.2 Final > Environment: jmx, twiddle > Reporter: Fabiano C. de Oliveira > Assigned To: Magesh Kumar B > Fix For: JBossAS-4.2.0.CR1, JBossAS-5.0.0.Beta2 > > Attachments: JBAS-1955a.zip > > > This patch add a Interceptor to org.jboss.jmx.connector.invoker.InvokerAdaptorService besides AuthenticationInterceptor that is responsable for prevent remote clients to launch NonSerializable exception. > The interception have 3 types of action: Invisible, Null and Wrapper. > In the Invisible mode all NonSerializable fields are ignored so if you call getMBeanInfo all NonSerializable will be remove and returned to your remote client(twiddle, MC4J, etc). This mode is more tested so it is recommended. > In the null mode NonSerializable fields are visible but always return Null. > The wraper mode is not implemented, but the idea is replace the NonSerializable Class for another > The interceptor is only a class. The tests are in the patch too. Only test for invisible mode. I´m still doing tests for the other modes. > Any idea is very appreciated. I dont have sufficient time to work more in this code. But I hope to do soon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1248) Regression: Fix Consumer tests on 4.0.5 using JBoss WS 1.0.4

by Chris Laprun (JIRA)

Regression: Fix Consumer tests on 4.0.5 using JBoss WS 1.0.4 ------------------------------------------------------------ Key: JBPORTAL-1248 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1248 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.6.Alpha2 Reporter: Chris Laprun Assigned To: Chris Laprun Fix For: 2.6.Beta1 Seems like there's a problem with the way Sessions are handled/passed by the WS stack. The problem does not occur on 4.0.5 (which uses 1.0.3.SP1). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-780) no-loop results in NullPointer in RuleTerminalNode.retractTuple

by Mark Proctor (JIRA)

no-loop results in NullPointer in RuleTerminalNode.retractTuple --------------------------------------------------------------- Key: JBRULES-780 URL: http://jira.jboss.com/jira/browse/JBRULES-780 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.1-m1 Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m2 no-loop is currently trapped with: // if the current Rule is no-loop and the origin rule is the same then return if ( this.rule.getNoLoop() && this.rule.equals( context.getRuleOrigin() ) ) { return; } That means we have a tuple that reached the terminal node, but is not added to the memory or an activation created and attached. Thus on a modify or a retract the Tuple reaches the RuleTerminalNode and causes a Null pointer. The Q is, do we just do a null check and return, or do we do another no-loop check, my worry with just a null check is that it may mask other bugs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-778) fact handle used in consequences even for fields

by Mark Proctor (JIRA)

fact handle used in consequences even for fields ------------------------------------------------ Key: JBRULES-778 URL: http://jira.jboss.com/jira/browse/JBRULES-778 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.1-m1 Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m2 If you bind to a field and then do a modify( var ) it will use the handle of the parent object, which is obviously wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-771) Expose agenda group events

by Mark Proctor (JIRA)

Expose agenda group events -------------------------- Key: JBRULES-771 URL: http://jira.jboss.com/jira/browse/JBRULES-771 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Reteoo Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m2 pushed and popped agneda groups should be exposed in the event model.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-767) autocomplete for static classes fails

by Mark Proctor (JIRA)

autocomplete for static classes fails ------------------------------------- Key: JBRULES-767 URL: http://jira.jboss.com/jira/browse/JBRULES-767 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Eclipse IDE Affects Versions: 3.1-m1 Reporter: Mark Proctor Assigned To: Kris Verlaenen Fix For: 3.1-m2 Autocomplete for static classes overrites the entire import with just the static name. import org.drools.Cheesery.Maturity; ends up as: import Maturity; When I try to use autocomplete for the Maturity class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
1
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 April 2007