[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 9-August-2002
Number of tests run: 897
Successful tests: 891
Errors:3
Failures: 3
[time of test: 9 August 2002 0:35 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See 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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-592495 ] Validate void return type for CMP setter
Bugs item #592495, was opened at 2002-08-08 10:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=592495group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Meadows (legerdemain) Assigned to: Christian Riege (lqd) Summary: Validate void return type for CMP setter Initial Comment: Recently wrote a CMP entity bean with the following code: ... public abstract int getOrgId(); public abstract int setOrgId(int orgId); public abstract int getSiteId(); public abstract int setSiteId(int siteId); public abstract int getId(); public abstract int setId(int id); ... i.e. with a return type of int in the setters. This causes the entity proxy to throw a NullPointerException. Now this was a really dumb thing to do but given that finding the problem was so difficult it might be good to have the validation check the return type of the setter methods. Original postings: http://www.jboss.org/forums/thread.jsp? forum=46thread=18830 -- Comment By: Christian Riege (lqd) Date: 2002-08-09 10:04 Message: Logged In: YES user_id=176671 OK, thanks it's better than nothing. So the NPE is only thrown on the client or do you see something in the server log, too?! From reading the thread in the forum I also gather that this only happens if the set accessor method is invoked on a compound primary key field? -- Comment By: Michael Meadows (legerdemain) Date: 2002-08-08 19:34 Message: Logged In: YES user_id=185411 Wow... you fixed it already. Thanks ;) The stack trace you requested unfortunately it doesn't say much because the proxy is generated straight to bytecode: 18:30:30,670 ERROR [LogInterceptor] TransactionRolledbackException, causedBy: java.lang.NullPointerException at com.visualfiles.workflow.ActivityAutoCreateBean$Proxy.setOr gId(gener ated) at com.visualfiles.workflow.ActivityAutoCreateBean.ejbCreate (ActivityAut oCreateBean.java:18) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity (CMPPersisten ceManager.java:221) at org.jboss.resource.connectionmanager.CachedConnectionInte rceptor.crea teEntity(CachedConnectionInterceptor.java:270) at org.jboss.ejb.EntityContainer.createLocalHome (EntityContainer.java:57 9) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHom e(EntityC ontainer.java:1116) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome (AbstractIntercep tor.java:73) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeH ome(Ent itySynchronizationInterceptor.java:209) at org.jboss.resource.connectionmanager.CachedConnectionInte rceptor.invo keHome(CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome (EntityInst anceInterceptor.java:88) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome (EntityLockInte rceptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome (EntityCrea tionInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInte rceptor.java:98) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions (TxIntercep torCMT.java:176) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome (TxInterceptorCMT.ja va:52) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome (SecurityIntercep tor.java:104) at org.jboss.ejb.plugins.LogInterceptor.invokeHome (LogInterceptor.java:1 18) at org.jboss.ejb.EntityContainer.invokeHome (EntityContainer.java:487) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invokeH ome(Base LocalContainerInvoker.java:227) at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke (LocalHomeProxy.java :110) at $Proxy170.create(Unknown Source) at com.visualfiles.workflow.ProcessTypeControllerBean.createAc tivityAuto Create(ProcessTypeControllerBean.java:588) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at
[JBoss-dev] [ jboss-Bugs-592495 ] Validate void return type for CMP setter
Bugs item #592495, was opened at 2002-08-08 10:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=592495group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Meadows (legerdemain) Assigned to: Christian Riege (lqd) Summary: Validate void return type for CMP setter Initial Comment: Recently wrote a CMP entity bean with the following code: ... public abstract int getOrgId(); public abstract int setOrgId(int orgId); public abstract int getSiteId(); public abstract int setSiteId(int siteId); public abstract int getId(); public abstract int setId(int id); ... i.e. with a return type of int in the setters. This causes the entity proxy to throw a NullPointerException. Now this was a really dumb thing to do but given that finding the problem was so difficult it might be good to have the validation check the return type of the setter methods. Original postings: http://www.jboss.org/forums/thread.jsp? forum=46thread=18830 -- Comment By: Christian Riege (lqd) Date: 2002-08-09 11:51 Message: Logged In: YES user_id=176671 michael, thanks for the clarification. will have a closer look at this. -- Comment By: Michael Meadows (legerdemain) Date: 2002-08-09 11:37 Message: Logged In: YES user_id=185411 The stack trace was from the server so the NPE is only thrown on the server. Not sure what the client receives. It was most probably a standard remote exception wrapper. The speculation about the primary key fields was because I'd only made the mistake with the primary key fields! So it may or may not be only primary key fields that suffer from this problem. :) -- Comment By: Christian Riege (lqd) Date: 2002-08-09 10:04 Message: Logged In: YES user_id=176671 OK, thanks it's better than nothing. So the NPE is only thrown on the client or do you see something in the server log, too?! From reading the thread in the forum I also gather that this only happens if the set accessor method is invoked on a compound primary key field? -- Comment By: Michael Meadows (legerdemain) Date: 2002-08-08 19:34 Message: Logged In: YES user_id=185411 Wow... you fixed it already. Thanks ;) The stack trace you requested unfortunately it doesn't say much because the proxy is generated straight to bytecode: 18:30:30,670 ERROR [LogInterceptor] TransactionRolledbackException, causedBy: java.lang.NullPointerException at com.visualfiles.workflow.ActivityAutoCreateBean$Proxy.setOr gId(gener ated) at com.visualfiles.workflow.ActivityAutoCreateBean.ejbCreate (ActivityAut oCreateBean.java:18) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity (CMPPersisten ceManager.java:221) at org.jboss.resource.connectionmanager.CachedConnectionInte rceptor.crea teEntity(CachedConnectionInterceptor.java:270) at org.jboss.ejb.EntityContainer.createLocalHome (EntityContainer.java:57 9) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHom e(EntityC ontainer.java:1116) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome (AbstractIntercep tor.java:73) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeH ome(Ent itySynchronizationInterceptor.java:209) at org.jboss.resource.connectionmanager.CachedConnectionInte rceptor.invo keHome(CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome (EntityInst anceInterceptor.java:88) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome (EntityLockInte rceptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome (EntityCrea tionInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInte rceptor.java:98) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions (TxIntercep torCMT.java:176) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome (TxInterceptorCMT.ja va:52) at
[JBoss-dev] [ jboss-Bugs-592495 ] Validate void return type for CMP setter
Bugs item #592495, was opened at 2002-08-08 10:43
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=592495group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael Meadows (legerdemain)
Assigned to: Christian Riege (lqd)
Summary: Validate void return type for CMP setter
Initial Comment:
Recently wrote a CMP entity bean with the following
code:
...
public abstract int getOrgId();
public abstract int setOrgId(int orgId);
public abstract int getSiteId();
public abstract int setSiteId(int siteId);
public abstract int getId();
public abstract int setId(int id);
...
i.e. with a return type of int in the setters.
This causes the entity proxy to throw a
NullPointerException.
Now this was a really dumb thing to do but given that
finding the problem was so difficult it might be good to
have the validation check the return type of the setter
methods.
Original postings:
http://www.jboss.org/forums/thread.jsp?
forum=46thread=18830
--
Comment By: Christian Riege (lqd)
Date: 2002-08-09 13:57
Message:
Logged In: YES
user_id=176671
I have found the source for the NPE on the server:
org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler
line 126:
} else if(methodName.startsWith(set)) {
field.setValue(ctx, args[0]);
return null;
}
i will have a chat with Dain on whether [w|h]e will fix this
or leave it at the verifier level.
--
Comment By: Christian Riege (lqd)
Date: 2002-08-09 11:51
Message:
Logged In: YES
user_id=176671
michael,
thanks for the clarification. will have a closer look at this.
--
Comment By: Michael Meadows (legerdemain)
Date: 2002-08-09 11:37
Message:
Logged In: YES
user_id=185411
The stack trace was from the server so the NPE is only
thrown on the server. Not sure what the client receives. It was
most probably a standard remote exception wrapper.
The speculation about the primary key fields was because I'd
only made the mistake with the primary key fields! So it may
or may not be only primary key fields that suffer from this
problem. :)
--
Comment By: Christian Riege (lqd)
Date: 2002-08-09 10:04
Message:
Logged In: YES
user_id=176671
OK, thanks it's better than nothing. So the NPE is only
thrown on the client or do you see something in the server
log, too?! From reading the thread in the forum I also
gather that this only happens if the set accessor method is
invoked on a compound primary key field?
--
Comment By: Michael Meadows (legerdemain)
Date: 2002-08-08 19:34
Message:
Logged In: YES
user_id=185411
Wow... you fixed it already. Thanks ;)
The stack trace you requested unfortunately it doesn't say
much because the proxy is generated straight to bytecode:
18:30:30,670 ERROR [LogInterceptor]
TransactionRolledbackException, causedBy:
java.lang.NullPointerException
at
com.visualfiles.workflow.ActivityAutoCreateBean$Proxy.setOr
gId(gener
ated)
at
com.visualfiles.workflow.ActivityAutoCreateBean.ejbCreate
(ActivityAut
oCreateBean.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.ejb.plugins.CMPPersistenceManager.createEntity
(CMPPersisten
ceManager.java:221)
at
org.jboss.resource.connectionmanager.CachedConnectionInte
rceptor.crea
teEntity(CachedConnectionInterceptor.java:270)
at org.jboss.ejb.EntityContainer.createLocalHome
(EntityContainer.java:57
9)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHom
e(EntityC
ontainer.java:1116)
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome
(AbstractIntercep
tor.java:73)
at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeH
ome(Ent
itySynchronizationInterceptor.java:209)
at
org.jboss.resource.connectionmanager.CachedConnectionInte
rceptor.invo
keHome(CachedConnectionInterceptor.java:215)
at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome
(EntityInst
anceInterceptor.java:88)
at
[JBoss-dev] YAJI (Yet Another JBoss Invoker)
Hi, I am also playing with a new invoker. Well, not really new... It is actually the JRMP invoker code, with just a few changes to sent the Invocation over IIOP rather than JRMP. In the lack of a better name, I am calling it JavaIIOPInvoker. JavaIIOPInvoker is quite different from the plain IIOPInvoker. It is also much simpler. By way of comparison: - IIOPInvoker allows IIOP access to the actual interfaces of deployed beans. When a client calls create() on an EJBHome, an IIOP request with operation name create goes over the wire and is handled by the plain IIOPInvoker. - JavaIIOPInvoker allow IIOP acess to a single interface: Invoker, which essentially has a single operation, invoke(). When a client class create() on an EJBHome, an IIOP request with operation name invoke goes over the wire and is handled by the JavaIIOPInvoker. Info on the actual method to be invoked (create(), in this case) goes within the Invocation parameter to invoke(). Unlike IIOPInvoker, which uses an IORFactory, JavaIIOPInvoker works with the standard JBoss ProxyFactory. Whan a client gets a reference to an EJBHome or EJBObject, it really gets a serialized Java proxy, just like in the JRMP case. The only difference is that this proxy's delegate has a CORBA reference (IOR) to the JavaIIOPInvoker, instead of a RMI/JRMP reference to the JRMPInvoker. Everything else works (or should work) as in the JRMP case: interceptors, client container, transactions, etc. JavaIIOPInvoker is useless to non-Java clients (hence its name). I am interested in comparing it with the JRMPInvoker WRT performance. So far (a simple hello test) I got pretty much the same numbers... Of course, the performance may change with the ORB used. I am doing everything with JacORB. Should I commit this stuff? Right now I am not really sure if it will be useful or not. Cheers, Francisco --- 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
[JBoss-dev] [ jboss-Bugs-593047 ] Bad web.xml resource-ref is't notified
Bugs item #593047, was opened at 2002-08-09 09:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593047group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Robert Marcano (robmv) Assigned to: Nobody/Anonymous (nobody) Summary: Bad web.xml resource-ref is't notified Initial Comment: I'm using Jetty as my servlet container I created a resource-ref inside my web.xml like this one: resource-ref description/description res-ref-namejdbc/repsrv/res-ref-name res-typejavax.sql.Datasource/res-type res-authCONTAINER/res-auth /resource-ref please note that Container is in uppercase an is not equals to Container (the web.xml dtd for servlet 2.2 says that the values must be CONTAINER) when I deploy the war file JBoss install it souccesfully but jdbc/repsrvis not bound t the JNDI context. JBoss doen't notify that there is an error in the web.xml file. I debugged the problem and found that in the class org.jboss.web.AbstractWebContainer line 883 there is an empty catch that makes that the exception information became lost. I debugged JBoss release 3.0 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593047group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-593047 ] Bad web.xml resource-ref isn't notified
Bugs item #593047, was opened at 2002-08-09 09:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593047group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Robert Marcano (robmv) Assigned to: Nobody/Anonymous (nobody) Summary: Bad web.xml resource-ref isn't notified Initial Comment: I'm using Jetty as my servlet container I created a resource-ref inside my web.xml like this one: resource-ref description/description res-ref-namejdbc/repsrv/res-ref-name res-typejavax.sql.Datasource/res-type res-authCONTAINER/res-auth /resource-ref please note that Container is in uppercase an is not equals to Container (the web.xml dtd for servlet 2.2 says that the values must be CONTAINER) when I deploy the war file JBoss install it souccesfully but jdbc/repsrvis not bound t the JNDI context. JBoss doen't notify that there is an error in the web.xml file. I debugged the problem and found that in the class org.jboss.web.AbstractWebContainer line 883 there is an empty catch that makes that the exception information became lost. I debugged JBoss release 3.0 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593047group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-593047 ] Bad web.xml res-auth isn't notified
Bugs item #593047, was opened at 2002-08-09 09:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593047group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Robert Marcano (robmv) Assigned to: Nobody/Anonymous (nobody) Summary: Bad web.xml res-auth isn't notified Initial Comment: I'm using Jetty as my servlet container I created a resource-ref inside my web.xml like this one: resource-ref description/description res-ref-namejdbc/repsrv/res-ref-name res-typejavax.sql.Datasource/res-type res-authCONTAINER/res-auth /resource-ref please note that Container is in uppercase an is not equals to Container (the web.xml dtd for servlet 2.2 says that the values must be CONTAINER) when I deploy the war file JBoss install it souccesfully but jdbc/repsrvis not bound t the JNDI context. JBoss doen't notify that there is an error in the web.xml file. I debugged the problem and found that in the class org.jboss.web.AbstractWebContainer line 883 there is an empty catch that makes that the exception information became lost. I debugged JBoss release 3.0 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593047group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-562972 ] Error in PortableRemoteObject.narrow()
Bugs item #562972, was opened at 2002-05-31 09:30
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=562972group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 8
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in PortableRemoteObject.narrow()
Initial Comment:
18:30:30,517 ERROR [STDERR] java.lang.ClassCastException
18:30:30,518 ERROR [STDERR] at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
18:30:30,519 ERROR [STDERR] at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
When running narrow after lookup from a servlet.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-09 08:30
Message:
Logged In: NO
This bug is killing my development efforts, but it doesn't look like JBoss fault, but
rather the VM's. First a few
investigative notes. This ClassCastException happens on both remote and local
interfaces using
PortableRemoteObject and without. PortableRemoteObject has nothing to do with this
bug. If some investigative
code is put in like this in the setSessionContext:
Context ctx = new InitialContext();
Object obj = ctx.lookup(local/BeanAHome);
Class[] c = obj.getClass().getInterfaces();
System.out.println(obj.getClass().getSuperclass().getName());
for (int i=0; ic.length; i++) {
System.out.println(c[i].getName());
}
BeanAHome home = (BeanAHome)obj;
We find the following out. First, as expected, obj is of java.lang.reflect.Proxy
class. Next we check to see what
interfaces it implements. The output show com.mycompany.BeanAHome as an implemented
interface in the
Proxy. However, when a cast is made to this object an exception occurs. This makes
no sense because
reflection shows it implements the desired interface.
I have looked at Sun's bug parade have not found anything like this. I however didn't
look to hard at it. There is a
chance that JBoss could be responsible for this bug, but I don't feel like searching
in the code and my next project
is on Oracle 9iAS. If I get some more time, I will look into this more.
A good test would be to download java 1.3 and see if the bug goes away. My guess is
that is does.
Matt
--
Comment By: Brian Topping (topping)
Date: 2002-07-21 16:23
Message:
Logged In: YES
user_id=99236
See 584663. Couldn't attach a file here.
HTH
--
Comment By: Scott M Stark (starksm)
Date: 2002-07-21 16:13
Message:
Logged In: YES
user_id=175228
Many of our unit tests make use of
PortableRemoteObject.narrow without any problems so post
a testcase that demonstrates this if you want to get this
resoved.
--
Comment By: Brian Topping (topping)
Date: 2002-07-20 01:10
Message:
Logged In: YES
user_id=99236
Okay, this is curious:
I've been setting up JUnit, trying to localize this bug, figuring
it's something to do with my code. Nothing but
ClassCastException, over and over again.
Then I turned *off* the Reload classes every run option on
the JUnit GUI. Suddenly my test passes. I can run the test
multiple times, turn on the switch, down it goes,
ClassCastException. Ad nauseum, no differences from the
script. I can reproduce this 100%.
I'm not familiar with the what this switch does, but it might be
a clue into this bug.
--
Comment By: Brian Topping (topping)
Date: 2002-07-19 19:04
Message:
Logged In: YES
user_id=99236
By the way, I've tested this with only a single copy of the ejb
jar (or anything that would contain the interfaces) in deploy,
the tmp and work directories blown away, and confirmed that
the remote interfaces work properly from a web container
client.
This shouldn't be this hard, FWIW it's definitely got everything
here at a standstill.
--
Comment By: Brian Topping (topping)
Date: 2002-07-19 17:58
Message:
Logged In: YES
user_id=99236
I'm having this problem as well, here is my test code:
Properties params = new Properties();
params.put
(Context.INITIAL_CONTEXT_FACTORY, org.jnp.interfaces.Na
mingContextFactory);
params.put(Context.PROVIDER_URL, localhost);
params.put
(Context.URL_PKG_PREFIXES, org.jboss.naming:org.jnp.int
erfaces );
InitialContext initialContext = new InitialContext(params);
try {
java.lang.Object objRef = initialContext.lookup
(com.bill2.ejb.CustomerHome.JNDI_NAME);
return (com.bill2.ejb.CustomerHome)
PortableRemoteObject.narrow(objRef,
com.bill2.ejb.CustomerHome.class);
} finally {
initialContext.close();
}
[JBoss-dev] [ jboss-Bugs-562972 ] Error in PortableRemoteObject.narrow()
Bugs item #562972, was opened at 2002-05-31 09:30
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=562972group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 8
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in PortableRemoteObject.narrow()
Initial Comment:
18:30:30,517 ERROR [STDERR] java.lang.ClassCastException
18:30:30,518 ERROR [STDERR] at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
18:30:30,519 ERROR [STDERR] at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
When running narrow after lookup from a servlet.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-09 08:33
Message:
Logged In: NO
This bug is killing my development efforts, but it doesn't look like JBoss fault, but
rather the VM's. First a few
investigative notes. This ClassCastException happens on both remote and local
interfaces using
PortableRemoteObject and without. PortableRemoteObject has nothing to do with this
bug. If some investigative
code is put in like this in the setSessionContext:
Context ctx = new InitialContext();
Object obj = ctx.lookup(local/BeanAHome);
Class[] c = obj.getClass().getInterfaces();
System.out.println(obj.getClass().getSuperclass().getName());
for (int i=0; ic.length; i++) {
System.out.println(c[i].getName());
}
BeanAHome home = (BeanAHome)obj;
We find the following out. First, as expected, obj is of java.lang.reflect.Proxy
class. Next we check to see what
interfaces it implements. The output show com.mycompany.BeanAHome as an implemented
interface in the
Proxy. However, when a cast is made to this object an exception occurs. This makes
no sense because
reflection shows it implements the desired interface.
I have looked at Sun's bug parade have not found anything like this. I however didn't
look to hard at it. There is a
chance that JBoss could be responsible for this bug, but I don't feel like searching
in the code and my next project
is on Oracle 9iAS. If I get some more time, I will look into this more.
A good test would be to download java 1.3 and see if the bug goes away. My guess is
that is does.
Matt
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-09 08:30
Message:
Logged In: NO
This bug is killing my development efforts, but it doesn't look like JBoss fault, but
rather the VM's. First a few
investigative notes. This ClassCastException happens on both remote and local
interfaces using
PortableRemoteObject and without. PortableRemoteObject has nothing to do with this
bug. If some investigative
code is put in like this in the setSessionContext:
Context ctx = new InitialContext();
Object obj = ctx.lookup(local/BeanAHome);
Class[] c = obj.getClass().getInterfaces();
System.out.println(obj.getClass().getSuperclass().getName());
for (int i=0; ic.length; i++) {
System.out.println(c[i].getName());
}
BeanAHome home = (BeanAHome)obj;
We find the following out. First, as expected, obj is of java.lang.reflect.Proxy
class. Next we check to see what
interfaces it implements. The output show com.mycompany.BeanAHome as an implemented
interface in the
Proxy. However, when a cast is made to this object an exception occurs. This makes
no sense because
reflection shows it implements the desired interface.
I have looked at Sun's bug parade have not found anything like this. I however didn't
look to hard at it. There is a
chance that JBoss could be responsible for this bug, but I don't feel like searching
in the code and my next project
is on Oracle 9iAS. If I get some more time, I will look into this more.
A good test would be to download java 1.3 and see if the bug goes away. My guess is
that is does.
Matt
--
Comment By: Brian Topping (topping)
Date: 2002-07-21 16:23
Message:
Logged In: YES
user_id=99236
See 584663. Couldn't attach a file here.
HTH
--
Comment By: Scott M Stark (starksm)
Date: 2002-07-21 16:13
Message:
Logged In: YES
user_id=175228
Many of our unit tests make use of
PortableRemoteObject.narrow without any problems so post
a testcase that demonstrates this if you want to get this
resoved.
--
Comment By: Brian Topping (topping)
Date: 2002-07-20 01:10
Message:
Logged In: YES
user_id=99236
Okay, this is curious:
I've been setting up JUnit, trying to localize this bug, figuring
it's something to do with my code. Nothing but
ClassCastException, over and over again.
Then I turned *off* the Reload classes every run option on
the JUnit GUI.
[JBoss-dev] Container.getJmxName()
Hello!
Recently, I had problems with scoped-EARs deployment. I checked the
working test case and found that a bean despite of whether it has
only a local interface must have unique jndi-name besides
local-jndi-name.
The reason is that Container's jmx name is constructed with the
following method:
public ObjectName getJmxName()
{
String jndiName = getBeanMetaData().getJndiName();
if (jndiName == null)
{
throw new IllegalStateException(cannot get Container object name unless jndi
name is set!);
} // end of if ()
if (jmxName == null)
{
jmxName = ObjectNameFactory.create(BASE_EJB_CONTAINER_NAME + ,jndiName= +
jndiName);
} // end of if ()
return jmxName;
}
My beans with local intf didn't suspect this and didn't specify
jndi-name. When container was registered it asked a jndi-name.
BeanMetaData can't refuse with null value and returns ejb-name if
jndi-name is absent. Thus I couldn't get EARs scoped-deployed.
The conclusion is: to get EARs scoped-deployed, beans should have
different ejb-name, or jndi-name.
Or maybe it's better to change jmx name for container?
Say, change jndiName in the getJmxName() as:
BeanMetaData bmd = getBeanMetaData();
jndiName = bmd.getHome() != null ? bmd.getJndiName() : bmd.getLocalJndiName();
or construct jmxName as ObjectNameFactory.create(BASE_EJB_CONTAINER_NAME +
,localJndiName= + localJndiName);
if bean doesn't have remote intf. But in this case conatiners will
have different name structure.
Any comments? TIA.
--
Best regards,
Alex Loubyansky
---
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
Re: [JBoss-dev] Container.getJmxName()
This one:
Say, change jndiName in the getJmxName() as:
BeanMetaData bmd = getBeanMetaData();
jndiName = bmd.getHome() != null ? bmd.getJndiName() : bmd.getLocalJndiName();
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Alex Loubyansky [EMAIL PROTECTED]
To: JBoss-Dev [EMAIL PROTECTED]
Sent: Friday, August 09, 2002 9:05 AM
Subject: [JBoss-dev] Container.getJmxName()
Hello!
Recently, I had problems with scoped-EARs deployment. I checked the
working test case and found that a bean despite of whether it has
only a local interface must have unique jndi-name besides
local-jndi-name.
The reason is that Container's jmx name is constructed with the
following method:
public ObjectName getJmxName()
{
String jndiName = getBeanMetaData().getJndiName();
if (jndiName == null)
{
throw new IllegalStateException(cannot get Container object name unless jndi
name is set!);
} // end of if ()
if (jmxName == null)
{
jmxName = ObjectNameFactory.create(BASE_EJB_CONTAINER_NAME + ,jndiName= +
jndiName);
} // end of if ()
return jmxName;
}
My beans with local intf didn't suspect this and didn't specify
jndi-name. When container was registered it asked a jndi-name.
BeanMetaData can't refuse with null value and returns ejb-name if
jndi-name is absent. Thus I couldn't get EARs scoped-deployed.
The conclusion is: to get EARs scoped-deployed, beans should have
different ejb-name, or jndi-name.
Or maybe it's better to change jmx name for container?
Say, change jndiName in the getJmxName() as:
BeanMetaData bmd = getBeanMetaData();
jndiName = bmd.getHome() != null ? bmd.getJndiName() : bmd.getLocalJndiName();
or construct jmxName as ObjectNameFactory.create(BASE_EJB_CONTAINER_NAME +
,localJndiName= + localJndiName);
if bean doesn't have remote intf. But in this case conatiners will
have different name structure.
Any comments? TIA.
--
Best regards,
Alex Loubyansky
---
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
Re: Re[4]: [JBoss-dev] Container.getJmxName()
There is only one level of commit access, so your 3.0 working directory must be checked out as anonymous or something. If you can commit to head you can commit to any branch. I'm working on a scoping issue so leave the branches to me. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Alex Loubyansky [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Sent: Friday, August 09, 2002 11:12 AM Subject: Re[4]: [JBoss-dev] Container.getJmxName() I committed it to HEAD. Also I removed jndi-name tags from jboss.xml files in cts testcase where entities don't have home interfaces. I couldn't commit to Branch_3_0, because commit requires write access to the repository So, please, someone who has access update it. TIA, alex Friday, August 09, 2002, 7:50:54 PM, you wrote: SMS Yes. SMS SMS Scott Stark SMS Chief Technology Officer SMS JBoss Group, LLC SMS SMS - Original Message - SMS From: Alex Loubyansky [EMAIL PROTECTED] SMS To: Scott M Stark [EMAIL PROTECTED] SMS Sent: Friday, August 09, 2002 9:35 AM SMS Subject: Re[2]: [JBoss-dev] Container.getJmxName() Scott, does it mean I should commit it? :) Friday, August 09, 2002, 7:39:36 PM, you wrote: SMS This one: Say, change jndiName in the getJmxName() as: BeanMetaData bmd = getBeanMetaData(); jndiName = bmd.getHome() != null ? bmd.getJndiName() : bmd.getLocalJndiName(); -- Best regards, Alex Loubyansky --- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[6]: [JBoss-dev] Container.getJmxName()
SMS There is only one level of commit access, so your 3.0 working SMS directory must be checked out as anonymous or something. If SMS you can commit to head you can commit to any branch. But that's not my fiction. It's a quote. Maybe it was eventually. SMS I'm working on a scoping issue so leave the branches to me. Ok, so, no problem. Thanks! -- Best regards, Alex Loubyansky --- 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
[JBoss-dev] BasicMBeanRegistry and class loader MBeans
When one registers an MBean that is a ClassLoader the BasicMBeanRegistry adds it to the the default LoaderRepository. This breaks scoped class loading of services, and it really seems to be out of the scope of functionality that the BasicMBeanRegistry should assume. Really I don't see why the BasicMBeanRegistry should have any interaction with the LoaderRepository as all it is doing is adding and removing class loaders. Scott Stark Chief Technology Officer JBoss Group, LLC --- 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
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 9-August-2002
Number of tests run: 897
Successful tests: 890
Errors:3
Failures: 4
[time of test: 9 August 2002 12:35 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See 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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-593236 ] EJB query fails in 3.0.1RC1, ok in 3.0.0
Bugs item #593236, was opened at 2002-08-09 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593236group_id=22866 Category: JBossServer Group: v3.1 Status: Open Resolution: None Priority: 5 Submitted By: Joe Simone (jsimone) Assigned to: Nobody/Anonymous (nobody) Summary: EJB query fails in 3.0.1RC1, ok in 3.0.0 Initial Comment: The follow EJB query works perfectly with 3.0.0 final but fails with 3.0.1RC1 ... query query-method method-namefindBySession/method- name method-params method- paramjava.lang.String/method-param /method-params /query-method ejb-ql SELECT OBJECT(a) FROM Session AS s, IN (s.course.track.program.event.attendees) AS a, IN (a.attendeeSessions) AS attsess WHERE s.id= ?1 AND attsess.session.id = s.id /ejb-ql /query Here is the error that comes out of 3.0.1RC1 ... [java] getSessionEnrolledAttendees(-807297147- 1865639104)... [java] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [java] java.rmi.ServerException: Find failed: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] [DB2/NT] SQL0206N T6_S_COURSE_TRACK_PROGRAM_EVENT.ID is not valid in the context where it is used. SQLSTATE=42703 [java] ; nested exception is: [java] javax.ejb.EJBException: Find failed: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] [DB2/NT] SQL0206N T6_S_COURSE_TRACK_PROGRAM_EVENT.ID is not valid in the context where it is used. SQLSTATE=42703 [java] java.rmi.ServerException: Find failed: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] [DB2/NT] SQL0206N T 6_S_COURSE_TRACK_PROGRAM_EVENT.ID is not valid in the context where it is used. SQLSTATE=42703 [java] ; nested exception is: [java] javax.ejb.EJBException: Find failed: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] [DB2/NT] SQL0206N T6_S_COURSE_TRACK_PROGRAM_EVENT.ID is not valid in the context where it is used. SQLSTATE=42703 [java] javax.ejb.EJBException: Find failed: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] [DB2/NT] SQL0206N T6_ S_COURSE_TRACK_PROGRAM_EVENT.ID is not valid in the context where it is used. SQLSTATE=42703 [java] at sun.rmi.transport.StreamRemoteCall.exceptionReceived FromServer(StreamRemoteCall.java:240) [java] at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:215) [java] at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:117) [java] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invok e(Unknown Source) [java] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.i nvoke(JRMPInvokerProxy.java:128) [java] at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:108) [java] at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:73) [java] at org.jboss.proxy.SecurityInterceptor.invoke (SecurityInterceptor.java:76) [java] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke (StatelessSessionInterceptor.java:111) [java] at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:76) [java] at $Proxy3.getSessionEnrolledAttendees (Unknown Source) [java] at com.highnotes.ebu.client.test.AttendeeTest.main (AttendeeTest.java:130) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593236group_id=22866 --- 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
[JBoss-dev] [ jboss-Change Notes-593265 ] better deadlock detection
Change Notes item #593265, was opened at 2002-08-09 17:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=593265group_id=22866 Category: None Group: v2.4.8 Status: Open Priority: 5 Submitted By: Bill Burke (patriot1burke) Assigned to: Nobody/Anonymous (nobody) Summary: better deadlock detection Initial Comment: Added a new scenario for deadlock detection. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=593265group_id=22866 --- 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
[JBoss-dev] [ jboss-Change Notes-593268 ] FIFO queue for Connection pooling
Change Notes item #593268, was opened at 2002-08-09 17:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=593268group_id=22866 Category: None Group: v2.4.8 Status: Open Priority: 5 Submitted By: Bill Burke (patriot1burke) Assigned to: Nobody/Anonymous (nobody) Summary: FIFO queue for Connection pooling Initial Comment: David Jencks did this, but not sure if he'll remember to add the change note. Should clean up remaining syncrhonization issues in connection pooling for the 2.4 release. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=593268group_id=22866 --- 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
[JBoss-dev] µçÄÔÅä¼þµÍ¼Û¹©Ó¦
̨ÖÐÊ¢´ï¼¯ÍÅ´ó½°ìÊ´¦ ÎÒ¹«Ë¾³¤ÆÚ¾ÓªÔ×°½ø¿Ú²úÆ·.ÏÖÓеçÄÔÅä¼þ.±Ê¼Ç±¾.±Ê¼Ç±¾Åä¼þ.ÊýÂëÏà»ú.ÉãÏñ»ú.ͶӰÉè ±¸. ͶӰ¸½¼þ.Æû³µ.ÊÖ»ú.¼ÒÓõçÆ÷.²Êµç.¿Õµ÷..ÓÐÒâÔÚ¸÷µØ³ÏÕ÷´úÀíÖ±ÏúÉÌ. Ϊ±£Ö¤ÐÅÓþ ʵÐлõµ½¸¶¿î. Ò²ÐíÄú¶ÔÎÒÃǵļ۸ñÖ®µÍ±íʾ»³ÒÉ,µ«ÄúÊÇ·ñÖªµÀÎÒÃÇ´ÓµçÄÔÊг¡»òÉ̵êÂò»ØÀ´µÄ²úÆ·ÊǾ ¹ý¸÷¼¶´úÀí²ã²ã¼Ó¼ÛµÄ½á¹û.Ó볧¼Ò³ö³§µÄ¼Û¸ñÓÐ×ÅÌìÈÀÖ®±ð.¶øÎÒÃǹ«Ë¾Í¨¹ýÌØÊâµÄ½ø»õÇþµÀ ͨ¹ýÍøÂçÖ±ÏúÄÜ°ÑÖмä´úÀí·ÑÓÃÈ«²¿Ìê³ý,ʵÏÖÕæÕýµÄ¿Í»§Ó빫˾˫Ӯ½á¹û. ¿¼Âǵ½ÍøÂçµÄÐÅÓÃÎÊÌâ,ÎÒÃÇËù³öÊ۵IJúÆ·¾ùʵÐлõµ½¸¶¿îµÄÔÔò.ÕâÖÖ·½Ê½Ëä»áÔö¼ÓÎÒÃÇµÄ ÔËÓª³É±¾,µ«ÎÒÃÇÏ£ÍûÒÔ³ÏÐŵķþÎñ°Ñ×Ô¼º×ö´ó×öÇ¿.ÓëÄúÁªÏµºÏ×÷ÊÂÒê. ( ÇëÎðÖ±½Ó»Ø¸´£¬ÓÐÒâÇëÀ´µçÁªÏµ.ÁªÏµÈË:ºú¿Ë ÁªÏµµç»°: 0138-59709838) µçÄÔÅä¼þ(RMB.Ôª): A:Ö÷°å: ΢ÐÇ 845Pro2-LE(Socket,i845,SDRAM,AC97Éù¿¨) 380Ôª 845Pro (Socket,i845,SDRAM,AC97Éù¿¨) 430Ôª 850Pro5 (Socket,i850,8738Éù¿¨) 520Ôª 645UITRA (Socket478,SiS645оƬ 3DDR AC97) 330Ôª K7T266Pro (SocketA,KT266,3DDR,AC97) 310Ôª K7T266Pro2-LE(SocketA,AC97,ATA100) 270Ôª K7t266Pro2(SocketA,Ö§³ÖXP,3DDR,AC97) 310Ôª 815EPT Pro-NL(Socket370,i815EP,Ö§³ÖÐÂPIII,AC97,ATA100) 270Ôª 815EP Pro-R (Socket370,i850EP,IDE RAID) 280Ôª 815EP-NL (Socket370,i815EP,AC97) 250Ôª 815ET Pro (Socket370,i815E,ÐÂPIII,i752,AC97) 340Ôª 694D Pro2-IR (Socket370,VIA694X/686B,RAID) 320Ôª 6309NL100 (Socket370,VIA694X/686B,AC97) 160Ôª 6309NL/-A (Socket370,VIA694X/686B,AC97,´´ÐÂ5880 190Ôª ÃÀ´ï KT133B (SocketA,KT133/686B,ATA100,AC97) 180Ôª 6VA694XB (Socket370,VIA694x/686B,AC97,ATA100) 135Ôª °º´ï VP266+128M DDR 295Ôª VP266 (Socket370,VIA/APOLLO/PRO266/AC97) 200Ôª VK266 (SocketA,KT133A/686B/AC97/ATA100) 190Ôª VT-133PLUS(SocketA,KT133/686B/AC97/ATA100) 190Ôª ID815E (Socket370,i815E/i752/AC97/ATA100) 195Ôª ID815EP (Socket370,i815EP/AC97/ATA100) 190Ôª ID810 (Socket370,i810/ATA66/i752ÏÔ¿¨/AC97Éù¿¨) 140Ôª VP4-133PLUS(Socket370,VIA694x/686B/AC97/ATA100) 160Ôª Vp4-133/M (Socket370,VIA694/596B/CMI8738Éù¿¨/ATA66) 140Ôª VP-133 (Socket370,VIA693A/596B/CMI8738Éù¿¨/ATA66) 150Ôª SIS730S (SocketA,SiS300/AC97/10/100MÍø¿¨) 155Ôª SIS630E (Socket370,SIS630E/SiS300ÏÔ¿¨/AC97) 175Ôª B:Ó²ÅÌ Maxtor(ÂõÍØ) 40GB£¨ Plus 60/É¢£©7200ת\»º´æ:2MB 180Ôª 40.9GB£¨ VL40/É¢£©5400ת\»º´æ:2MB 160Ôª 160GB£¨ D540X/É¢£©5400ת\»º´æ:2MB 530Ôª 120GB£¨D540X/É¢£©5400ת\»º´æ:2MB 350Ôª 20GB£¨ Plus 60/É¢£© 7200ת\»º´æ:2MB 140Ôª 30GB£¨ Plus 60/É¢£©7200ת\»º´æ:2MB 170Ôª 81.9GB£¨ 80/É¢£©5400ת\»º´æ:2MB 250Ôª 20GB£¨ Plus D740X/É¢£©7200ת\»º´æ:2MB 170Ôª 40GB£¨ Plus D740X/É¢£©7200ת\»º´æ:2MB 180Ôª 20GB£¨ 541DX/É¢£©5400ת\»º´æ:2MB 160Ôª 60GB£¨ D540X/É¢£©5400ת\»º´æ:2MB 200Ôª 20GB£¨ 541DX/ºÐ£©5400ת\»º´æ:2MB 150Ôª 60GB£¨ Plus D740X/É¢£©7200ת\»º´æ:2MB 220Ôª 80GB£¨ Plus D740X/É¢£©7200ת\»º´æ:2MB 300Ôª 40GB£¨ D540X/É¢£©5400ת\»º´æ:2MB 160Ôª 20.4GB£¨ VL40/É¢£©5400ת\»º´æ:2MB 140Ôª 40GB£¨ Plus D740X/ºÐ£©7200ת\»º´æ:2MB 200Ôª 60GB£¨Plus D740X/ºÐ£©7200ת\»º´æ:2MB 230Ôª 80GB£¨ Plus D740X/ºÐ£©7200ת\»º´æ:2MB 350Ôª 40GB£¨ D540X/ºÐ£©5400ת\»º´æ:2MB 185Ôª 80GB£¨ D540X/ºÐ£©5400ת\»º´æ:2MB 280Ôª 20GB£¨ Plus D740X/ºÐ£©7200ת\»º´æ:2MB 160Ôª 40GB£¨ 536DX/ºÐ£©5400ת\»º´æ:2MB 190Ôª 80GB£¨ 536DX/ºÐ£©5400ת\»º´æ:2MB 280Ôª 60GB£¨ Plus 60/ºÐ£©7200ת\»º´æ:2MB 250Ôª 120GB£¨D540X/ºÐ£©5400ת\»º´æ:2MB 400Ôª 81.9GB£¨ 80/ºÐ£©5400ת\»º´æ:2MB 270Ôª 60GB£¨ 536DX/ºÐ£©5400ת\»º´æ:2MB 230Ôª 100GB£¨ 536DX/ºÐ£©5400ת\»º´æ:2MB 800Ôª 60GB£¨ D540X/ºÐ£©5400ת\»º´æ:2MB 270Ôª 160GB£¨ D540X/ºÐ£©5400ת\»º´æ:2MB 900Ôª 30.7GB£¨ VL40/É¢£©5400ת\»º´æ:2MB 210Ôª 61.4GB£¨ 80/É¢£©5400ת\»º´æ:2MB 270Ôª 40GB£¨ 536DX/É¢£©5400ת\»º´æ:2MB 170Ôª 15GB£¨531DX/É¢£©5400ת\»º´æ:2MB 160Ôª 20GB£¨Plus 60/ºÐ£©7200ת\»º´æ:2MB 180Ôª Ï£½Ý 40.8GB£¨U Series 6£©5400ת\»º´æ:2MB 250Ôª 40GB£¨Barracuda ATA IV£©7200ת\»º´æ:2MB 170Ôª 60GB£¨Barracuda ATA IV£©7200ת\»º´æ:2MB 200Ôª 20.4GB£¨U Series 6£©5400ת\»º´æ:512KB 140Ôª 80GB£¨Barracuda ATA IV£©7200ת\»º´æ:2MB 250Ôª 20GB£¨Barracuda ATA IV£©7200ת\»º´æ:2MB 160Ôª 30GB£¨Barracuda ATA III£©7200ת\»º´æ:2MB 170Ôª 20GB£¨U Series 5£©5400ת\»º´æ:512KB 130Ôª 40GB£¨U Series 5£©5400ת\»º´æ:512KB 160Ôª 20GB£¨Barracuda ATA III£©7200ת\»º´æ:2MB 160Ôª 40GB£¨Barracuda ATA III£©7200ת\»º´æ:2MB 170Ôª 10.2GB£¨Barracuda ATA III£©7200ת\»º´æ:2MB 135Ôª 10GB£¨U Series 5£©5400ת\»º´æ:512KB 100Ôª 15.3GB£¨Barracuda ATA III£©7200ת\»º´æ:2MB 165Ôª 30GB£¨U Series 5£©5400ת\»º´æ:512KB 200Ôª 15.3GB£¨U Series 5£©5400ת\»º´æ:512KB 180Ôª ST39236/LW 1ת\»º´æ:2MB\ÈÝÁ¿:9.2GB 350Ôª ST39236/LCV 7200ת\»º´æ:4MB\ÈÝÁ¿:9.2GB 400Ôª IBM 60GB£¨Deskstar 60GXP£©7200ת\»º´æ:2MB 190Ôª 10GB£¨Travelstar 20GN£©4200ת\»º´æ:512KB 140Ôª 40GB£¨Deskstar 60GXP£©7200ת\»º´æ:2MB 170Ôª 40GB£¨Deskstar 120GXP£©7200ת\»º´æ:2MB 170Ôª 80GB£¨Deskstar 120GXP£©7200ת\»º´æ:2MB 230Ôª 30GB£¨Travelstar 20GN£© ±Ê¼Ç±¾Ó²ÅÌ\תËÙ:4200ת\»º´æ:512KB 320Ôª 40GB£¨Travelstar 20GN£© ±Ê¼Ç±¾Ó²ÅÌ\תËÙ:4200ת\»º´æ:512KB 400Ôª 120GB£¨Deskstar 120GXP£© ̨ʽ»úÓ²ÅÌ\תËÙ:7200ת\»º´æ:2MB 430Ôª 18.3GB£¨Ultrastar 36LZX/68£© ·þÎñÆ÷Ó²ÅÌ\תËÙ:1ת\»º´æ:4MB 420Ôª 18.3GB£¨Ultrastar 36LZX/80£© ·þÎñÆ÷Ó²ÅÌ\תËÙ:1ת\»º´æ:4MB 130Ôª 36.9GB£¨Ultrastar 36LZX/80£© ·þÎñÆ÷Ó²ÅÌ\תËÙ:1ת\»º´æ:4MB 680Ôª 36.9GB£¨Ultrastar 36LZX/68£©
RE: [JBoss-dev] Castor XML users; can you drop some knowledge
It just so happens that I was doing some of this work yesterday. I will send an email to you directly with a zip archive (as not to spam the general jboss group) of a generated XSD from your sample, and simple .bat to kick off Castor's src generator, and the resulting classes. James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 5:56 PM To: 'Jboss-Development@Lists. Sourceforge. Net' Subject: [JBoss-dev] Castor XML users; can you drop some knowledge Hiya, I am looking for someone who is familiar with Castor XML to bind XML to Java (and via versa). Basically what I would like is for you to take an example XML document, create the XML schema and either provide the impl classes or provide a runnable example to make use of the class generator. I think this is fairly easy todo, that is if you are familiar with XML schemas and the Castor XML bits. I have looked over both, but have not had time to get something working just yet. There are entirely too many things todo. So it might seem like I am lazy, but really I am just trying to do more with less time. I am hoping to take this example and learn how the system works by it, instead of spending countless hours in trail and error. Are you down? I hope so. Let me know (don't worry I don't bite). Attached is the example XML doc, which is for the JBoss/Console configuration. Thanks, --jason --- 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
[JBoss-dev] Re:
confirm 105513 --- 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
