[JBoss-dev] [ jboss-Bugs-616546 ] Exposed properties not serializable
Bugs item #616546, was opened at 2002-09-30 15:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=616546group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: Exposed properties not serializable Initial Comment: JBoss 3.0.x, 3.2.0beta2, Solaris (concerns all platforms). I try to read the ManagedConnectionFactoryProperties of a data source using MEJB (jsr77), but Management management = getManagementMEJB(); ... management.getAttribute( dataSourceName, ManagedConnectionFactoryPropertie s ); results in a NotSerializableException, because neither the Crimson nor the Xerces implementation of org.w3c.dom.Element is serializable. In general, all attributes exposed by MBeans should be serializable, otherwise they are not accessible through MEJB. Exposing XML fragments in an MBean may be convenient for the programmer, but is of little use for the clients. Regards Georg -- Comment By: Georg Schmid (giorgio42) Date: 2002-10-01 09:41 Message: Logged In: YES user_id=437570 IMHO: If the attribute is exposed (named in the list of attributes available to MEJB), then it must be readable, too. Publishing the attribute name and throwing an exception when it is actually accessed does not make sense to me. My 0.02$. Regards Georg -- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-30 16:40 Message: Logged In: NO It is a requirement for an EJB remote interface to return either serializable or Remote types though, is it not? -- Comment By: Georg Schmid (giorgio42) Date: 2002-09-30 16:13 Message: Logged In: YES user_id=437570 Ok. Understood. This means, MEJB is only a second-class citizen in the JMX world. Georg -- Comment By: David Jencks (d_jencks) Date: 2002-09-30 16:10 Message: Logged In: YES user_id=60525 Sorry, there is no requirement that mbean attributes be serializable, however convenient it might be for you. The particular problem you are having I hope to address soon in jboss 4 by exposing the ManagedConnectionFactory itself as an mbean: the mcf properties, all of which are serializable, will appear as mbean attributes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=616546group_id=22866 --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-613360 ] Verifier: abstract-schema-name
Bugs item #613360, was opened at 2002-09-23 21:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_id=22866 Category: JBossServer Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dain Sundstrom (dsundstrom) Assigned to: Christian Riege (lqd) Summary: Verifier: abstract-schema-name Initial Comment: 10.3.13 An abstract-schema-name element for each entity bean. The abstract-schema-name must be a valid Java identifier and must be unique within the ejb-jar file. 10.6.14 The Bean Provider should not use reserved identifiers as ejb-names or abstract-schema-names. Reserved identifiers are discussed in Section 11.2.6.1. 22.2 Entity Beans abstract schema name. If the enterprise bean is an Entity Bean with container-managed persistence and cmp-version 2.x, the Bean Provider must specify the abstract schema name of the entity bean using the abstract-schema-name element. I suggest we make this an enforced error in 3.2 and 4.0 but only a warning in 3.0. -- Comment By: Christian Riege (lqd) Date: 2002-10-01 11:06 Message: Logged In: YES user_id=176671 Fixed in 3.2. Backport to 3.0 when I have the time (includes some more changes), 4.0 will get a new Verification logic anyways so I don't see its worthwhile actually porting this. -- Comment By: Christian Riege (lqd) Date: 2002-09-24 15:06 Message: Logged In: YES user_id=176671 Hm, the Spec is (as usual) a bit ambigious in some cases here: according to the spec the rules of ejb-name being a valid Java Identifier only apply to CMP 2.0 Entity Beans. There's no mentioning of this on BMP, Session or Message Driven Beans. IMO we should enforce this on all types of EJB's though, it Just makes sense and it'll be consistent. Dain, what's your opinion on this issue? Of course this change hoses some parts of the testsuite and a couple of default JBoss Components (e.g. the JMX-EJB Adaptor). I'll try to fix these as I go along but I don't think I will catch all :). -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-23 21:02 Message: Logged In: YES user_id=251431 The valid Java identifier rule also applies to ejb-name so the common style name 'my/app/MyBean' name is not legal. Again, I think this should be enforced in 3.2 and 4.0 but not in 3.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_id=22866 --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-613349 ] Verifier: queries must be declared
Bugs item #613349, was opened at 2002-09-23 20:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613349group_id=22866 Category: JBossServer Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dain Sundstrom (dsundstrom) Assigned to: Christian Riege (lqd) Summary: Verifier: queries must be declared Initial Comment: 10.5.6 Every finder method except findByPrimaryKey(key) must be associated with a query element in the deployment descriptor. 10.5.7 Every select method must be associated with a query element in the deployment descriptor. I suggest we make this an enforced error in 3.2 and 4.0 but only a warning in 3.0. -- Comment By: Christian Riege (lqd) Date: 2002-10-01 11:08 Message: Logged In: YES user_id=176671 Fixed in 3.2. Backport to 3.0 when I have the time (includes some more changes), 4.0 will get a new Verification logic anyways so I don't see its worthwhile actually porting this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613349group_id=22866 --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-594563 ] Include of JSP jumps to top of page
Bugs item #594563, was opened at 2002-08-13 05:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=594563group_id=22866
Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jeff Miner (jeff_miner)
Assigned to: Scott M Stark (starksm)
Summary: Include of JSP jumps to top of page
Initial Comment:
OS: Win98
JDK: 1.4
I have some code that manually does a JSP include
by getting a RequestDispatcher. The code worked
under Weblogic 5.1 and 6. In Jboss/Catalina,
although there are no errors thrown, the output from
the included JSP gets put at the top of the containing
page rather than in the middle where it was called.
This is puzzling because it ought to be exactly the
same as a jsp:include ... tag (and I assume those
work!)
**Containing Page***
tabletrtd
%= myObject.getOutput(request, response) %
/td/tr/table...
*** Object
public String getOutput(HttpServletRequest request,
HttpServletResponse response) {
RequestDispatcher dispatch =
context.getRequestDispatcher(someJSP.jsp);
try {
dispatch.include(request, response);
} catch(Exception e){}
return ;
*
The output from someJSP.jsp should go inside the
table, but instead it goes at the top of the containing
page.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-01 02:44
Message:
Logged In: NO
Try using
%pageContext.getOut().flush();%
The following works for me
html
head/head
body
about to include stuff --
%
pageContext.getOut().flush();
RequestDispatcher rd = application.getRequestDispatcher
(/Included.jsp);
rd.include(request, response);
%
-- finished including stuff
/body
/html
whereas this does not:
html
head/head
body
about to include stuff --
%
response.flushBuffer();
RequestDispatcher rd = application.getRequestDispatcher
(/Included.jsp);
rd.include(request, response);
%
-- finished including stuff
/body
/html
Regards,
Alex Sumner
--
Comment By: Jeff Miner (jeff_miner)
Date: 2002-09-30 20:07
Message:
Logged In: YES
user_id=592596
nobody: I tried flushing the buffer (response.flushBuffer())
both before (makes sense) and after (a desperate move),
but it didn't help.
starksm: Version No.? When was it fixed? My version is
not that old, I don't think.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-30 03:43
Message:
Logged In: NO
The jump to the top of the page is due to the buffer not being
flushed. The given example is the same as a jsp include
without a buffer flush. If you want the buffer flushed, you have
to explicitly code that.
--
Comment By: Scott M Stark (starksm)
Date: 2002-09-28 20:12
Message:
Logged In: YES
user_id=175228
This was a jasper issue that has been fixed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=594563group_id=22866
---
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server
today at http://www.ServePath.com/indexfm.htm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha Group,
make sure you add the getMethod and setMethod mapping to your MMB
attributes.
Thanks. I did this and started re-reading your JMX book. I now have a new
error :)
Below, I include my MBean Info generation code, and some error output. When
I try to view the jmx-console page for my new MBean, the servlet tries to
get all of the bean's attributes. The attribute getId is requested, but
this information is stored by the name Id. I assume that there is
something wrong with my MBean info, but I can't figure out what it is.
Error debug output are listed below. Any help would be appreciated.
- Matt
### metadata generation
public ModelMBeanInfo getModelMBeanInfo()
{
final boolean READABLE = true;
final boolean WRITABLE = true;
final boolean BOOLEAN = true;
// build 'Id' read-write attribute
Descriptor descr1 = new DescriptorSupport();
descr1.setField(name, Id);
descr1.setField(descriptorType, attribute);
descr1.setField(displayName, Identification);
descr1.setField(setMethod, setId);
descr1.setField(getMethod, getId);
ModelMBeanAttributeInfo idAttrInfo;
idAttrInfo = new ModelMBeanAttributeInfo(Id,
String.class.getName(),
Identification.,
READABLE,
WRITABLE,
!BOOLEAN,
descr1);
// MBean descriptor
Descriptor descr4 = new DescriptorSupport();
descr4.setField(name, Widget);
descr4.setField(descriptorType, mbean); // was MBean
// create ModelMBeanInfo
ModelMBeanAttributeInfo[] attrInfo = new ModelMBeanAttributeInfo[] {
idAttrInfo };
ModelMBeanOperationInfo[] operationInfo = new ModelMBeanOperationInfo[]
{};
ModelMBeanInfo info = new
ModelMBeanInfoSupport(RequiredModelMBean.class.getName(),
Widget,
attrInfo,
null,
operationInfo,
null,
descr4);
return info;
}
### AttributeOperationREsolver constructor
11:33:33,020 INFO [STDOUT] !!!m attributes[0]:
ModelMBeanAttributeInfo[Name=Id,Type=java.lang.String,Access=RW,Descript
or(setMethod=setId,descriptorType=attribute,name=Id,displayName=Identificati
on,getMethod=getId)]
### AttributeOperationREsolver.store()
11:33:33,020 INFO [STDOUT] !!!m storing attrName: Id and code: 0
### AttributeOperationREsolver.lookup()
11:34:06,141 INFO [STDOUT] !!!m looking up actionName: getId and signature:
[Ljava.lang.String;@1c87031
### error
java.lang.NoSuchMethodException: Unable to locate method for: getId()
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:300)
at
org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn
terceptor.java:66)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:54)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:91)
at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:129)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:99)
at
org.jboss.mx.server.MBeanInvoker.getAttribute(MBeanInvoker.java:110)
at
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBe
an.java:147)
at
org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:455)
at
org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java
:125)
at
org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:179)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
02)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:362)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:284)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:216)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:151)
at
RE: [JBoss-dev] creating persistent MBeans dynamically
do you have operation info for the operation names you are mapping to
(setId getId)?
On Tue, 1 Oct 2002, Matt Munz wrote:
Juha Group,
make sure you add the getMethod and setMethod mapping to your MMB
attributes.
Thanks. I did this and started re-reading your JMX book. I now have a new
error :)
Below, I include my MBean Info generation code, and some error output. When
I try to view the jmx-console page for my new MBean, the servlet tries to
get all of the bean's attributes. The attribute getId is requested, but
this information is stored by the name Id. I assume that there is
something wrong with my MBean info, but I can't figure out what it is.
Error debug output are listed below. Any help would be appreciated.
- Matt
### metadata generation
public ModelMBeanInfo getModelMBeanInfo()
{
final boolean READABLE = true;
final boolean WRITABLE = true;
final boolean BOOLEAN = true;
// build 'Id' read-write attribute
Descriptor descr1 = new DescriptorSupport();
descr1.setField(name, Id);
descr1.setField(descriptorType, attribute);
descr1.setField(displayName, Identification);
descr1.setField(setMethod, setId);
descr1.setField(getMethod, getId);
ModelMBeanAttributeInfo idAttrInfo;
idAttrInfo = new ModelMBeanAttributeInfo(Id,
String.class.getName(),
Identification.,
READABLE,
WRITABLE,
!BOOLEAN,
descr1);
// MBean descriptor
Descriptor descr4 = new DescriptorSupport();
descr4.setField(name, Widget);
descr4.setField(descriptorType, mbean); // was MBean
// create ModelMBeanInfo
ModelMBeanAttributeInfo[] attrInfo = new ModelMBeanAttributeInfo[] {
idAttrInfo };
ModelMBeanOperationInfo[] operationInfo = new ModelMBeanOperationInfo[]
{};
ModelMBeanInfo info = new
ModelMBeanInfoSupport(RequiredModelMBean.class.getName(),
Widget,
attrInfo,
null,
operationInfo,
null,
descr4);
return info;
}
### AttributeOperationREsolver constructor
11:33:33,020 INFO [STDOUT] !!!m attributes[0]:
ModelMBeanAttributeInfo[Name=Id,Type=java.lang.String,Access=RW,Descript
or(setMethod=setId,descriptorType=attribute,name=Id,displayName=Identificati
on,getMethod=getId)]
### AttributeOperationREsolver.store()
11:33:33,020 INFO [STDOUT] !!!m storing attrName: Id and code: 0
### AttributeOperationREsolver.lookup()
11:34:06,141 INFO [STDOUT] !!!m looking up actionName: getId and signature:
[Ljava.lang.String;@1c87031
### error
java.lang.NoSuchMethodException: Unable to locate method for: getId()
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:300)
at
org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn
terceptor.java:66)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:54)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:91)
at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:129)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:99)
at
org.jboss.mx.server.MBeanInvoker.getAttribute(MBeanInvoker.java:110)
at
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBe
an.java:147)
at
org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:455)
at
org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java
:125)
at
org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:179)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
02)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:362)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
Re: [JBoss-dev] permanently association xa connection with transaction
Thank you, David. This is exactly the behaviour I am looking for. David Jencks wrote: This is in HEAD and 3.2. Both Local and XAConnectionManagers are wrappers around TxConnectionManager. In XA and TxConnectionManager you can set TrackConnectionByTx to eliminate all intermediate end(suspend) and start(resume) calls. Also, all work on one tx will go through one connection. A side effect of this (currently at least) is that a connection will only be usable by one tx until the tx commits. david jencks On 2002.09.30 18:41:47 -0400 Igor Fedorenko wrote: Hi, I rememeber there was a discussion about keeping jdbc xa connection allocated for a transaction until the transaction ends. Is it implemented? -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha,
do you have operation info for the operation names you are mapping to
(setId getId)?
Nope, and I now see where this causes the problem. At least I'm learning...
Thanks for all the assistance.
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Juha-P Lindfors
Sent: Tuesday, October 01, 2002 12:20 PM
To: JBoss Developers Group
Subject: RE: [JBoss-dev] creating persistent MBeans dynamically
do you have operation info for the operation names you are mapping to
(setId getId)?
On Tue, 1 Oct 2002, Matt Munz wrote:
Juha Group,
make sure you add the getMethod and setMethod mapping to your MMB
attributes.
Thanks. I did this and started re-reading your JMX book. I now have a
new
error :)
Below, I include my MBean Info generation code, and some error output.
When
I try to view the jmx-console page for my new MBean, the servlet tries to
get all of the bean's attributes. The attribute getId is requested, but
this information is stored by the name Id. I assume that there is
something wrong with my MBean info, but I can't figure out what it is.
Error debug output are listed below. Any help would be appreciated.
- Matt
### metadata generation
public ModelMBeanInfo getModelMBeanInfo()
{
final boolean READABLE = true;
final boolean WRITABLE = true;
final boolean BOOLEAN = true;
// build 'Id' read-write attribute
Descriptor descr1 = new DescriptorSupport();
descr1.setField(name, Id);
descr1.setField(descriptorType, attribute);
descr1.setField(displayName, Identification);
descr1.setField(setMethod, setId);
descr1.setField(getMethod, getId);
ModelMBeanAttributeInfo idAttrInfo;
idAttrInfo = new ModelMBeanAttributeInfo(Id,
String.class.getName(),
Identification.,
READABLE,
WRITABLE,
!BOOLEAN,
descr1);
// MBean descriptor
Descriptor descr4 = new DescriptorSupport();
descr4.setField(name, Widget);
descr4.setField(descriptorType, mbean); // was MBean
// create ModelMBeanInfo
ModelMBeanAttributeInfo[] attrInfo = new ModelMBeanAttributeInfo[] {
idAttrInfo };
ModelMBeanOperationInfo[] operationInfo = new
ModelMBeanOperationInfo[]
{};
ModelMBeanInfo info = new
ModelMBeanInfoSupport(RequiredModelMBean.class.getName(),
Widget,
attrInfo,
null,
operationInfo,
null,
descr4);
return info;
}
### AttributeOperationREsolver constructor
11:33:33,020 INFO [STDOUT] !!!m attributes[0]:
ModelMBeanAttributeInfo[Name=Id,Type=java.lang.String,Access=RW,Descript
or(setMethod=setId,descriptorType=attribute,name=Id,displayName=Identificati
on,getMethod=getId)]
### AttributeOperationREsolver.store()
11:33:33,020 INFO [STDOUT] !!!m storing attrName: Id and code: 0
### AttributeOperationREsolver.lookup()
11:34:06,141 INFO [STDOUT] !!!m looking up actionName: getId and
signature:
[Ljava.lang.String;@1c87031
### error
java.lang.NoSuchMethodException: Unable to locate method for: getId()
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:300)
at
org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn
terceptor.java:66)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:54)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:91)
at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:129)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:99)
at
org.jboss.mx.server.MBeanInvoker.getAttribute(MBeanInvoker.java:110)
at
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBe
an.java:147)
at
org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:455)
at
org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java
:125)
at
org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:179)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
[JBoss-dev] Set interface implementation
I'm working on a bug 576410. The problem is that we need a Set implementation that will order elements by its addition to the set. I called it SequencedSet. There are two main approaches: implement it from scratch extending AbstractSet or on top of something. I talked with Dain and he advised me on-top and pointed to SequencedHashMap from Apache commons-collections (it's really nice). Now the problem: - SequencedSet needs to be in client's class path in both approaches. Let it be. - in on-top approach the class SequencedHashMap needs to be in client's classpath too. i.e. +1 jar for client. That's not so nice. Indeed, SequencedHashMap can be taken out from commons-collections.jar. But that's not nice too. Any thoughts? Thanks. alex PS: Dain currently isn't available. --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-595672 ] Deserialization broken in JBoss 3.01
Bugs item #595672, was opened at 2002-08-15 18:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=595672group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: Wont Fix Priority: 8 Submitted By: Boris Tamarkin (upss) Assigned to: Dain Sundstrom (dsundstrom) Summary: Deserialization broken in JBoss 3.01 Initial Comment: Win2000 operating system MySQL or MS SQLServer 2000 databases mapping in standardjbosscmp-jdbc.xml (same as in 3.0) for mySQL java-typejava.lang.Object/java-type jdbc-typeJAVA_OBJECT/jdbc-type sql-typeLONGBLOB/sql-type java-typejava.lang.Object/java-type jdbc-typeJAVA_OBJECT/jdbc-type sql-typeIMAGE/sql-type Repeat scenario Having CMP2 entity bean with one Object atribute. Call setObject works fine and store as a Blob in database. When trying to retreive after, failure happens. Stacktrace attached below *Notes: 1. Serialization and deserialization doing only with 3.01 version of JBoss 2. Not trying to deserealize old blobs (I am aware of it can be not supported and compatible with earlier version of JBoss) 3. This functionality and same code works fine with previous JBoss 3.0 version, but it is broken in 3.01. Thanks Stacktrace * 10:51:02,738 ERROR [LogInterceptor] TransactionRolledbackLocalException, causedB y: java.sql.SQLException: Unable to load to deserialize result: java.io.StreamCorru ptedException: invalid stream header at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.convertByteArra yToObject(JDBC Util.java:612) at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.getResult (JDBCUtil.java:311) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMP FieldBridge.load ArgumentResults (JDBCAbstractCMPFieldBridge.java:350) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMP FieldBridge.load InstanceResults(JDBCAbstractCMPFieldBridge.java:304) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityComman d.execute(JDBCLoad EntityCommand.java:142) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityComman d.execute(JDBCLoad EntityCommand.java:62) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.load Entity(JDBCStoreM anager.java:572) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntit y(CMPPersistence Manager.java:410) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.load Entity(CachedConnectionInterceptor.java:353) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv oke(EntityS ynchronizationInterceptor.java:262) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invo ke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke (EntityInstance Interceptor.java:152) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke (EntityLockIntercep tor.java:107) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke (EntityCreation Interceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInte rceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxIntercep torCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:6 0) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor. java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:203) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:493) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv oke(BaseLoca lContainerInvoker.java:301) at org.jboss.ejb.plugins.local.EntityProxy.invoke (EntityProxy.java:38) at $Proxy161.getKeyValue(Unknown Source) at com.rendition.MyEJB.retrieveKey (MyEJB.java:155) ** -- Comment By: Boris Tamarkin (upss) Date: 2002-09-27 00:09 Message: Logged In: YES user_id=595649 I wanted to add: Scenario is: 1.start JBoss3.02 2.serialize object with CMP and persist 3. deserialize object (everything works great) 4. Shutdown Jboss 5.start jBoss 6. deserialize again persisted object Boom !!! Exception Doesn't works for String, and for byte[] -- Comment By: Boris Tamarkin (upss) Date: 2002-09-27 00:05 Message: Logged In: YES user_id=595649 Hi Dan, The problem still exists in 3.02 as well. In 3.02 deserialization works fine until first shut down the server. Next time server starting, same exception happens (please see below). So probably in 3.02 was work around of keeping in cash? But it is still broken though. **Important note: objects were serialized and deserialized in 3.02. So, something big missing here. I have tested with 3 databases: mySQL, SQLServer2000 and Oracle9i And You can't not to use Blob if You want to store crypto key for example. If it is impossible
Re: [JBoss-dev] XADataSource wrapper for JBoss 4
Title: FW: [JBoss-dev] XADataSource wrapper for JBoss 4 Hi Igor. I applied the patchand initially found the XAResourceTest tests ran successfully a number of times. Ive found that after running the XAResourceTest, if l leave SQL Server running,stop and start JBoss and then run the test again, the testSimpleCommitTx test fails (see the log extract below). Ive started having a look at it - if you dont think its worth the effort let me know. Given the senario the exception occurs under and thepresence of static objects, is it possible that either the MS JDBC drivers or the VM could behanging onto something that is messing up the works? Jamie line 238 :tx.delistResource(xares, XAResource.TMSUCCESS); line 239: tx.commit(); Log Extract: 2002-09-30 20:20:36,987 WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] errorCode=XAER_RMERRjavax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_end (400) returns -6at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source)at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.end(Unknown Source)at com.microsoft.jdbcx.base.BaseXAResource.end(Unknown Source)at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:118)at org.jboss.tm.TransactionImpl.endResource(TransactionImpl.java:1353)at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:727)at org.jboss.test.jca.tm.XAResourceTest.testSimpleCommitTx(XAResourceTest.java:238)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:548)at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:265)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)at sun.rmi.transport.Transport$1.run(Transport.java:148)at java.security.AccessController.doPrivileged(Native Method)at sun.rmi.transport.Transport.serviceCall(Transport.java:144)at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)at java.lang.Thread.run(Thread.java:536)2002-09-30 20:20:36,997 WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] errorCode=XAER_RMERRjavax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_end (400) returns -6at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source)at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.end(Unknown Source)at com.microsoft.jdbcx.base.BaseXAResource.end(Unknown Source)at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:118)at org.jboss.tm.TransactionImpl.endResource(TransactionImpl.java:1353)at org.jboss.tm.TransactionImpl.endResources(TransactionImpl.java:1428)at org.jboss.tm.TransactionImpl.checkStatusForPrepare(TransactionImpl.java:1917)at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:308)at org.jboss.test.jca.tm.XAResourceTest.testSimpleCommitTx(XAResourceTest.java:239)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:548)at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:265)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)at sun.rmi.transport.Transport$1.run(Transport.java:148)at java.security.AccessController.doPrivileged(Native Method)at sun.rmi.transport.Transport.serviceCall(Transport.java:144)at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)at
Re: [JBoss-dev] XADataSource wrapper for JBoss 4
I suspect this might be a limitation of the current jboss XidFactory... namely it starts over with global ids every time you restart jboss. If you leave SQLServer running, it may object if it gets the same xid later on that it committed earlier. Is there an easy way to see if this is the problem? thanks david jencks On 2002.10.01 17:04:10 -0400 Jamie Burns wrote: FW: [JBoss-dev] XADataSource wrapper for JBoss 4Hi Igor. I applied the patch and initially found the XAResourceTest tests ran successfully a number of times. Ive found that after running the XAResourceTest, if l leave SQL Server running, stop and start JBoss and then run the test again, the testSimpleCommitTx test fails (see the log extract below). Ive started having a look at it - if you dont think its worth the effort let me know. Given the senario the exception occurs under and the presence of static objects, is it possible that either the MS JDBC drivers or the VM could be hanging onto something that is messing up the works? Jamie line 238 : tx.delistResource(xares, XAResource.TMSUCCESS); line 239:tx.commit(); Log Extract: 2002-09-30 20:20:36,987 WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_end (400) returns -6 at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source) at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.end(Unknown Source) at com.microsoft.jdbcx.base.BaseXAResource.end(Unknown Source) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:118) at org.jboss.tm.TransactionImpl.endResource(TransactionImpl.java:1353) at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:727) at org.jboss.test.jca.tm.XAResourceTest.testSimpleCommitTx(XAResourceTest.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:548) at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:265) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:536) 2002-09-30 20:20:36,997 WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_end (400) returns -6 at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source) at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.end(Unknown Source) at com.microsoft.jdbcx.base.BaseXAResource.end(Unknown Source) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:118) at org.jboss.tm.TransactionImpl.endResource(TransactionImpl.java:1353) at org.jboss.tm.TransactionImpl.endResources(TransactionImpl.java:1428) at org.jboss.tm.TransactionImpl.checkStatusForPrepare(TransactionImpl.java:1917) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:308) at org.jboss.test.jca.tm.XAResourceTest.testSimpleCommitTx(XAResourceTest.java:239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:548) at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:265) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
RE: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss?
No, my entity name is: !DOCTYPE jbosscmp-jdbc PUBLIC -//JBoss//DTD JBOSS-CMP-JDBC 3.0//EN http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd; Which I took from a jbosscmp-jdbc.xml from jboss/testsuite. On the side it would be nice if we had pages on jboss.org which describes each of our XML documents. Thanks for checking =] --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Saturday, September 28, 2002 4:47 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss? Based on the XmlFileLoader.getDocument(XmlFileLoader.java:257) line number this is the current 3.0 source and this does have a local entity resolver for jbosscmp-jdbc_3_0.dtd provided you are using the correct public entity name: !DOCTYPE jbosscmp-jdbc PUBLIC -//JBoss//DTD JBOSSCMP-JDBC 3.0//EN http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd; Does your jbosscmp-jdbc.xml DOCTYPE look this this? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 27, 2002 10:40 PM Subject: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss? I am getting exceptions like the follwing because for some reason www.jboss.org is down. Sup with that? --jason 22:36:58,880 ERROR [XmlFileLoader] External entity not found: http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd.:-1:4 java.net.ConnectException: Connection timed out at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java:2 796) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1155) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:489) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.ja va:185) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:86) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:257) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD Matrix2) Testsuite Results: 2-October-2002
Number of tests run: 976 Successful tests: 959 Errors:15 Failures: 2 [time of test: 2 October 2002 1:50 GMT] [java.version: 1.3.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_03-b03] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/sun_jdk131_03 for the junit report of this test. - http://lubega.com/testarchive/sun_jdk131_03/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-481358 ] UserTransaction bug reproducible
Bugs item #481358, was opened at 2001-11-13 09:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=481358group_id=22866 Category: JBossTX Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Daniel OConnor (docodan) Assigned to: Andreas Schaefer (schaefera) Summary: UserTransaction bug reproducible Initial Comment: This is a resubmission of bug #472868, because I couldn't figure out how to attach code to an existing, closed report. I believe that UserTransaction is still broken with session synchronization as of 2.4.3. I have attached a JAR with complete source code that will reproduce the bug on this JBoss distribution. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-01 18:44 Message: Logged In: NO my penis has reddish pimples all over the tip, it gets pretty sore after urination - i was with 6 prostitutes last night and didn't use a condom, the 5 wemon and 1 cross dresser said they were desease free - do you think i got aids? -- Comment By: Markus Menner (labo) Date: 2001-12-09 22:11 Message: Logged In: YES user_id=397834 This could be the same bug as #486416!? Markus -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-15 15:59 Message: Logged In: YES user_id=70434 Yeah, yeah. It seems I am stupid. Finally I got it and it really shows me that with a transaction the data are not saved. Andy -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-15 15:35 Message: Logged In: YES user_id=70434 Either I am stupid or there is no bug. Took the source, build it and deployed it on the current CVS Branch_2_4 and it run through without a hintch (or is this the problem). Andy -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=481358group_id=22866 --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-614116 ] Oracle XA pooling/repeated rollback
Bugs item #614116, was opened at 2002-09-24 19:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Oracle XA pooling/repeated rollback
Initial Comment:
I've been trying to isolate some problems I've been
having with transaction roll-backs and message-driven
beans. Basically, when a transaction is rolled-back
a number of times in the onMessage() body
(by calling MessageDrivenContext.setRollbackOnly()
5-10 times in succession),
the message is re-delivered to the MDB, but the Oracle
Connection is no longer in a good state.
This problem manifests itself when using a very small
connection pool (say 1-5) connections.
Example code snippet:
public void onMessage(javax.jms.Message jmsMessage)
{
Connection c = null;
try {
TextMessage tm = (TextMessage)jmsMessage;
String text = tm.getText();
c = ds.getConnection();
PreparedStatement s = c.prepareStatement(insert into test values (?));
s.setString(1, text);
s.executeUpdate();
mdc.setRollbackOnly();
} catch (Exception e) {
throw new EJBException(e);
} finally {
if (c != null) {
try { c.close(); }
catch (Exception e) {
e.printStackTrace();
}
}
First I see it works for a few times. It rolls-back successfully
about 5 or 6 times. Then, for no reason, I see:
15:50:44,922 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.delistResource(TxCapsule.java:579)
at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:92)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.delist(XATxConnectionManager.java:284)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.connectionClosed(XATxConnectionManager.java:331)
at
org.jboss.resource.adapter.jdbc.BaseManagedConnection.fireConnectionEvent(BaseManagedConnection.java:152)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.fireConnectionEvent(XAManagedConnection.java:215)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection$1.connectionClosed(XAManagedConnection.java:127)
at
oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:482)
at
oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:445)
at oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:2900)
at oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1418)
at com.proteusmobile.smx.AMDB.onMessage(AMDB.java:140)
Later:
15:50:44,929 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1312)
at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:440)
at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:83)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:301)
at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:603)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:417)
at org.jboss.mq.SpySession.run(SpySession.java:259)
at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655)
at java.lang.Thread.run(Thread.java:479)
And then, I can no longer get a connection:
15:50:44,971 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//5,
BranchQual=] errorCode=XAER_PROTO
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.disallowLocalTxnMode(OracleXAResource.java:1045)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:153)
at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1180)
at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:679)
at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:102)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.enlist(XATxConnectionManager.java:262)
at
[JBoss-dev] [ jboss-Bugs-614116 ] Oracle XA pooling/repeated rollback
Bugs item #614116, was opened at 2002-09-24 16:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Oracle XA pooling/repeated rollback
Initial Comment:
I've been trying to isolate some problems I've been
having with transaction roll-backs and message-driven
beans. Basically, when a transaction is rolled-back
a number of times in the onMessage() body
(by calling MessageDrivenContext.setRollbackOnly()
5-10 times in succession),
the message is re-delivered to the MDB, but the Oracle
Connection is no longer in a good state.
This problem manifests itself when using a very small
connection pool (say 1-5) connections.
Example code snippet:
public void onMessage(javax.jms.Message jmsMessage)
{
Connection c = null;
try {
TextMessage tm = (TextMessage)jmsMessage;
String text = tm.getText();
c = ds.getConnection();
PreparedStatement s = c.prepareStatement(insert into test values (?));
s.setString(1, text);
s.executeUpdate();
mdc.setRollbackOnly();
} catch (Exception e) {
throw new EJBException(e);
} finally {
if (c != null) {
try { c.close(); }
catch (Exception e) {
e.printStackTrace();
}
}
First I see it works for a few times. It rolls-back successfully
about 5 or 6 times. Then, for no reason, I see:
15:50:44,922 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.delistResource(TxCapsule.java:579)
at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:92)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.delist(XATxConnectionManager.java:284)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.connectionClosed(XATxConnectionManager.java:331)
at
org.jboss.resource.adapter.jdbc.BaseManagedConnection.fireConnectionEvent(BaseManagedConnection.java:152)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.fireConnectionEvent(XAManagedConnection.java:215)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection$1.connectionClosed(XAManagedConnection.java:127)
at
oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:482)
at
oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:445)
at oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:2900)
at oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1418)
at com.proteusmobile.smx.AMDB.onMessage(AMDB.java:140)
Later:
15:50:44,929 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1312)
at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:440)
at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:83)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:301)
at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:603)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:417)
at org.jboss.mq.SpySession.run(SpySession.java:259)
at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655)
at java.lang.Thread.run(Thread.java:479)
And then, I can no longer get a connection:
15:50:44,971 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//5,
BranchQual=] errorCode=XAER_PROTO
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.disallowLocalTxnMode(OracleXAResource.java:1045)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:153)
at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1180)
at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:679)
at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:102)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.enlist(XATxConnectionManager.java:262)
at
[JBoss-dev] [ jboss-Bugs-565237 ] StatefulHandleImpl not serializable
Bugs item #565237, was opened at 2002-06-06 04:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=565237group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Stephen Coy (scoy) Assigned to: Scott M Stark (starksm) Summary: StatefulHandleImpl not serializable Initial Comment: JBoss 3.0.0 final MacOS X 10.1.5 Java 1.3.1 The class org.jboss.proxy.ejb.handle.StatefulHandleImpl is not properly serializable because (I think) it has an org.jboss.invocation.Invoker member. Some invoker implementations are serializable and some are not. I have a stateful session bean containing a collection of data objects containing back pointers (via javax.ejb.Handle) to the session bean. Passivation of the session bean fails while serializing the data objects: 2002-06-06 18:06:23,806 ERROR [org.jboss.logging.Log4jService$ThrowableListenerLoggingAdapter] unhandled throwable java.rmi.ServerException: Could not passivate; nested exception is: java.rmi.MarshalException: Invalid remote object java.rmi.MarshalException: Invalid remote object at java.rmi.server.RemoteObject.writeObject(RemoteObject.java:153) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectOutputStream.invokeObjectWriter(ObjectOutputStrea m.java:1864) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.jav a:1210) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java: 366) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.writeExtern al(JRMPInvokerProxy.java:149) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.jav a:1180) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java: 366) at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStrea m.java:1827) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStrea m.java:480) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.jav a:1214) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java: 366) at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStrea m.java:1827) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStrea m.java:480) at com.whitesmiths.sacha.ejb.worklists.interfaces.WorklistElement. writeObject(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectOutputStream.invokeObjectWriter(ObjectOutputStrea m.java:1864) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.jav a:1210) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java: 366) at java.io.ObjectOutputStream.outputArray(ObjectOutputStream.java: 1098) at java.io.ObjectOutputStream.checkSubstitutableSpecialClasses(Ob jectOutputStream.java:456) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java: 361) at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStrea m.java:1827) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStrea m.java:480) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.jav a:1214) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java: 366) at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStrea m.java:1827) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStrea m.java:480) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.jav a:1214) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java: 366) at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.pas sivateSession(StatefulSessionFilePersistenceManager.java:288) at org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(Sta tefulSessionInstanceCache.java:78) at org.jboss.ejb.plugins.AbstractInstanceCache$1.execute(AbstractIn stanceCache.java:615) at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:20 6) at java.lang.Thread.run(Thread.java:496) 2002-06-06 18:06:39,260 DEBUG [org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy] Resized cache for bean Priv: old capacity = 100, new capacity = 50 2002-06-06 18:06:59,049 DEBUG [org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy] Resized cache for bean GSMServiceFacade: old capacity = 100, new capacity = 50 2002-06-06 18:07:00,982 DEBUG [org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy] Resized cache for bean NumberStatus: old capacity = 100, new capacity = 50 2002-06-06 18:07:02,759 DEBUG [org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy] Resized cache for bean GSMService: old capacity = 100, new capacity = 50 2002-06-06 18:07:11,227 DEBUG [org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy] Resized cache for bean Numbers: old capacity = 100, new capacity = 50
Re: [JBoss-dev] [ANN] Cache-invalidation commited
On Mon, 30 Sep 2002, Sacha Labourey wrote: Hello, I've just commited a generic cache-invalidation mechansim to HEAD (mainly in org.jboss.cache.invalidation). Some of the code and ideas comes from Bill Burke's implementation of the Seppuku algorithm that has been recently commited. drool! Is this code completly generic? How tied is it to jboss(not that I really care, but if it could be a separate project, ...). I have read all this, and it looks absolutely wonderful. I only have one comment tho: [snip] Local Caches A cache, will get access to the local InvalidationManager and will subscribe using an appropriate InvalidationGroup (i.e. shared identifier, name). Whenever an invalidation message is received by the IM for this IG, the cache will receive a callback. Caches and related object must implement the *Invalidable* interface. Wouldn't Invalidatable be a better name? --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
