September 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1109) Exported BRMS repositories lose version history

by Shahad Ahmed (JIRA)

Exported BRMS repositories lose version history ----------------------------------------------- Key: JBRULES-1109 URL: http://jira.jboss.com/jira/browse/JBRULES-1109 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.0.GA Environment: Windows XP SP2, SUN JRE 1.5_09 Reporter: Shahad Ahmed Assigned To: Mark Proctor I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History. If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option? Here's how to replicate the problem for a clean BRMS install: 1. Create a new category called test. 2. In the defaultPackage create a new technical rule called test as shown below: when eval(true) then System.out.println("Hello"); 3. Save the test rule 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule. 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository. 6. From Admin/Manage Backups save the repository. 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository). 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost. -- 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

18 years, 8 months

4
6
0 / 0

[JBoss JIRA] Resolved: (JBREM-129) remove oswego-concurrent lib

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-129?page=all ] Ron Sigal resolved JBREM-129. ----------------------------- Resolution: Won't Fix Assignee: (was: Tom Elrod) The premise of this issue, that oswego-concurrent jar is only being used by test code, is no longer true: org.jboss.remoting.Client uses org.jboss.util.id.GUID (from the common-core project) for its sessionId, and GUID uses org.jboss.util.id.UID, which uses an EDU.oswego.cs.dl.util.concurrent.SynchronizedLong. > remove oswego-concurrent lib > ---------------------------- > > Key: JBREM-129 > URL: http://jira.jboss.com/jira/browse/JBREM-129 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Priority: Optional > Fix For: 2.4.0.CR1 (Pinto) > > > The oswego-concurrent jar is only being used by test code. If change this code to not use concurrent then can remove jar from remoting project (and distribution). -- 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

18 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-433) point to multipoint invocation api

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-433?page=all ] Ron Sigal updated JBREM-433: ---------------------------- Fix Version/s: 3.0.0.Alpha1 (Otter) (was: 2.4.0.Beta1 (Pinto)) Affects Version/s: 2.2.2.GA (was: 2.0.0.Beta1) There's not point in working on this issue until Remoting 3.0. > point to multipoint invocation api > ---------------------------------- > > Key: JBREM-433 > URL: http://jira.jboss.com/jira/browse/JBREM-433 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.2.2.GA > Reporter: Tom Elrod > Assigned To: David Lloyd > Fix For: 3.0.0.Alpha1 (Otter) > > > Would like to provide API where client could make single invocation that would be made on multiple remoting servers at one time. The responses for each target server would be aggregated into one response as return to the client call. Basically want to mimic same behavior found within jgroups for this, but provide support over all the transports for this. -- 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

18 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1673) Update documentation with JBoss AS version to use (4.2.1)

by Antoine Herzog (JIRA)

Update documentation with JBoss AS version to use (4.2.1) --------------------------------------------------------- Key: JBPORTAL-1673 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1673 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Reference Guide Affects Versions: 2.6.1 Final Environment: JBP 2.6.1 GA Reporter: Antoine Herzog Assigned To: Julien Viet Priority: Minor Fix For: 2.6.2 Final In the reference guide, (v 2.6.1 dated 25 july 2007), there is : 2.2. Installing from Binary Download "... please install JBoss 4.0.5+ from here ." I guess, now, it is not anymore 4.0.5, but 4.2.1 there should be some other place where this happens (system requirements, etc...) some clarification about using 4.0.5 or 4.2.1 will be welcome too. may be a few links to some wiki about important things to care for the portal, about moving from 4.0.5 to 4.2.1.... Such as the JSF implementation. -- 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

18 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-733) When org.jboss.remoting.Client.addListener() creates a Connector, it should pass in InvokerLocator parameters with configuration map.

by Ron Sigal (JIRA)

When org.jboss.remoting.Client.addListener() creates a Connector, it should pass in InvokerLocator parameters with configuration map. ------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-733 URL: http://jira.jboss.com/jira/browse/JBREM-733 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Currently, Client.addListener() is just passing in Client.configuration. It should also add the InvokerLocator parameters so that the server configuration, e.g., XML service file, can contribute to the configuration of a callback server invoker. -- 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

18 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-730) JNDIDetector should use rebind() instead of bind() to add new local detection messages

by Ron Sigal (JIRA)

JNDIDetector should use rebind() instead of bind() to add new local detection messages -------------------------------------------------------------------------------------- Key: JBREM-730 URL: http://jira.jboss.com/jira/browse/JBREM-730 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Currently, JNDIDetector.registerDetectionMsg() is using javax.naming.Context.bind() to add a new local detection message to the JNDI server, which means it can't overwrite a detection message that already exists. It should call Context.rebind() instead. -- 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

18 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-717) servlet invoker illegal state exception not serializable

by John Mazzitelli (JIRA)

servlet invoker illegal state exception not serializable -------------------------------------------------------- Key: JBREM-717 URL: http://jira.jboss.com/jira/browse/JBREM-717 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod I have my server-side using the servlet invoker (I'm inside JBossAS 4.0.5). After I shutdown and try to restart, I think I might not be restarting properly. If a client sends in a message, I get this stack trace and an HTTP 500 error comes across on the client. Here's the server-side stack: 15:59:05,510 WARN [[ServerInvokerServlet]] Servlet.service() for servlet ServerInvokerServlet threw exception java.io.NotSerializableException: org.jboss.remoting.transport.servlet.ServletServerInvoker at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at org.jboss.remoting.marshal.http.HTTPMarshaller.write(HTTPMarshaller.java:69) at org.jboss.remoting.transport.servlet.ServletServerInvoker.processRequest(ServletServerInvoker.java:257) at sun.reflect.GeneratedMethodAccessor183.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201) at $Proxy185.processRequest(Unknown Source) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.processRequest(ServerInvokerServlet.java:127) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.doPost(ServerInvokerServlet.java:156) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:595) So this IllegalStateException is thrown because something didn't get restarted. But the fact that this IllegalStateException is defined inside the ServerInvoker object makes it not serializable (ServerInvoker.IllegalStateException is not serializable because ServerInvoker is not serializable). This issue is to document the fact that this exception is not serializable - the whole "restart didn't fully restart" problem is something that may be my fault. Recommend that you split out IllegalStateException so you can send it over the wire - or thrown a java.lang.IllegalStateException. This is in 2.0.0.GA. I haven't tried to see if this is an issue in later versions. -- 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

18 years, 8 months

4
10
0 / 0

[JBoss JIRA] Created: (JBRULES-1159) Function calls for not work for the MVEL dialect

by Mark Proctor (JIRA)

Function calls for not work for the MVEL dialect ------------------------------------------------ Key: JBRULES-1159 URL: http://jira.jboss.com/jira/browse/JBRULES-1159 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.1, 4.0.0.GA Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 4.0.2 MVEL dialect cannot call DRL functions or static method functions on existing classes. -- 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

18 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-789) Release 2.2.1.SP1

by Ron Sigal (JIRA)

Release 2.2.1.SP1 ----------------- Key: JBREM-789 URL: http://jira.jboss.com/jira/browse/JBREM-789 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal -- 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

18 years, 8 months

1
8
0 / 0

[JBoss JIRA] Created: (JBREM-796) Verify Remoting 2.2.2 is compatible with earlier versions

by Ron Sigal (JIRA)

Verify Remoting 2.2.2 is compatible with earlier versions --------------------------------------------------------- Key: JBREM-796 URL: http://jira.jboss.com/jira/browse/JBREM-796 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.GA Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.GA Need to add version 2.2.0.SP4 jboss-remoting.jar to src/etc/lib and run tests.versioning.all. -- 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

18 years, 8 months

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