AW: [JBoss-dev] Cvs head build error

[Jung , Dr. Christoph]

Shame on me and incremental recompilation through Eclipse!

Sorry,
CGJ


-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Scott
M Stark
Gesendet: Freitag, 30. Januar 2004 21:43
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Cvs head build error

I fixed it.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben
Wang
Sent: Friday, January 30, 2004 10:36 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Cvs head build error

Hi,

I just did a fresh check out (from jboss-head). Here is the build error
I got in jboss.net.

Thanks,

-Ben

compile-classes:
[javac] Compiling 12 source files to
E:\cvsroot\jboss-head\jboss.net\output\classes\main
[javac]
E:\cvsroot\jboss-head\jboss.net\src\main\org\jboss\net\ws4ee\metadata\We
bservices.java:81: unreported exception
javax.xml.transform.TransformerException; must be caught or declared to
be thrown
[javac]  new WebserviceDescription((Node)
allDescriptions.get(



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Adding JCE providers at runtime.

[Jason Essington]

On Feb 1, 2004, at 6:58 AM, Scott M Stark wrote:

I have not tried this, but others said they have done it.
Then I certainly must be doing something wrong

Where are you putting the jar
In the jboss-net.sar along with other Web Service Security support 
libraries.

and how is the BouncyCastle provider being installed?
In a static initializer the following code is called:
	java.security.Security.addProvider(new 
org.bouncycastle.jce.provider.BouncyCastleProvider());

This code doesn't throw any exception, so the jar containing the 
provider is found just fine.
but later when an attempt is made to access a cypher (RSA) that is 
supplied by BC using the code:
	cipher = Cipher.getInstance(RSA);
yields an exception saying something about no provicer for that cipher, 
however calling
	cipher = Cipher.getInstance(RSA, BC);
basically forcing the use of the Bouncy castle provider, yields the 
previously mentioned SecurityException.

Should I be adding the provider in a different way, or perhaps from a 
different place?

-jason




Scott Stark
Chief Technology Officer
JBoss Group, LLC

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jason Essington
Sent: Friday, January 30, 2004 3:47 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Adding JCE providers at runtime.
I am trying to add the BouncyCastle Security Provider at runtime. The
call to java.security.Security.addProvider() seems to succeed, but 
later
attempts to use the provider cause a SecurityException with the message
The provider BC may not be signed by a trusted party. This jar works
fine from command line apps, and if it is installed in the jre (jar
added to the lib/ext dir and an entry made into the java.security 
file),
so there is no problem in the signed jar.

Is this maybe a classloader problem where java.security can't find the
cacerts file to verify the jar? What else could be causing the problem?
-jason



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] New ListenerServiceMBeanSupport class

[Dimitris Andreadis]

Hi,

I've checked in a new baseclass org.jboss.system.ListenerServiceMBeanSupport
( ListenerServiceMBean) that helps writing Service MBeans that are
Notification listeners, too:

/**
 * An abstract base class that provides for declarative JMX notification
 * subscription handling.
 * p
 * A JBoss service that is in addition a NotificationListener can
 * subclass ListenerServiceMBeanSupport instead of ServiceMBeanSupport
 * and specify at instantiation-time, inline in the MBean descriptor using
the
 * SubscriptionList attribute, the set of MBeans/notifications the
 * service wants to subscribe/receive.
 * p
 * Just before start() the baseclass will register to those MBeans and for
 * those notifications that match the specified criteria. Similarly,
 * just after stop() the baseclass will automatically unsubscribe.
 * p
 * In addition, while started, it will monitor for registration events
 * from the MBeanServer and automatically subscribe to new instances
 * of MBeans that match the subscription criteria. Monitoring for
 * unsubscribe events in not necessary, since the MBeanServer
 * automatically removes subscriptions to unregistering MBeans.
 * p
 * Moreover, unless the service is properly started (state == STARTED)
 * all incoming notifications will be consumed.
 * p
 * To handle the incoming notifications override the handleNotification2()
 * method. The usual handleNotification() method should not be overriden,
 * since it is used to monitor the incoming notifications for registration
 * events coming from the MBeanServer, before delegating to
 * handleNotification2().
**/

There is also a NotificationListener that demonstrates the usage of the base
class:

(from monitoring-service.xml, uncomment to activate)

!-- Example of listening for notifications from JBoss monitors

  mbean code=org.jboss.monitor.notifications.NotificationListener
 name=jboss.jmx:service=NotificationListener
attribute name=SubscriptionList
  subscription-list
mbean name=jboss.monitor:*
  notification type=JBOSS_MONITOR_NOTIFICATION/
/mbean
  /subscription-list
/attribute
  /mbean
--

(The above example with the proper output formating is more or less
equivalent to the ConsoleAlertListener, but without the dependencies - I'll
come back with suggestions...)

You may specify arbitrary subscription rules, like:

  subscription-list
mbean name=*:service=invoker,* handback=aHandbackString/
mbean name=JMImplementation:type=MBeanServerDelegate
  notification type=JMX.mbean.registered/
  [...]
/mbean
[...]
  /subscription-list

or even:
   mbean name=*:*/

You can easily monitor a single MBean, or the whole MBean server. You just
need to specify what to do with those Notifications.

Hope you find this useful. I've put a DTD at
system/src/resources/org/jboss/metadata/jboss-subscription.dtd

If the check-in locations are innapropriate, please let me know.

Regards
/Dimitris



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] [MailServer Notification] To Recipient a virus was found and acti on taken.

[Scott M Stark]

Ok, the dev list is now going into you must be subscribed to post mode. 



Scott Stark
Chief Technology Officer
JBoss Group, LLC
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
System Attendant
Sent: Tuesday, January 27, 2004 4:23 AM
To: '[EMAIL PROTECTED]'
Subject: [JBoss-dev] [MailServer Notification] To Recipient a virus was
found and acti on taken.

ScanMail for Microsoft Exchange took action on the message.  The message
details were: 
Sender = [EMAIL PROTECTED]
Recipient(s) = [EMAIL PROTECTED];
Subject = [JBoss-dev] hello
Scanning time = 01/27/2004 13:23:07
Engine/Pattern = 6.810-1005/745





---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Compilation Failed! JBoss (HEAD/linux1/1.4.1_06) [AUTOMATED]

[chris]

===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
Tue Jan 27 15:24:45 GMT 2004
===
HERE ARE THE LAST 100 LINES OF THE LOG:
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
init:

_buildmagic:build-bypass-checker:

_buildmagic:build-bypass-notice:

_buildmagic:build-bypass-check:

jars:

_buildmagic:init:

init:

compile-mbean-sources:
[mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/common/output/gen-src
[execmodules] (XDocletMain.start   47  ) Running mbeaninterface/
[execmodules] (TemplateSubTask.engineStarted   789 ) Generating output for 
'org.jboss.util.property.jmx.SystemPropertyClassValue' using template file 
'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet-xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/resources/mbean.xdt'.
[execmodules] INFO:Some classes refer to other classes that were not found among 
the sources or on the classpath.
[execmodules]  (Perhaps the referred class doesn't exist? Hasn't been 
generated yet?)
[execmodules]  The referring classes do not import any fully qualified classes 
matching these classes.
[execmodules]  However, since no packages are imported, xjavadoc has assumed 
that the referred classes
[execmodules]  belong to the same package as the referring class. The classes 
are:
[execmodules] 
/home/jbossci/jbossci2/jboss-head/common/src/main/org/jboss/net/protocol/URLListerBase.java
 -- URLFilter qualified to org.jboss.net.protocol.URLFilter

compile-classes:
[mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/common/output/classes
[javac] Compiling 211 source files to 
/home/jbossci/jbossci2/jboss-head/common/output/classes
[execmodules] 1 warning

compile-etc:
[mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/common/output/etc
 [copy] Copying 1 file to /home/jbossci/jbossci2/jboss-head/common/output/etc

compile:
[mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/common/output/lib
  [jar] Building jar: 
/home/jbossci/jbossci2/jboss-head/common/output/lib/jboss-common.jar
  [jar] Building jar: 
/home/jbossci/jbossci2/jboss-head/common/output/lib/jboss-common-client.jar
  [jar] Building jar: 
/home/jbossci/jbossci2/jboss-head/common/output/lib/testsuite-support.jar
[touch] Creating /home/jbossci/jbossci2/jboss-head/common/output/build-marker

most:

==
==  Finished with 'most' in module 'common'.
==


_module-common-most:
[mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/build/output/testbuild/lib
 [copy] Copying 1 file to 
/home/jbossci/jbossci2/jboss-head/build/output/testbuild/lib
[mkdir] Created dir: 
/home/jbossci/jbossci2/jboss-head/build/output/testbuild/client
 [copy] Copying 1 file to 
/home/jbossci/jbossci2/jboss-head/build/output/testbuild/client
 [copy] Copying 6 files to 
/home/jbossci/jbossci2/jboss-head/build/output/testbuild/lib

==
==  Executing 'most' in module 'jmx'...
==

_buildmagic:init:

configure:
Overriding previous definition of reference to xdoclet.task.classpath

init:

_buildmagic:build-bypass-checker:

_buildmagic:build-bypass-notice:

_buildmagic:build-bypass-check:

output:

_buildmagic:init:

init:

compile-mbean-sources:
[mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/jmx/output/gen-src

_default:compile-classes:
[mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/jmx/output/classes
[mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/jmx/output/gen/classes
   [depend] Deleted 0 out of date files in 0 seconds
[javac] Compiling 615 source files to 
/home/jbossci/jbossci2/jboss-head/jmx/output/classes
/home/jbossci/jbossci2/jboss-head/jmx/src/main/org/jboss/mx/modelmbean/ModelMBeanInvoker.java:111:
 cannot resolve symbol
symbol  : method setDelayedRegistration (boolean)
location: class org.jboss.mx.modelmbean.ModelMBeanInvoker
  setDelayedRegistration(true);
  ^
/home/jbossci/jbossci2/jboss-head/jmx/src/main/org/jboss/mx/modelmbean/XMBean.java:361:
 
configureInterceptorStack(javax.management.modelmbean.ModelMBeanInfo,javax.management.MBeanServer)
 in org.jboss.mx.modelmbean.ModelMBeanInvoker cannot be applied to 

[JBoss-dev] [ jboss-Bugs-889337 ] Read-ahead fails on one-to-one relationship

[SourceForge.net]

Bugs item #889337, was opened at 2004-02-02 22:10
Message generated for change (Comment added) made by rchristy63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889337group_id=22866

Category: JBossCMP
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich C. (rchristy63)
Assigned to: Nobody/Anonymous (nobody)
Summary: Read-ahead fails on one-to-one relationship

Initial Comment:
OS: Linux Redhat 9/Windows XP 
JDK: 1.4.2
JBOSS version: cvs head as of 1/21/03 (3.2.4 R1)

Since JBOSS only allows one table per bean, we simulate
inheritance of entity beans using delegation.So say
Bean A is a base class, Bean B has a getBeanA() method
which delegates all inherited calls through this
one-to-one relationship.   This has worked correctly on
past releases of JBOSS.  However in the version I built
off the cvs head, we noticed the following behavior by
stepping through the cmp code.  If Bean B has a preload
strategy of none, than everything works correctly.  I
can read one or many Bean Bs and everything works. 
However, changing preload strategy to either
on-find/on-load, causes the following exception only if
multiple bean Bs are returned by a finder (the first
one successfully is read and cached, the error occurs
on the second bean always retrieving the getBeanA
relation from the preload cache)

15:30:08,759 ERROR [LogInterceptor]
TransactionRolledbackLocalException in method: public
abstract java.util.Map
com.rcm.securitiesservice.ejbinterfaces.domain.Security.getSecurityProperties(),
causedBy:
javax.ejb.NoSuchObjectLocalException: New value
[2850513] of a foreign key field securityID changed the
value of a primary key field securityID[null]
at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:142)
at
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:89)
at
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:54)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:313)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:147)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at
org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:489)
at
org.jboss.ejb.Container.invoke(Container.java:700)
at
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:375)
at
org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
at $Proxy1441.getSecurityProperties(Unknown Source)
at
com.rcm.securitiesservice.serversupport.SecuritiesValueObjectFactory.fillSecurityValueObject(SecuritiesValueObjectFactory.java:499)


We are just if something has changed to cause this to
no longer work.  Preloading strategy seems to work
correctly for other one-to-one relationships, just not
this particular relationship

Thanks,

Rich


--

Comment By: Rich C. (rchristy63)
Date: 2004-02-02 22:14

Message:
Logged In: YES 
user_id=959867

Just to clarify, this works correctly with JBOSS version
3.2.2RC4 and 3.2.3RC1, but not in 3.2.4RC1 that we built
from the cvs head.

Thanks again,

Rich

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889337group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-884090 ] Using HTML entities in signature does not work

[SourceForge.net]

Bugs item #884090, was opened at 2004-01-25 13:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=884090group_id=22866

Category: Nukes
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Juha Lindfors (juhalindfors)
Assigned to: Julien Viet (cooperfbi)
Summary: Using HTML entities in signature does not work

Initial Comment:
Attempted to use HTML entity à in the signature.
This however solves no problems, as the string à
is not interpreted at all but displayed as is.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=884090group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-885357 ] BMP ejbStore loop

[SourceForge.net]

Bugs item #885357, was opened at 2004-01-27 11:00
Message generated for change (Comment added) made by loubyansky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=885357group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: John Wagg (waggj)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: BMP ejbStore loop

Initial Comment:
I am having a problem porting our application from JBoss 
3.2.1 to 3.2.3. My current problem is an infinite loop 
occuring during an update of a BMP entity bean. The 
outer session bean method has a transaction attribute 
of 'required'. This method uses a BMP home interface to 
do a findByPrimaryKey. It does this again for a second 
BMP entity bean. It then does a get for just one column 
in the first entity. Then it does a different get for the 
second entity bean. All the BMP entity bean methods 
have a 'required' transaction attribute. On calling the 
second get method JBoss has decided that it needs to 
update the first BMP entity bean. i.e. it calls ejbStore on 
the bean. I'm not sure why it should feel the need to do 
this but it does. The problem is that it then gets into a 
loop. The ejbStore method for the bean is doing a 
findByPrimaryKey and a series of sets for one of two 
possible CMP entity beans. All the methods for these 
two CMP beans are 'required' transaction attributes as 
well. It eventually gets a stack overflow but the stack 
trace shows that the update for the CMP bean it has 
chosen forces another ejbStore for the BMP bean and so 
on. 

Here's a section of the stack trace showing one loop 

at 
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeH
ome(BaseLocalProxyFactory.java:293) 
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke
(LocalHomeProxy.java:110) 
at $Proxy214.findByPrimaryKey(Unknown Source) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.update(DFCamatgrpBean.java:555) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.ejbStore(DFCamatgrpBean.java:459) 
at sun.reflect.GeneratedMethodAccessor52.invoke
(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:324) 
at 
org.jboss.ejb.plugins.BMPPersistenceManager.storeEntity
(BMPPersistenceManager.java:454) 
at 
org.jboss.resource.connectionmanager.CachedConnectio
nInterceptor.storeEntity
(CachedConnectionInterceptor.java:387) 
at org.jboss.ejb.EntityContainer.storeEntity
(EntityContainer.java:714) 
at org.jboss.ejb.GlobalTxEntityMap.synchronizeEntities
(GlobalTxEntityMap.java:149) 
at 
org.jboss.ejb.EntityContainer.synchronizeEntitiesWithinTr
ansaction(EntityContainer.java:119) 
at org.jboss.ejb.EntityContainer.findLocal
(EntityContainer.java:607) 
at sun.reflect.GeneratedMethodAccessor48.invoke
(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:324) 
at 
org.jboss.ejb.EntityContainer$ContainerInterceptor.invok
eHome(EntityContainer.java:1043) 
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome
(AbstractInterceptor.java:88) 
at 
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv
okeHome(EntitySynchronizationInterceptor.java:197) 
at 
org.jboss.resource.connectionmanager.CachedConnectio
nInterceptor.invokeHome
(CachedConnectionInterceptor.java:214) 
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome
(AbstractInterceptor.java:88) 
at 
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHo
me(EntityInstanceInterceptor.java:89) 
at 
org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome
(EntityLockInterceptor.java:61) 
at 
org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHo
me(EntityCreationInterceptor.java:28) 
at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:88) 
at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:267) 
at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome
(TxInterceptorCMT.java:98) 
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome
(SecurityInterceptor.java:92) 
at org.jboss.ejb.plugins.LogInterceptor.invokeHome
(LogInterceptor.java:120) 
at 
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok
eHome(ProxyFactoryFinderInterceptor.java:93) 
at org.jboss.ejb.EntityContainer.internalInvokeHome
(EntityContainer.java:483) 
at org.jboss.ejb.Container.invoke(Container.java:720) 
at 
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeH
ome(BaseLocalProxyFactory.java:293) 
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke
(LocalHomeProxy.java:110) 
at $Proxy214.findByPrimaryKey(Unknown Source) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.update(DFCamatgrpBean.java:555) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.ejbStore(DFCamatgrpBean.java:459) 
at sun.reflect.GeneratedMethodAccessor52.invoke

[JBoss-dev] [ jboss-Bugs-889337 ] Read-ahead fails on one-to-one relationship

[SourceForge.net]

Bugs item #889337, was opened at 2004-02-02 22:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889337group_id=22866

Category: JBossCMP
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich C. (rchristy63)
Assigned to: Nobody/Anonymous (nobody)
Summary: Read-ahead fails on one-to-one relationship

Initial Comment:
OS: Linux Redhat 9/Windows XP 
JDK: 1.4.2
JBOSS version: cvs head as of 1/21/03 (3.2.4 R1)

Since JBOSS only allows one table per bean, we simulate
inheritance of entity beans using delegation.So say
Bean A is a base class, Bean B has a getBeanA() method
which delegates all inherited calls through this
one-to-one relationship.   This has worked correctly on
past releases of JBOSS.  However in the version I built
off the cvs head, we noticed the following behavior by
stepping through the cmp code.  If Bean B has a preload
strategy of none, than everything works correctly.  I
can read one or many Bean Bs and everything works. 
However, changing preload strategy to either
on-find/on-load, causes the following exception only if
multiple bean Bs are returned by a finder (the first
one successfully is read and cached, the error occurs
on the second bean always retrieving the getBeanA
relation from the preload cache)

15:30:08,759 ERROR [LogInterceptor]
TransactionRolledbackLocalException in method: public
abstract java.util.Map
com.rcm.securitiesservice.ejbinterfaces.domain.Security.getSecurityProperties(),
causedBy:
javax.ejb.NoSuchObjectLocalException: New value
[2850513] of a foreign key field securityID changed the
value of a primary key field securityID[null]
at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:142)
at
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:89)
at
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:54)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:313)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:147)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at
org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:489)
at
org.jboss.ejb.Container.invoke(Container.java:700)
at
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:375)
at
org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
at $Proxy1441.getSecurityProperties(Unknown Source)
at
com.rcm.securitiesservice.serversupport.SecuritiesValueObjectFactory.fillSecurityValueObject(SecuritiesValueObjectFactory.java:499)


We are just if something has changed to cause this to
no longer work.  Preloading strategy seems to work
correctly for other one-to-one relationships, just not
this particular relationship

Thanks,

Rich


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889337group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-889390 ] CMR's don't outer-join when they should

[SourceForge.net]

Bugs item #889390, was opened at 2004-02-02 15:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889390group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Handwerker (mhandwerker)
Assigned to: Nobody/Anonymous (nobody)
Summary: CMR's don't outer-join when they should

Initial Comment:
When I add the following EJB-QL finder to an entity bean:

SELECT DISTINCT OBJECT(a) FROM Acl a WHERE 
(a.accessorGuid = ?1) and (a.objectTypeAsString = ?3 
and (a.vCObject is null or a.vCObject.guid = ?2))

JDBCEJBQLCompiler generates the following incorrect 
SQL:

SELECT DISTINCT t0_a.acl_pk FROM vc_acl t0_a, 
vc_object t1_a_vCObject WHERE ((t0_a.accessor_guid 
= ?) AND (t0_a.object_type = ? AND (t0_a.obj_fk IS 
NULL OR t1_a_vCObject.obj_pk = ?)) AND 
t0_a.obj_fk=t1_a_vCObject.obj_pk)

Notice that there is a container-managed relationship 
between the AclBean and VCObjectBean on the obj_fk 
database column.

Because the EJB-QL mentions the guid field of 
VCObjectBean (a.vCObject.guid = ?2), 
JDBCEJBQLCompiler generates a join to VCObject accross 
the obj_fk foreign key field (...AND 
t0_a.obj_fk=t1_a_vCObject.obj_pk).  It incorrectly 
generates an inner-join, when an outer-join is required.  
If Acl.obj_fk is null, t0_a.obj_fk IS NULL should allow 
that Acl instance to be found, but it will not be found, 
because the inner-join to VCObject fails.

BEA Weblogic 7.x, 8.1, and IBM WebSphere 4.0.x and 
5.0 all correctly generate an outer join for this query.

I am running JBoss version 3.2.3 against Microsoft 
SQLServer 2000.

Martin Handwerker
Celequest Corporation
Work: (650) 637-2168
Email: mhandwerker AT celequest DOT com


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889390group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-889078 ] WSDL generation broken in =3.2.2

[SourceForge.net]

Bugs item #889078, was opened at 2004-02-02 14:35
Message generated for change (Comment added) made by mlange99
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889078group_id=22866

Category: JBossSOAP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marek Lange (mlange99)
Assigned to: Ceki Gulcu (cgu)
Summary: WSDL generation broken in =3.2.2

Initial Comment:
In JBoss 3.2.3 we have problems with the generated 
WSDL:

simpleType name=ObjectNameType
  simpleContent
extension base=xsd:string/
  /simpleContent
/simpleType

According to the schema definition, this is not correct.  
simpleType must not follow simpleContent (only 
complexType):

Schema error - undefined schema 
component 'simpleContent' encountered - expected: 
(annotation | list | restriction | union) 

The problematic code seems to be in 
org.jboss.net.jmx.adaptor.ObjectNameSerializer:

/**
* Return XML schema for the specified type.
* Our type simply inherits from string.
*/
   public Element writeSchema(Class clazz, Types types) 
throws Exception {
  // ComplexType representation of SimpleType bean 
class
  Element simpleType = types.createElement
(simpleType);
  types.writeSchemaElement(xmlType, simpleType);
  simpleType.setAttribute(name, 
xmlType.getLocalPart());
  Element simpleContent = types.createElement
(simpleContent);
  simpleType.appendChild(simpleContent);
  Element extension = types.createElement
(extension);
  simpleContent.appendChild(extension);
  extension.setAttribute(
 base,
 types.getNamespaces().getCreatePrefix(
XMLType.XSD_STRING.getNamespaceURI())
+ :
+ XMLType.XSD_STRING.getLocalPart());
  return simpleType;
   }

The WSDL from 3.2.1 worked.

Thanks!

-marek

--

Comment By: Marek Lange (mlange99)
Date: 2004-02-02 14:37

Message:
Logged In: YES 
user_id=759286

Problematic WSDL part:

simpleType name=ObjectNameType
  simpleContent
extension base=xsd:string/
  /simpleContent
/simpleType

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889078group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] URL based transaction demarcation and long running transations

[Adrian Brock]

You need to be careful with the http session. It can be used on
multiple threads unlike an ejb stateful session bean.

Regards,
Adrian

On Mon, 2004-01-19 at 16:50, Bill Burke wrote:
 I'd like for somebody to look into being able to define transaction 
 demarcation like we can for EJB at the servlet/jsp/war level.  So, based 
 on a URL pattern you can specify trans-attributes.  Along with this 
 would be stuffing the transaction into the HTTP session so that you can 
 have long transactions that span separate HTTP requests.  I don't think 
 that something like this would be very hard to do.  It is just a matter 
 of providing a Filter and some metadata with jboss-web.xml.  You can 
 probably steal a lot of code from the transaction interceptors within 
 our ejb stack and invokers.
 
 Let me know if anybody is interested and I can give you some more ideas.
 
 Bill
 
 P.S. Ivelin.  I'd like to add this to the roadmap.
-- 
 
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC 
 



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-878879 ] Removing an Entity pointed to by CMR destroys the database

[SourceForge.net]

Bugs item #878879, was opened at 2004-01-17 17:41
Message generated for change (Comment added) made by vprise
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878879group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Shai Almog (vprise)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: Removing an Entity pointed to by CMR destroys the database

Initial Comment:
When we have a 1-1 unidrectional CMR relationship and we 
remove the Entity at the receiving end, JBoss sets the 
relationship to NULL which is an invalid state thus rendering 
the database unusable since findByPrimaryKey on the 
original entity would fail.
So if we have two entities A and B where A has a 
unidirectional relationship to B. When we try to remove B 
we should get a RemoveException (since the database would 
have a constraint issue) instead JBoss updates A to point at 
NULL and removes B which completely works around the 
relational integrity. Since this is a 1-1 relationship when we 
will to a find() operation on A we will get an exception and 
the database is an invalid state.
This is all discussed in this thread:
http://www.jboss.org/
index.html?module=bbop=viewtopict=43055

Which also has a workaround for this problem that DOESN'T 
WORK! This workaround only works for 1-1 relationships but 
it causes 1-many relationships to stop working!

I'm using JBoss 3.2.2 on Linux with PostgreSQL but the 
problem was also verified on 3.0.6

--

Comment By: Shai Almog (vprise)
Date: 2004-02-02 22:17

Message:
Logged In: YES 
user_id=953496

The fact that something doesn't appear in the spec doesn't mean it 
isn't implied. This specific bug makes CMR COMPLETELY USELESS 
for a real DB application!!! Show me a real DB application that can 
be written without this support!!!

JBoss implicitly goes and sets the fields to NULL without any 
request, this was not mentioned anywhere in the spec! If JBoss 
won't go and set the fields to null then an SQLException will be 
thrown followed by a remove exception.

--

Comment By: Alexey Loubyansky (loubyansky)
Date: 2004-02-02 21:52

Message:
Logged In: YES 
user_id=543482

 So if we have two entities A and B where A has a
 unidirectional relationship to B. When we try to remove B
 we should get a RemoveException

Show me this in the spec, please.

We could provide a JBoss-specific configuration option for
this case. But it is definitely not a bug.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878879group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-889312 ] Error looking up bean from war file.

[SourceForge.net]

Bugs item #889312, was opened at 2004-02-02 15:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889312group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Wolfangel (swolfangel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error looking up bean from war file. 

Initial Comment:
I am getting the following exception when I try to lookup 
a bean from a separately deployed ear file. 

15:28:26,359 ERROR [LogInterceptor] EJBException:
javax.ejb.EJBException: Invalid invocation, check your 
deployment packaging, method=public abstract 
com.metamatrix.platform.security.api.LogonAPI 
com.metamatrix
.platform.security.api.LogonAPIHome.create() throws 
javax.ejb.CreateException,java.rmi.RemoteException

I am able to lookup and communicate with the bean from 
an external client but get this exception when looking up 
from a servlet. 

I have searched the newsgroups and found others with 
a similar problem but have not found a solution. 

Is this a bug or a packaging issue?
I can send my ear and war files if need be. They are too 
big to attache.

Regards,

Steve Wolfangel


Starting JBoss (MX MicroKernel)...
Release ID: JBoss [WonderLand] 3.2.3 (build: 
CVSTag=JBoss_3_2_3 date=200311301445)
Home Dir: D:\jb32\server\jboss
Home URL: file:/D:/jb32/server/jboss/
Library URL: file:/D:/jb32/server/jboss/lib/
Patch URL: null
Server Name: metamatrix
Server Home Dir: D:\jb32\server\jboss\server\metamatrix
Server Home URL: 
file:/D:/jb32/server/jboss/server/metamatrix/
Server Data Dir: D:\jb32
\server\jboss\server\metamatrix\data
Server Temp Dir: D:\jb32
\server\jboss\server\metamatrix\tmp
Server Config URL: 
file:/D:/jb32/server/jboss/server/metamatrix/conf/
Server Library URL: 
file:/D:/jb32/server/jboss/server/metamatrix/lib/
Root Deployment Filename: jboss-service.xml
Starting General Purpose Architecture (GPA)...
Java version: 1.4.2,Sun Microsystems Inc.
Java VM: Java HotSpot(TM) Client VM 1.4.2-b28,Sun 
Microsystems Inc.
OS-System: Windows XP 5.1,x86


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889312group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-878879 ] Removing an Entity pointed to by CMR destroys the database

[SourceForge.net]

Bugs item #878879, was opened at 2004-01-17 17:41
Message generated for change (Comment added) made by loubyansky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878879group_id=22866

Category: JBossCMP
Group: v3.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Shai Almog (vprise)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: Removing an Entity pointed to by CMR destroys the database

Initial Comment:
When we have a 1-1 unidrectional CMR relationship and we 
remove the Entity at the receiving end, JBoss sets the 
relationship to NULL which is an invalid state thus rendering 
the database unusable since findByPrimaryKey on the 
original entity would fail.
So if we have two entities A and B where A has a 
unidirectional relationship to B. When we try to remove B 
we should get a RemoveException (since the database would 
have a constraint issue) instead JBoss updates A to point at 
NULL and removes B which completely works around the 
relational integrity. Since this is a 1-1 relationship when we 
will to a find() operation on A we will get an exception and 
the database is an invalid state.
This is all discussed in this thread:
http://www.jboss.org/
index.html?module=bbop=viewtopict=43055

Which also has a workaround for this problem that DOESN'T 
WORK! This workaround only works for 1-1 relationships but 
it causes 1-many relationships to stop working!

I'm using JBoss 3.2.2 on Linux with PostgreSQL but the 
problem was also verified on 3.0.6

--

Comment By: Alexey Loubyansky (loubyansky)
Date: 2004-02-02 21:52

Message:
Logged In: YES 
user_id=543482

 So if we have two entities A and B where A has a
 unidirectional relationship to B. When we try to remove B
 we should get a RemoveException

Show me this in the spec, please.

We could provide a JBoss-specific configuration option for
this case. But it is definitely not a bug.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878879group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-878879 ] Removing an Entity pointed to by CMR destroys the database

[SourceForge.net]

Bugs item #878879, was opened at 2004-01-17 17:41
Message generated for change (Comment added) made by loubyansky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878879group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Shai Almog (vprise)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: Removing an Entity pointed to by CMR destroys the database

Initial Comment:
When we have a 1-1 unidrectional CMR relationship and we 
remove the Entity at the receiving end, JBoss sets the 
relationship to NULL which is an invalid state thus rendering 
the database unusable since findByPrimaryKey on the 
original entity would fail.
So if we have two entities A and B where A has a 
unidirectional relationship to B. When we try to remove B 
we should get a RemoveException (since the database would 
have a constraint issue) instead JBoss updates A to point at 
NULL and removes B which completely works around the 
relational integrity. Since this is a 1-1 relationship when we 
will to a find() operation on A we will get an exception and 
the database is an invalid state.
This is all discussed in this thread:
http://www.jboss.org/
index.html?module=bbop=viewtopict=43055

Which also has a workaround for this problem that DOESN'T 
WORK! This workaround only works for 1-1 relationships but 
it causes 1-many relationships to stop working!

I'm using JBoss 3.2.2 on Linux with PostgreSQL but the 
problem was also verified on 3.0.6

--

Comment By: Alexey Loubyansky (loubyansky)
Date: 2004-02-02 22:58

Message:
Logged In: YES 
user_id=543482

In the current implementation, JBoss literally follows the
spec, i.e. first, the instance is removed from all the
relationships and then it is removed itself.
Note, it is not the JBoss that makes entity beans and CMR
not usuable.

--

Comment By: Shai Almog (vprise)
Date: 2004-02-02 22:17

Message:
Logged In: YES 
user_id=953496

The fact that something doesn't appear in the spec doesn't mean it 
isn't implied. This specific bug makes CMR COMPLETELY USELESS 
for a real DB application!!! Show me a real DB application that can 
be written without this support!!!

JBoss implicitly goes and sets the fields to NULL without any 
request, this was not mentioned anywhere in the spec! If JBoss 
won't go and set the fields to null then an SQLException will be 
thrown followed by a remove exception.

--

Comment By: Alexey Loubyansky (loubyansky)
Date: 2004-02-02 21:52

Message:
Logged In: YES 
user_id=543482

 So if we have two entities A and B where A has a
 unidirectional relationship to B. When we try to remove B
 we should get a RemoveException

Show me this in the spec, please.

We could provide a JBoss-specific configuration option for
this case. But it is definitely not a bug.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878879group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Expansion of service dependencies to redeployment

[Adrian Brock]

Hi Scott,

Our deployments generally boil down to a classpath
and a set of mbeans.

There is also a contract to define a directed graph
across deployments which orders the mbean lifecycle
invocations using depends

There are also implicit rules like:
1) deployments wait for their deployer
2) russian doll
3) deployment sorter

It appears to me, that what is missing is the
ability to define the directed graph for classloading.
Changing a parent deployment in this graph would
require a redeployment of children because the
classloaders need to reconstructed.

To make it work, there needs to be enough information
available to define the graph.

The simplest approach would be to change the meaning
of classpath to define the graph/dependencies. The use
of manifest.mf would also be included.
i.e. each deployment explicity states which jars it
uses.

More implicit rules could be defined:
1) A deployer could define its implementation jars
which all its deployments inherit in case a deployer
is restarted.
2) There was an attempt early in 3.0 to define an
MBeanClassLoader that recorded which classes were
actually used by a deployment. A redeployment of
those classes would force a redeployment of the mbean.
3) The MBeanClassLoader misses classes passed by
reference across the MBus where the signature is an interface,
but this could be added.
4) There are other mechanisms where classes get passed
by reference, e.g. jndi. 
Mechanisms involving serialization
would be caught by the MBeanClassLoader.

Regards,
Adrian

On Sat, 2004-01-31 at 17:31, Scott M Stark wrote:
 So a user has a scenario that could 
 
 M1 -Pa- M4 -Pd-  |
  *
 M2 -Pc- M5 -Pd-  M7
  *
 M3 -Pb- M6 -Pe-  |
 
 Px = protocol x with seperate contract_x.jar for interfaces
 Mn = mbean n that depends on one or more protocols
 
 whenever a protocol contract jar for which mbeans 1..m depend
 on is deployed, mbeans 1..m need to be redeployed. This could
 potentially be addressed by extending the current dependency
 notion to optionally support redeployment, not just stopping
 of the service.
 
 However, in general when contract_x.jar is redeployed, its
 not sufficient to simply redeploy the mbeans using the contract,
 since at least one of them also needs to be upgraded to use the
 modified contract. It seems as though the behavior needed is
 that if the contract_x.jar is redeployed, all mbeans depending
 on the contract are undeployed, and are not redeployed until
 their deployment jar is updated by actually being changed or
 just touched.
 
 So the model seems to require an alternate hot deployment service
 that has the notion of levels and compartments. At a given level
 services are generally independent, but can be made dependent
 by lifecycle contract as can be done now. The level below has
 a deployment level dependency on the level above in that a redeployment
 of a higher level compartment causes an undeploy of the services
 depending on that compartment.
 
 New issues this raises:
 - The directory structure will not correspond to the levels in general
 because a service an mbean can be using multiple protocols, and thus
 depend on multiple compartments in the level above. So there has to
 be a new dependency description mechanism to say service S1 depends on
 compartment level L1a in terms of redeployment. This is going to have
 to be a representation of a directed graph describing the inter-level
 and intra-level dependencies.
 - Updating a contract_x.jar deploys the dependent services and these
 remain updeployed until explicitly redeployed or touched. This can't
 result in exceptions, but could result in services not being redeployed
 if the admin forgets.
 - What happens to the upstream services? So in the above diagram,
 contract_Pd.jar
 is redeployed which affects M4, M5, M7 by type, and M1, M2, and M6 due
 to service
 availability of M7. M4, M5, and M7 must be redeployed, M1, M2, and M6
 simply have
 to wait for M4, M5, and M7 respectively. What support is jboss providing
 vs
 what do you have to code to make this work is the question.
 
 In general this issue raises an issue that has come up a few times due
 to
 the fact that dependency does not have anything to do with redeployment,
 even
 though dependency may require redeployment if type system involved in
 the
 dependency changes. Our service dependency needs to expand to support
 the
 possibility of dependency to the redeployment level.
 
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 JBoss-Development mailing list
 [EMAIL PROTECTED]
 

RE: [JBoss-dev] jmx unit tests

[Adrian Brock]

First the 3.2 build was incorrect.
Second it wasn't testing against the jmxri 1.2

There were three known compliance issues (none are very important they
are on the edge of the spec or relate to UCL semantics versus the
spec's loader repository semantics).

The new failure looks to be caused by this modification:
http://cvs.sourceforge.net/viewcvs.py/jboss/jmx/src/main/org/jboss/mx/notification/MBeanServerListenerRegistration.java?hideattic=0only_with_tag=JBoss_4_0_0_DR2

Jeff, do you remember the issue with the modelmbean invoker?
I don't think it should be possible to use
remove(NofificationListener, NotificationFilter, Object) against
a Broadcaster through the MBeanServer since a Broadcaster does not
support this method, you need an Emitter.

The other failures are related to incompatible changes in the descriptor
implemention of the RI for modelmbeans.
The RI also has more failures in the 1.0 seralization scheme
which is optional and it has never done this correctly anyway.

Regards,
Adrian

On Tue, 2004-01-20 at 22:49, Juha Lindfors wrote:
 There's a difference in running the JMX compliance suite between 3.2.3-RC2
 checkout and the current 3.2.4-RC1 checkout (with JMX 1.2 head backport)
 
 3.2.3-RC2
 =
 
 [EMAIL PROTECTED] /cygdrive/d/jboss-323-RC2/jboss-3.2/jmx
 $ sh build.sh test-compliance-JBossMX
 Searching for build.xml ...
 Buildfile: d:\jboss-323-RC2\jboss-3.2\jmx\build.xml
 
 ...
 
 
  [java] There were 3 failures:
  [java] 1)
 testInstantiateWithDefaultLoaderRepository(test.compliance.server.MBeanServerTEST)junit.framework.Asserti
 onFailedError: FAILS IN JBOSSMX: ULR3 loads from TCL, should be DLR
  [java] at
 test.compliance.server.MBeanServerTEST.testInstantiateWithDefaultLoaderRepository(MBeanServerTEST.jav
 a:1014)
  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
  [java] at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  [java] at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  [java] at
 test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:37)
  [java] 2)
 testGetDescriptor(test.compliance.modelmbean.ModelMBeanInfoSupportTEST)junit.framework.AssertionFailedErr
 or: FAILS IN JBOSSMX: We incorrectly return descriptor type 'constructor'
 here -- should be 'operation'
  [java] at
 test.compliance.modelmbean.ModelMBeanInfoSupportTEST.testGetDescriptor(ModelMBeanInfoSupportTEST.java
 :177)
  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
  [java] at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  [java] at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  [java] at
 test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:37)
  [java] 3)
 testPathological(test.compliance.query.QueryTestCase)junit.framework.AssertionFailedError:
 FAILS IN JBoss
 MX: expected Hello(?:.) to match Hello(?:.)
  [java] at
 test.compliance.query.QueryTestCase.testPathological(QueryTestCase.java:1056)
  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
  [java] at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  [java] at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  [java] at
 test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:37)
 
  [java] FAILURES!!!
  [java] Tests run: 628,  Failures: 3,  Errors: 0
 
 
 BUILD SUCCESSFUL
 Total time: 15 seconds
 
 
 
 
 3.2.4-RC1
 =
 
 /cygdrive/d/jboss-324-RC1/jmx
 $ ./build.bat test-compliance-JBossMX
 Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger
 test-compliance-JBossMX
 Buildfile: build.xml
 
 ...
 
  [java] There were 2 errors:
  [java] 1)
 testInstantiateWithDefaultLoaderRepository(test.compliance.server.MBeanServerTEST)ReflectionException:
 Cl
 ass not found: test.compliance.server.support.AClass
  [java] Cause: java.lang.ClassNotFoundException:
 test.compliance.server.support.AClass
  [java] at
 org.jboss.mx.server.MBeanServerImpl.handleInstantiateExceptions(MBeanServerImpl.java:872)
  [java] at
 org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:853)
  [java] at
 org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:264)
  [java] at
 test.compliance.server.MBeanServerTEST.testInstantiateWithDefaultLoaderRepository(MBeanServerTEST.jav
 a:833)
  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
  [java] at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  [java] at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  [java] at
 test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:48)
  

[JBoss-dev] [ jboss-Feature Requests-889014 ] Enable JBoss TM for DTM

[SourceForge.net]

Feature Requests item #889014, was opened at 2004-02-02 13:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376688aid=889014group_id=22866

Category: JBossTX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Horia Muntean (sevenm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enable JBoss TM for DTM

Initial Comment:
Enable JBoss TM to handle distributed transaction
management. Or, provide easy integration with 3rd party
TMs (JOTM, etc). AFAIK Tyrex is not supported anymore
out of the box, and JOTM was never supported.

Regards,
Horia

P.S. Arjuna is not a solution. It's not free. :)

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376688aid=889014group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-889078 ] WSDL generation broken in =3.2.2

[SourceForge.net]

Bugs item #889078, was opened at 2004-02-02 14:35
Message generated for change (Settings changed) made by mlange99
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889078group_id=22866

Category: JBossSOAP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marek Lange (mlange99)
Assigned to: Dr. Christoph Georg Jung (cgjung)
Summary: WSDL generation broken in =3.2.2

Initial Comment:
In JBoss 3.2.3 we have problems with the generated 
WSDL:

simpleType name=ObjectNameType
  simpleContent
extension base=xsd:string/
  /simpleContent
/simpleType

According to the schema definition, this is not correct.  
simpleType must not follow simpleContent (only 
complexType):

Schema error - undefined schema 
component 'simpleContent' encountered - expected: 
(annotation | list | restriction | union) 

The problematic code seems to be in 
org.jboss.net.jmx.adaptor.ObjectNameSerializer:

/**
* Return XML schema for the specified type.
* Our type simply inherits from string.
*/
   public Element writeSchema(Class clazz, Types types) 
throws Exception {
  // ComplexType representation of SimpleType bean 
class
  Element simpleType = types.createElement
(simpleType);
  types.writeSchemaElement(xmlType, simpleType);
  simpleType.setAttribute(name, 
xmlType.getLocalPart());
  Element simpleContent = types.createElement
(simpleContent);
  simpleType.appendChild(simpleContent);
  Element extension = types.createElement
(extension);
  simpleContent.appendChild(extension);
  extension.setAttribute(
 base,
 types.getNamespaces().getCreatePrefix(
XMLType.XSD_STRING.getNamespaceURI())
+ :
+ XMLType.XSD_STRING.getLocalPart());
  return simpleType;
   }

The WSDL from 3.2.1 worked.

Thanks!

-marek

--

Comment By: Marek Lange (mlange99)
Date: 2004-02-02 14:37

Message:
Logged In: YES 
user_id=759286

Problematic WSDL part:

simpleType name=ObjectNameType
  simpleContent
extension base=xsd:string/
  /simpleContent
/simpleType

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889078group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-889078 ] WSDL generation broken in =3.2.2

[SourceForge.net]

Bugs item #889078, was opened at 2004-02-02 14:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889078group_id=22866

Category: JBossSOAP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marek Lange (mlange99)
Assigned to: Nobody/Anonymous (nobody)
Summary: WSDL generation broken in =3.2.2

Initial Comment:
In JBoss 3.2.3 we have problems with the generated 
WSDL:

simpleType name=ObjectNameType
  simpleContent
extension base=xsd:string/
  /simpleContent
/simpleType

According to the schema definition, this is not correct.  
simpleType must not follow simpleContent (only 
complexType):

Schema error - undefined schema 
component 'simpleContent' encountered - expected: 
(annotation | list | restriction | union) 

The problematic code seems to be in 
org.jboss.net.jmx.adaptor.ObjectNameSerializer:

/**
* Return XML schema for the specified type.
* Our type simply inherits from string.
*/
   public Element writeSchema(Class clazz, Types types) 
throws Exception {
  // ComplexType representation of SimpleType bean 
class
  Element simpleType = types.createElement
(simpleType);
  types.writeSchemaElement(xmlType, simpleType);
  simpleType.setAttribute(name, 
xmlType.getLocalPart());
  Element simpleContent = types.createElement
(simpleContent);
  simpleType.appendChild(simpleContent);
  Element extension = types.createElement
(extension);
  simpleContent.appendChild(extension);
  extension.setAttribute(
 base,
 types.getNamespaces().getCreatePrefix(
XMLType.XSD_STRING.getNamespaceURI())
+ :
+ XMLType.XSD_STRING.getLocalPart());
  return simpleType;
   }

The WSDL from 3.2.1 worked.

Thanks!

-marek

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889078group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-889117 ] apply button does not work properly in the debug dialog

[SourceForge.net]

Bugs item #889117, was opened at 2004-02-02 15:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889117group_id=22866

Category: JBoss-IDE
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas  Wuest (andreaswuest)
Assigned to: Nobody/Anonymous (nobody)
Summary: apply button does not work properly in the debug dialog

Initial Comment:
hi,

when i add a log file in the Log Files tag in the
debug dialog of 
my jboss configuration i expect the apply button to be
activated after adding
the log file. however it is not enabled. after changing
the current tab
it is possible to use the apply button because the
button the gets enabled. it would be nice if you could
change to behaviour so that the apply button gets
enabled after you
added a log file.

i am using eclipse 2.1.2 und jboss ide 1.2.2, windows
2000, jdk 1.4.1_01.

thanks, 
Andreas


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889117group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] AOP and microcontainer

[Bill Burke]

Renamed and reposted to jboss-dev

Marc Fleury wrote:


On a separate note.  I have been thinking for the past week about this
stuff and microcontainer stuff in general.  I think it is basically a
clean up of EJB stuff.  Been thinking about entities and a way to
cleanly wrap up hibernate stuff.  Finders are important. I have a hard
time finding any justification for session beans except remote,
cluster/failover, transactions.  These are already in AOP so I may just
rebuild them but frankly they become a bit useless in memory.  Also Bill
we may need to revisit the proxy stuff, you may have been right.  If the
main point is failover, it requires a proxy and then we are back to your
original designs.  Bottom line we may need proxy/instance AOP for the
different use cases.
We do need to play with and implement some applications with the AOP 
approach.

Some other thoughts:

1) I should eventually merge AOP metadata with XMBean metadata based on 
Alex's new stuff.

2) Need to figure out the integration with AOP and XMBean.  AOP in the 
AspectJ sense is always based on the Class level where MBeans are more 
towards a per instance type of thing.  XMBean defined interceptors 
should support pointcut expressions that the AOP framework has and the 
two should migrate into the same look and feel.

3) I do have the concept of an Abstract Container within the AOP 
framework, but I have not made it public yet.  The idea was to be able 
to specify pointcuts on an Abstract Container in the same way you could 
define pointcuts on a class.  An Abstract Container could support a 
specific Class or a set of interfaces.  Container's are always needed as 
they allow references to objects to live beyond the lifetime of the 
actual object.  Also thought of the Abstract Container as a way to group 
attachment of interceptors rather than the all or nothing approach 
AspectJ has on a class.

4) The Microkernel needs to be more IoC enabled.  I touched on some of 
these points in the RoadMap, but I'll repost here:

==

1.	The ability to define POJOs as MBeans with no requirements other than 
a public constructor.  Even looser than the *Mbean template for 
StandardMbeans.  This facilitates having MBeans taken from existing 
static object models.  I know we have XMBeans to facilitate a lot of 
this funtionality, but we need to NOT require metadata and have defaults 
defined.
2.	Need to define semantics for dependencies for non-Service mbeans.  If 
a depends tag or depends optional-attribute mbean has not been 
started/created/loaded, what do we do?  Suggestions include, dont even 
register/allocate object until dependencies are resolved (both 
create/start for service mbeans).
3.	Move Service state out of ServiceMBeanSupport so that we do not have 
to inherit from org.jboss.system.ServiceMBeanSupport to manage current 
state of MBean.  This is so that we can just have MBeans that only have 
to implement orb.jboss.system.Service to get lifecycle events.  This is 
useful because some Objects may want to have their own inheritance 
structure.
4.	Document how to create a Service AOP Introduction so that 
non-changeable classes that we want to create as components can have 
lifecycle.
5.	Add Service controller attribute to MBean definition.  This will 
allocate a separate defined class that will handle lifecycle events on 
the MBean.  This allows you to define Service lifecycle as a 
cross-cutting concern without using AOP.
6.	For depends optional-attribute add a proxy-type for AOP ClassProxies.
7.	For depends optional-attribute have a well defined default for 
proxy-type: i.e. The MBean interface of the MBean.  If no Standard MBean 
interface, then all interfaces, or even optionally create a AOP ClassProxy.
8.	For depends optional-attribute have an instance instead of 
proxy-type.  MBeanServer will place the actual reference to the real 
object instead of a proxy.  On an MBean cycling, replace all references 
with the old object with the real object.
9. Let Constructors accept depends optiona-attribute arguments. 
Either ObjectName, ArrayList of ObjectNames (for lists), or an actual 
proxy or list of proxies

Bill


-Original Message-
From: Andrew Oliver [mailto:[EMAIL PROTECTED] 
Sent: Sunday, February 01, 2004 6:01 PM
To: The Core
Subject: EJB Spec

So RMH has posted asking for What do you hate about EJB  -- 
We should respond.  We should spell it out and basically 
spell out JBoss AOP + Hibernate without saying so then note 
as a matter of fact at the end we'll do this regardless 
while assuring compatibility with your legacy spec

Lets decide:

What do you hate about EJB?

ME:

Needless contract methods.  I especially hate the various 
lifecycle methods that are NEVER used but are there to 
satisfy interfaces...  Even worse the ones that are 
Container-EJB interfaces.

ME: 

CMR must be local interfaces.  Since most appservers make the 
locality unimportant, why do I HAVE to use local interfaces 
if I don't feel 

[JBoss-dev] [ jboss-Bugs-889263 ] IllegalStateException in getEJBObject()

[SourceForge.net]

Bugs item #889263, was opened at 2004-02-02 21:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889263group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Kral (lkral)
Assigned to: Nobody/Anonymous (nobody)
Summary: IllegalStateException in getEJBObject()

Initial Comment:
When I call sessionContext.getEJBObject() on session 
beans JBoss complains about a missing remote interface 
even if there is a remote interface defined. It seems 
that the StatefulSessionEnterpriseContext / 
StatelessSessionEnterpriseContext is missing a 
ProxyFactory while accessing the session bean instance 
through its local interface.

Since the affected beans worked great in 3.0.x I assume 
that this bug was introduced within the 3.2 branch. In 
addition, the bugreport #577711 was raised for the same 
issue on entity beans.

Here the relevant StackTrace:


20:34:44,062 ERROR [LogInterceptor] 
TransactionRolledbackLocalException in method: public 
abstract javax.ejb.EJBObject 
de.libra.ejb.StandardSessionEJBLocal.getEJBRemoteObjec
t(), causedBy:
java.lang.IllegalStateException: No remote interface 
defined.
at 
org.jboss.ejb.StatefulSessionEnterpriseContext$StatefulS
essionContextImpl.getEJBObject
(StatefulSessionEnterpriseContext.java:131)
at 
de.libra.ejb.StandardSessionEJBImpl.getEJBRemoteObject
(StandardSessionEJBImpl.java:111)
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.ejb.StatefulSessionContainer$ContainerIntercep
tor.invoke(StatefulSessionContainer.java:948)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:118)
at 
org.jboss.resource.connectionmanager.CachedConnection
Interceptor.invoke
(CachedConnectionInterceptor.java:185)
at 
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.i
nvoke(StatefulSessionInstanceInterceptor.java:269)
at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:84)
at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:267)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:128)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:191)
at 
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok
e(ProxyFactoryFinderInterceptor.java:122)
at 
org.jboss.ejb.StatefulSessionContainer.internalInvoke
(StatefulSessionContainer.java:416)
at org.jboss.ejb.Container.invoke
(Container.java:700)
at 
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke
(BaseLocalProxyFactory.java:375)
at 
org.jboss.ejb.plugins.local.StatefulSessionProxy.invoke
(StatefulSessionProxy.java:41)
at $Proxy535.getEJBRemoteObject(Unknown 
Source)
at 
de.libra.ejb.PaiSessionControllerEJBImpl$SessionBeanEntry
.getRemoteSessionBean
(PaiSessionControllerEJBImpl.java:974)
at 
de.libra.ejb.PaiSessionControllerEJBImpl$SessionInfoImpl.g
etRemoteSessionBean
(PaiSessionControllerEJBImpl.java:1416)
at 
de.libra.ejb.PaiSessionControllerEJBImpl.getRemoteSession
Bean(PaiSessionControllerEJBImpl.java:868)
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.ejb.StatefulSessionContainer$ContainerIntercep
tor.invoke(StatefulSessionContainer.java:948)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:118)
at 
org.jboss.resource.connectionmanager.CachedConnection
Interceptor.invoke
(CachedConnectionInterceptor.java:185)
at 
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.i
nvoke(StatefulSessionInstanceInterceptor.java:269)
at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:84)
at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:267)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:128)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:191)
at 
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok
e(ProxyFactoryFinderInterceptor.java:122)
at 
org.jboss.ejb.StatefulSessionContainer.internalInvoke
(StatefulSessionContainer.java:416)
at org.jboss.ejb.Container.invoke
(Container.java:700)
at 

[JBoss-dev] [ jboss-Feature Requests-889011 ] Provide logging to TM

[SourceForge.net]

Feature Requests item #889011, was opened at 2004-02-02 13:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376688aid=889011group_id=22866

Category: JBossTX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Horia Muntean (sevenm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Provide logging to TM

Initial Comment:
Provide logging capabilities to JBoss TM in order to be
able to recover tx (automatic or manual) after a crash.

Regards,
Horia

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376688aid=889011group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] xmbean persistence broken ?

[Scott M Stark]

Yes, and its fixed in 3.2. I'm still in the process of merging the
fixes back to head. 



Scott Stark
Chief Technology Officer
JBoss Group, LLC
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rupp, Heiko
Sent: Monday, January 26, 2004 12:18 AM
To: Jboss-Devel-List (E-Mail)
Subject: [JBoss-dev] xmbean persistence broken ?

Hi,

I recall a thread xmbean peristence broken or such.

Is there a solution on this?
 
  Heiko

-- 
Heiko W. Rupp   EMail: [EMAIL PROTECTED]
Senior Consultant   Telefon: +49 711 222 992 - 900
Cellent AG Finance SolutionsTelefax: +49 711 222 992 - 999
Calwer Str. 33  D-70173 Stuttgart



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-885357 ] BMP ejbStore loop

[SourceForge.net]

Bugs item #885357, was opened at 2004-01-27 11:00
Message generated for change (Comment added) made by loubyansky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=885357group_id=22866

Category: JBossCMP
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: John Wagg (waggj)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: BMP ejbStore loop

Initial Comment:
I am having a problem porting our application from JBoss 
3.2.1 to 3.2.3. My current problem is an infinite loop 
occuring during an update of a BMP entity bean. The 
outer session bean method has a transaction attribute 
of 'required'. This method uses a BMP home interface to 
do a findByPrimaryKey. It does this again for a second 
BMP entity bean. It then does a get for just one column 
in the first entity. Then it does a different get for the 
second entity bean. All the BMP entity bean methods 
have a 'required' transaction attribute. On calling the 
second get method JBoss has decided that it needs to 
update the first BMP entity bean. i.e. it calls ejbStore on 
the bean. I'm not sure why it should feel the need to do 
this but it does. The problem is that it then gets into a 
loop. The ejbStore method for the bean is doing a 
findByPrimaryKey and a series of sets for one of two 
possible CMP entity beans. All the methods for these 
two CMP beans are 'required' transaction attributes as 
well. It eventually gets a stack overflow but the stack 
trace shows that the update for the CMP bean it has 
chosen forces another ejbStore for the BMP bean and so 
on. 

Here's a section of the stack trace showing one loop 

at 
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeH
ome(BaseLocalProxyFactory.java:293) 
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke
(LocalHomeProxy.java:110) 
at $Proxy214.findByPrimaryKey(Unknown Source) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.update(DFCamatgrpBean.java:555) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.ejbStore(DFCamatgrpBean.java:459) 
at sun.reflect.GeneratedMethodAccessor52.invoke
(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:324) 
at 
org.jboss.ejb.plugins.BMPPersistenceManager.storeEntity
(BMPPersistenceManager.java:454) 
at 
org.jboss.resource.connectionmanager.CachedConnectio
nInterceptor.storeEntity
(CachedConnectionInterceptor.java:387) 
at org.jboss.ejb.EntityContainer.storeEntity
(EntityContainer.java:714) 
at org.jboss.ejb.GlobalTxEntityMap.synchronizeEntities
(GlobalTxEntityMap.java:149) 
at 
org.jboss.ejb.EntityContainer.synchronizeEntitiesWithinTr
ansaction(EntityContainer.java:119) 
at org.jboss.ejb.EntityContainer.findLocal
(EntityContainer.java:607) 
at sun.reflect.GeneratedMethodAccessor48.invoke
(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:324) 
at 
org.jboss.ejb.EntityContainer$ContainerInterceptor.invok
eHome(EntityContainer.java:1043) 
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome
(AbstractInterceptor.java:88) 
at 
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv
okeHome(EntitySynchronizationInterceptor.java:197) 
at 
org.jboss.resource.connectionmanager.CachedConnectio
nInterceptor.invokeHome
(CachedConnectionInterceptor.java:214) 
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome
(AbstractInterceptor.java:88) 
at 
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHo
me(EntityInstanceInterceptor.java:89) 
at 
org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome
(EntityLockInterceptor.java:61) 
at 
org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHo
me(EntityCreationInterceptor.java:28) 
at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:88) 
at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:267) 
at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome
(TxInterceptorCMT.java:98) 
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome
(SecurityInterceptor.java:92) 
at org.jboss.ejb.plugins.LogInterceptor.invokeHome
(LogInterceptor.java:120) 
at 
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok
eHome(ProxyFactoryFinderInterceptor.java:93) 
at org.jboss.ejb.EntityContainer.internalInvokeHome
(EntityContainer.java:483) 
at org.jboss.ejb.Container.invoke(Container.java:720) 
at 
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeH
ome(BaseLocalProxyFactory.java:293) 
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke
(LocalHomeProxy.java:110) 
at $Proxy214.findByPrimaryKey(Unknown Source) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.update(DFCamatgrpBean.java:555) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.ejbStore(DFCamatgrpBean.java:459) 
at sun.reflect.GeneratedMethodAccessor52.invoke

[JBoss-dev] [ jboss-Bugs-885357 ] BMP ejbStore loop

[SourceForge.net]

Bugs item #885357, was opened at 2004-01-27 09:00
Message generated for change (Comment added) made by waggj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=885357group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: John Wagg (waggj)
Assigned to: Nobody/Anonymous (nobody)
Summary: BMP ejbStore loop

Initial Comment:
I am having a problem porting our application from JBoss 
3.2.1 to 3.2.3. My current problem is an infinite loop 
occuring during an update of a BMP entity bean. The 
outer session bean method has a transaction attribute 
of 'required'. This method uses a BMP home interface to 
do a findByPrimaryKey. It does this again for a second 
BMP entity bean. It then does a get for just one column 
in the first entity. Then it does a different get for the 
second entity bean. All the BMP entity bean methods 
have a 'required' transaction attribute. On calling the 
second get method JBoss has decided that it needs to 
update the first BMP entity bean. i.e. it calls ejbStore on 
the bean. I'm not sure why it should feel the need to do 
this but it does. The problem is that it then gets into a 
loop. The ejbStore method for the bean is doing a 
findByPrimaryKey and a series of sets for one of two 
possible CMP entity beans. All the methods for these 
two CMP beans are 'required' transaction attributes as 
well. It eventually gets a stack overflow but the stack 
trace shows that the update for the CMP bean it has 
chosen forces another ejbStore for the BMP bean and so 
on. 

Here's a section of the stack trace showing one loop 

at 
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeH
ome(BaseLocalProxyFactory.java:293) 
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke
(LocalHomeProxy.java:110) 
at $Proxy214.findByPrimaryKey(Unknown Source) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.update(DFCamatgrpBean.java:555) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.ejbStore(DFCamatgrpBean.java:459) 
at sun.reflect.GeneratedMethodAccessor52.invoke
(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:324) 
at 
org.jboss.ejb.plugins.BMPPersistenceManager.storeEntity
(BMPPersistenceManager.java:454) 
at 
org.jboss.resource.connectionmanager.CachedConnectio
nInterceptor.storeEntity
(CachedConnectionInterceptor.java:387) 
at org.jboss.ejb.EntityContainer.storeEntity
(EntityContainer.java:714) 
at org.jboss.ejb.GlobalTxEntityMap.synchronizeEntities
(GlobalTxEntityMap.java:149) 
at 
org.jboss.ejb.EntityContainer.synchronizeEntitiesWithinTr
ansaction(EntityContainer.java:119) 
at org.jboss.ejb.EntityContainer.findLocal
(EntityContainer.java:607) 
at sun.reflect.GeneratedMethodAccessor48.invoke
(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:324) 
at 
org.jboss.ejb.EntityContainer$ContainerInterceptor.invok
eHome(EntityContainer.java:1043) 
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome
(AbstractInterceptor.java:88) 
at 
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv
okeHome(EntitySynchronizationInterceptor.java:197) 
at 
org.jboss.resource.connectionmanager.CachedConnectio
nInterceptor.invokeHome
(CachedConnectionInterceptor.java:214) 
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome
(AbstractInterceptor.java:88) 
at 
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHo
me(EntityInstanceInterceptor.java:89) 
at 
org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome
(EntityLockInterceptor.java:61) 
at 
org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHo
me(EntityCreationInterceptor.java:28) 
at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:88) 
at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:267) 
at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome
(TxInterceptorCMT.java:98) 
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome
(SecurityInterceptor.java:92) 
at org.jboss.ejb.plugins.LogInterceptor.invokeHome
(LogInterceptor.java:120) 
at 
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok
eHome(ProxyFactoryFinderInterceptor.java:93) 
at org.jboss.ejb.EntityContainer.internalInvokeHome
(EntityContainer.java:483) 
at org.jboss.ejb.Container.invoke(Container.java:720) 
at 
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeH
ome(BaseLocalProxyFactory.java:293) 
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke
(LocalHomeProxy.java:110) 
at $Proxy214.findByPrimaryKey(Unknown Source) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.update(DFCamatgrpBean.java:555) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.ejbStore(DFCamatgrpBean.java:459) 
at sun.reflect.GeneratedMethodAccessor52.invoke
(Unknown Source) 

RE: [JBoss-dev] xmbean persistence attributes in xmbean-dd

[Scott M Stark]

It can't be done with the existing 1.0 and 1.1 dtds, it can be done for
the 1.2 xsd. 



Scott Stark
Chief Technology Officer
JBoss Group, LLC
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rupp, Heiko
Sent: Monday, January 26, 2004 12:19 AM
To: Jboss-Devel-List (E-Mail)
Subject: [JBoss-dev] xmbean persistence attributes in xmbean-dd

Hi,

I have the impression that the attributes [EMAIL PROTECTED]
and [EMAIL PROTECTED] should be move to the persistence-manager
element of the xmbean descriptor, as they are specific per pm.

Does it make sense to address this now (*) or is the xmbean-dd rewritten
anyway? So this would be the first feature request :-)

  Heiko

(*) I am not sure, if I have time to do it.
-- 
Heiko W. Rupp   EMail: [EMAIL PROTECTED]
Senior Consultant   Telefon: +49 711 222 992 - 900
Cellent AG Finance SolutionsTelefax: +49 711 222 992 - 999
Calwer Str. 33  D-70173 Stuttgart



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-798840 ] org/jboss/mx/loading/LoadMgr.java deadlock

[SourceForge.net]

Bugs item #798840, was opened at 2003-09-01 23:20
Message generated for change (Comment added) made by ingrilli
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=798840group_id=22866

Category: JBossMX
Group: v3.2
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: sal ingrilli (ingrilli)
Assigned to: Scott M Stark (starksm)
Summary: org/jboss/mx/loading/LoadMgr.java deadlock 

Initial Comment:
JBOSS: Release ID: JBoss [WonderLand] 3.2.1 (build: 
CVSTag=JBoss_3_2_1 date=200305041533)
OS: Microsoft Windows XP [Version 5.1.2600]
CPU: Intel pentium 4 3Ghz, with hyperthreading
JVM: java version 1.3.1_02, 1.3.1_02-b02
Stack traces: attached
Related issues: 662098 

I have 2 threads, each issuing a Class.forName () 
through the following util:

public static Class forName (final String className)
  throws ClassNotFoundException {

final Thread currentThread = Thread.currentThread ();
final ClassLoader classLoader = 
currentThread.getContextClassLoader ();
  final Class newClass = classLoader.loadClass 
(className);
  return newClass;
}

I get a deadlock in the JBoss LoadMgr quite regularly 
during startup.

--

Comment By: sal ingrilli (ingrilli)
Date: 2004-01-24 01:07

Message:
Logged In: YES 
user_id=396317

JBOSS: Release ID: JBoss [WonderLand] 3.2.1 (build: 
CVSTag=JBoss_3_2_1 date=200305041533)
OS: Microsoft Windows XP [Version 5.1.2600]
CPU: Intel pentium 4 3Ghz
JVM: java version 1.3.1_02, 1.3.1_02-b02
Stack traces: attached
Related issues: 662098 

Scott:

I was finally able to recreate this with UCL tracing ON as you 
had requested.

Let me know what else I can do to help resolve this.

Sal.

--

Comment By: Scott M Stark (starksm)
Date: 2003-10-13 07:26

Message:
Logged In: YES 
user_id=175228

Reopen when you have a log that shows the deadlock.

--

Comment By: Scott M Stark (starksm)
Date: 2003-09-10 16:25

Message:
Logged In: YES 
user_id=175228

This will not fit as an attachment. Send to me directly at
[EMAIL PROTECTED]

--

Comment By: sal ingrilli (ingrilli)
Date: 2003-09-10 16:14

Message:
Logged In: YES 
user_id=396317

Attached is a zipped 18Mb ucl.log

--

Comment By: Scott M Stark (starksm)
Date: 2003-09-04 10:48

Message:
Logged In: YES 
user_id=175228

The log file only has 3 lines in it. See this link
https://sourceforge.net/docman/display_doc.php?docid=14918group_id=22866
for how to configure the trace level logging. It requires
putting the following into the conf/log4j.xml file:

appender name=UCL class=org.apache.log4j.FileAppender
  param name=File
value=${jboss.server.home.dir}/log/ucl.log/
  param name=Append value=false/
  layout class=org.apache.log4j.PatternLayout
 param name=ConversionPattern
value=[%r,%c{1},%t] %m%n/
  /layout
   /appender
   category name=org.jboss.mx.loading additivity=false
  priority value=TRACE class=org.jboss.logging.XLevel/
  appender-ref ref=UCL/
   /category


--

Comment By: sal ingrilli (ingrilli)
Date: 2003-09-03 19:48

Message:
Logged In: YES 
user_id=396317

i attached ucl.log on 9/2 but didn't see an email notification 
for it. so this is just to generate the notification.

--

Comment By: Scott M Stark (starksm)
Date: 2003-09-02 03:15

Message:
Logged In: YES 
user_id=175228

I'm going to need the trace level log as described in the
docs section on class loading debugging.

--

Comment By: sal ingrilli (ingrilli)
Date: 2003-09-02 01:29

Message:
Logged In: YES 
user_id=396317

i attached LoadMgr.nextTask.deadlock.txt in the original post.
it contains the traces of 2 threads stuck in LoadMgr.nextTask 
()
if you need something different, just shoot  i'll get it to you.

--

Comment By: Scott M Stark (starksm)
Date: 2003-09-02 00:36

Message:
Logged In: YES 
user_id=175228

Attach a thread dump of the deadlock.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=798840group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]

[JBoss-dev] [ jboss-Patches-885815 ] Entity-Command for DB2 Primary Key Generation

[SourceForge.net]

Patches item #885815, was opened at 2004-01-27 13:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376687aid=885815group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Wintschel (humandoing)
Assigned to: Nobody/Anonymous (nobody)
Summary: Entity-Command for DB2 Primary Key Generation

Initial Comment:
I wrote a subclass of 
JDBCIdentityColumnCreateCommand that takes 
advantage of the built in DB2 function 
IDENTITY_VAL_LOCAL(). This function returns the last 
generated ID for a DB Identity column (read: PK column) 
within a given transaction. This is only useful for tables 
in IBM DB2 that are created using the identity column 
statement (which is quite common for apps that want 
the DB to generate primary keys).

I have tested this somewhat extensively on DB2 8.1 and 
JBoss 3.2.2 on Windows 2000 Pro.

The class doesn't currently do any checking for what 
Java data type the primary key is, I can easily add that. 
I just wanted to submit the patch to see if there was 
interest in having it included. 

The file is attached.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376687aid=885815group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-878527 ] Logout does not work consistently

[SourceForge.net]

Bugs item #878527, was opened at 2004-01-16 22:04
Message generated for change (Comment added) made by cooperfbi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878527group_id=22866

Category: Nukes
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Juha Lindfors (juhalindfors)
Assigned to: Julien Viet (cooperfbi)
Summary: Logout does not work consistently

Initial Comment:
Logout from Nukes website does not work consistently.
User is reported as logged out but his session will
continue to be active. 

Nukes with current jboss.org website, Mozilla 1.5 Win32


--

Comment By: Julien Viet (cooperfbi)
Date: 2004-01-28 13:48

Message:
Logged In: YES 
user_id=337141

I hope it's good this time. The problem I solved was the
fact that Nukes could send at the same time cookies for
invalidating the credentials and cookie for login (sent by
blocks mainly when they do a security checks).

I moved the login procedure from the security check to the
process() method of the CoreModule. If the user come in and
has not identity, we look at the cookies and if he has them
we try to load the user.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878527group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-878879 ] Removing an Entity pointed to by CMR destroys the database

[SourceForge.net]

Bugs item #878879, was opened at 2004-01-17 17:41
Message generated for change (Settings changed) made by loubyansky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878879group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Shai Almog (vprise)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: Removing an Entity pointed to by CMR destroys the database

Initial Comment:
When we have a 1-1 unidrectional CMR relationship and we 
remove the Entity at the receiving end, JBoss sets the 
relationship to NULL which is an invalid state thus rendering 
the database unusable since findByPrimaryKey on the 
original entity would fail.
So if we have two entities A and B where A has a 
unidirectional relationship to B. When we try to remove B 
we should get a RemoveException (since the database would 
have a constraint issue) instead JBoss updates A to point at 
NULL and removes B which completely works around the 
relational integrity. Since this is a 1-1 relationship when we 
will to a find() operation on A we will get an exception and 
the database is an invalid state.
This is all discussed in this thread:
http://www.jboss.org/
index.html?module=bbop=viewtopict=43055

Which also has a workaround for this problem that DOESN'T 
WORK! This workaround only works for 1-1 relationships but 
it causes 1-many relationships to stop working!

I'm using JBoss 3.2.2 on Linux with PostgreSQL but the 
problem was also verified on 3.0.6

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=878879group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-884420 ] Search result sorting does not appear to be working

[SourceForge.net]

Bugs item #884420, was opened at 2004-01-26 00:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=884420group_id=22866

Category: Nukes
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Juha Lindfors (juhalindfors)
Assigned to: Julien Viet (cooperfbi)
Summary: Search result sorting does not appear to be working

Initial Comment:
The search screen allows sorting of the results by post
time to either ascending or descending order. Changing
this does not appear to have any effect on the results:
oldest post is always displayed first.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=884420group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-885053 ] UIL2 thead leak during broken connection attempt

[SourceForge.net]

Bugs item #885053, was opened at 2004-01-26 13:07
Message generated for change (Comment added) made by starksm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=885053group_id=22866

Category: JBossMQ
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Sebastian Hauer (hauer)
Assigned to: Scott M Stark (starksm)
Summary: UIL2 thead leak during broken connection attempt

Initial Comment:
We noticed a thread leak in one of our production
environment running JBoss 3.0.8 with the UIL2 JMS layer.

I did a quick test on my machine where I am running
JBoss 3.2.2RC3 and the UIL2 JMS service is listening on
port 443.  I tried connecting via a web browser to this
port which triggered as expected a:

java.io.StreamCorruptedException: Caught EOFException
while reading the stream header
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:840)
at
java.io.ObjectInputStream.init(ObjectInputStream.java:163)
at
org.jboss.mq.il.uil2.SocketManager$ReadTask.run(SocketManager.java:265)
at java.lang.Thread.run(Thread.java:479)


I looked at the JBoss code and saw that once you open a
connection to the JMS server 2 threads get launched a
socked read thread UIL2.SocketManager.ReadTask# and
socket write thread UIL2.SocketManager.WriteTask# .
When the the mentioned exception happened the read
thread stops nicely yet the write thread keeped on running.

I verified this taking thread dumps on my local jboss
instance:

After the first broken JMS invocation I had:
8 read threads 
9 write threads

After the second broken JMS invocation I had:
8 read threads 
10 write threads


After the third broken JMS invocation I had:
8 read threads 
11 write threads





--

Comment By: Scott M Stark (starksm)
Date: 2004-01-28 09:50

Message:
Logged In: YES 
user_id=175228

Neither the inital creation of an object stream to read a
message or write a message were cleaning up both threads.
Both have been fixed by calling  replacing the
log.error(...) call with a handleStop(...) call, a two line
change.

Fixed in 3.0 and higher branches.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=885053group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-886544 ] serialized ObjectName canonical value not equal

[SourceForge.net]

Bugs item #886544, was opened at 2004-01-28 16:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=886544group_id=22866

Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Haynie (jhaynie)
Assigned to: Nobody/Anonymous (nobody)
Summary: serialized ObjectName canonical value not equal

Initial Comment:
If you serialize an ObjectName and de-serialize it, the 
canonical name (and toString()) are not equal - although 
the object equality is true.

Example to program illustrate problem:

public class foo
{
public static void main (String args[])
{
try
{
ObjectName obj=new ObjectName
(vocalos:type=Service,foo=bar,bar=foo);
System.out.println(obj);

ByteArrayOutputStream bos=new 
ByteArrayOutputStream();
ObjectOutputStream oos=new 
ObjectOutputStream(bos);
oos.writeObject(obj);

ByteArrayInputStream bis=new 
ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois=new ObjectInputStream
(bis);
ObjectName obj2 = (ObjectName)ois.readObject
();

// obj1 != obj2 (from a string value sense)
System.out.println(obj2);

System.out.println(obj.equals(obj2));

}
catch (Exception ex)
{
ex.printStackTrace();
}

}
}


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=886544group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-886798 ] NPE after redeployment of an ear

[SourceForge.net]

Bugs item #886798, was opened at 2004-01-29 09:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=886798group_id=22866

Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Radim Hanus (rhanus)
Assigned to: Nobody/Anonymous (nobody)
Summary: NPE after redeployment of an ear

Initial Comment:
I'm using JBoss 3.2.3 on WinXP and this problem appears
regularly after redeployment. The only solution is to
restart the server :(

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=886798group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file

[SourceForge.net]

Bugs item #870942, was opened at 2004-01-05 06:54
Message generated for change (Comment added) made by starksm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=870942group_id=22866

Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Steve Wolfangel (swolfangel)
Assigned to: Scott M Stark (starksm)
Summary: Classloader problem with ear file

Initial Comment:
Hello,

I have an ear file that contains 2 stateless session 
beans and all the 3rd party jars required by the beans. 
The 3rd party jars contain older jdom classes than the 
jdom jar included in the jboss lib dir. I have a unique 
classloader setup (in the jboss-app.xml file) but I am 
having problems with jdom. It is finding the jboss jdom 
classes instead of the ones included in the ear. 

when I change the jboss-app.xml file to contain the 
following lines:

jboss-app
loader-repository
com.metamatrix:loader=MM.ear
loader-repository-
configjava2ParentDelegation=false/loader-repository-
config 
/loader-repository
/jboss-app

I get a NoClassDefFoundError. 

 java.lang.NoClassDefFoundError: java/sql/SQLException

This class is in the rt.jar file in the jdk!

I was under the impression that setting 
java2ParentDelegation to false meant that if the class 
was not found using the local classloader then the 
parent classloader would be called. 

In a nutshell, when I have java2ParentDelegation set to 
true, I get the jdom problem, when I have 
java2ParentDelegation set to false I am unable to see 
classes that are in the rt.jar file. 


Here is the output when starting the server.

[Server] Starting JBoss (MX MicroKernel)...
[Server] Release ID: JBoss [WonderLand] 3.2.3 (build: 
CVSTag=JBoss_3_2_3 date=200311301445)
[Server] Home Dir: D:\mm40\jb32\server\jboss
[Server] Home URL: file:/D:/mm40/jb32/server/jboss/
[Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/
[Server] Patch URL: null
[Server] Server Name: metamatrix
[Server] Server Home Dir: D:\mm40\jb32
\server\jboss\server\metamatrix
[Server] Server Home URL: 
file:/D:/mm40/jb32/server/jboss/server/metamatrix/
[Server] Server Data Dir: D:\mm40\jb32
\server\jboss\server\metamatrix\data
[Server] Server Temp Dir: D:\mm40\jb32
\server\jboss\server\metamatrix\tmp
[Server] Server Config URL: 
file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/
[Server] Server Library URL: 
file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/
[Server] Root Deployment Filename: jboss-service.xml
[Server] Starting General Purpose Architecture (GPA)...
[ServerInfo] Java version: 1.4.2,Sun Microsystems Inc.
[ServerInfo] Java VM: Java HotSpot(TM) Client VM 
1.4.2-b28,Sun Microsystems Inc.
[ServerInfo] OS-System: Windows XP 5.1,x86

--

Comment By: Scott M Stark (starksm)
Date: 2004-01-28 08:44

Message:
Logged In: YES 
user_id=175228

This has been fixed by excluding the scoped class loaders
that are not using parent first delegation from locating
resources outside of thier classpath. The fix is in for the
3.2.4RC1 release.

--

Comment By: Scott M Stark (starksm)
Date: 2004-01-23 13:58

Message:
Logged In: YES 
user_id=175228

No you should not be able to override java.* system classes
other than through vm specific means. Its a security issue
and the final ClassLoader.defineClass will not let you do
it. The xerces classes are not in the java.* package namespace.

--

Comment By: Martin Handwerker (mhandwerker)
Date: 2004-01-23 13:19

Message:
Logged In: YES 
user_id=952324

The jboss classloader should not be special-casing java.*, or 
any other package names (Scott-- my interpretation of your 
last comment is that you think it should).

Metamatrix probably shouldn't be redistributing java.sql 
classes with their ear, but if they do, those classes SHOULD 
override the system java.sql classes when referenced from 
the EAR.

Scott mentioned that there is a test-case for replacing the 
XML parser with a different version of Xerces.  We are doing 
just that with our EAR, and are finding that jboss is trying to 
use our Xerces classes when parsing our descriptors, even 
though we have java2ParentDelegation set to false in a jboss-
app.xml file.

--

Comment By: Scott M Stark (starksm)
Date: 2004-01-23 12:37

Message:
Logged In: YES 
user_id=175228

This is due to the use of scoped class loading that wants to
load classes from ear before the parent class loader, and
the inclusion of java.sql package classes in the ear:

+- metamatrix-server.jar (archive)
...
|  +- java/sql/Package.html
|  +- java/sql/ParameterMetaData.class
|  +- java/sql/Savepoint.class

classes in the java.* should not be able to override the
system classes, but 

[JBoss-dev] [ jboss-Bugs-877172 ] NullPointerException in LoadMgr3

[SourceForge.net]

Bugs item #877172, was opened at 2004-01-14 13:59
Message generated for change (Comment added) made by jcalabrese
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=877172group_id=22866

Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim McCune (javajedi)
Assigned to: Scott M Stark (starksm)
Summary: NullPointerException in LoadMgr3

Initial Comment:
I get this error out of JBoss 3.2.2 on a fairly regular
basis.  I'm still not sure exactly how to reproduce it,
but since it's an NPE, I'm hoping that someone can
track down what would cause it to happen fairly easily.
 Once it occurs for a particular class, the only fix is
to restart JBoss.  I never had this problem on 3.2.0.

java.lang.NullPointerException at
org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119)
at
org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:169)
at
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:123)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:235) 
   at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)

Looking at the code, the UnifiedLoaderRepository3 that
is passed into beginLoadTask as the 2nd parameter must
be null.  UnifiedClassLoader3, line 118 does a null
check for repository just a few lines before calling
loadClassImpl, so I'm assuming that this is a valid
state for the class loader to be in.  That would mean
that beginLoadTask in LoadMgr3 needs to handle the
situation where repository is null.

--

Comment By: Jason Calabrese (jcalabrese)
Date: 2004-01-30 09:47

Message:
Logged In: YES 
user_id=300014

I'm having the same problem with 3.2.3. 
 
Everything works fine and then I redeploy the war and get 
the NPE.   
 
Here's my stack trace: 
 
09:42:22,108 ERROR [STDERR] java.lang.NullPointerException 
09:42:22,109 ERROR [STDERR] at 
org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119) 
09:42:22,110 ERROR [STDERR] at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:169) 
09:42:22,112 ERROR [STDERR] at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:123) 
09:42:22,113 ERROR [STDERR] at 
java.lang.ClassLoader.loadClass(ClassLoader.java:235) 
09:42:22,114 ERROR [STDERR] at 
javax.crypto.SunJCE_b.c(DashoA6275) 
09:42:22,115 ERROR [STDERR] at 
javax.crypto.SunJCE_b.a(DashoA6275) 
09:42:22,116 ERROR [STDERR] at 
javax.crypto.Cipher.a(DashoA6275) 
09:42:22,117 ERROR [STDERR] at 
javax.crypto.Cipher.getInstance(DashoA6275) 
09:42:22,118 ERROR [STDERR] at 
com.contentscan.openpgp.OpenPGPUtil.getCipher(OpenPGPUtil.java:169) 
09:42:22,119 ERROR [STDERR] at 
com.contentscan.domeLogic.DomeSessionMgr.decrypt(DomeSessionMgr.java:612) 
09:42:22,120 ERROR [STDERR] at 
com.contentscan.domeLogic.DomeSessionMgr.decryptSessionKey(DomeSessionMgr.java:629) 
09:42:22,121 ERROR [STDERR] at 
com.contentscan.domeLogic.DomeSessionMgr.validateSession(DomeSessionMgr.java:280) 
09:42:22,123 ERROR [STDERR] at 
com.contentscan.webdome.WebEnvironment.establishSession(WebEnvironment.java:229) 
09:42:22,123 ERROR [STDERR] at 
com.contentscan.webdome.WebEnvironment.init(WebEnvironment.java:143) 
09:42:22,125 ERROR [STDERR] at 
com.contentscan.webdome.WebEnvironment.init(WebEnvironment.java:48) 
09:42:22,126 ERROR [STDERR] at 
org.apache.jsp.welcome_jsp._jspService(welcome_jsp.java:89) 
09:42:22,127 ERROR [STDERR] at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137) 
09:42:22,128 ERROR [STDERR] at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 
09:42:22,129 ERROR [STDERR] at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:210) 
09:42:22,130 ERROR [STDERR] at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) 
09:42:22,138 ERROR [STDERR] at 
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) 
09:42:22,139 ERROR [STDERR] at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 
09:42:22,140 ERROR [STDERR] at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
 
09:42:22,141 ERROR [STDERR] at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
 
09:42:22,142 ERROR [STDERR] at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) 
09:42:22,143 ERROR [STDERR] at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
 
09:42:22,144 ERROR [STDERR] at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
09:42:22,145 ERROR [STDERR] at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) 
09:42:22,147 ERROR 

RE: [JBoss-dev] jmx unit tests

[Scott M Stark]

The 3.2 branch is down to the same failures as head. The issue with the
two class loader failures is due to the fact that we don't like anything
but UCLs in the ULR and the MLet is transferred into an equivalent UCL
on
addition, but we lose the mapping between the UCL and MLet and when the
MLet is removed we can't find the associated UCL in the ULR. This should
be easy to fix by adding a non-UCL to UCL map to the ULR.

 [java] 3)
testMLetLoadClassFromURLInConstructor(test.compliance.loading.MLetTEST)
junit.framework.AssertionFailedError: class
test.compliance.loading.support.Trivial was still found in CL
repository.
 [java] at
test.compliance.loading.MLetTEST.testMLetLoadClassFromURLInConstructor(M
LetTEST.java:102)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 [java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
 [java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
 [java] at
test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:48)

 [java] 4) testBasicMLetFileLoad(test.compliance.loading.MLetTEST)
junit.framework.AssertionFailedError: class
test.compliance.loading.support.Trivial was already found in CL
repository.
 [java] at
test.compliance.loading.MLetTEST.testBasicMLetFileLoad(MLetTEST.java:122
)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 [java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
 [java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
 [java] at
test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:48) 



Scott Stark
Chief Technology Officer
JBoss Group, LLC
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Juha
Lindfors
Sent: Tuesday, January 20, 2004 2:28 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] jmx unit tests


JBOSS-HEAD:

/cygdrive/d/jboss-head/jmx
$ sh build.sh test-compliance-JBossMX
Searching for build.xml ...
Buildfile: d:\jboss-head\jmx\build.xml

...

[java] 1) testNotificationEmitterRemoveTripletFailsOnBroadcaster
(test.compliance.server.MBeanServerInvocationHandlerTestCase)
junit.framework.AssertionFailedError: removeNotificationListener
(NotificationListener, NotificationFilter, Object)should not work for a
broadcaster

* This is JMX1.2 API, so Adrian will know the details


[java] 2)
testGetDescriptor(test.compliance.modelmbean.ModelMBeanInfoSupportTEST)
junit.framework.AssertionFailedError: FAILS IN JBOSSMX:
We incorrectly return descriptor type 'constructor' here -- should be
'operation'

* Incorrect metadata value for a model mbean constructor, I vaguely
remember 1.2 spec has a different semantic specified here compared to
1.0


[java] 4) testPathological(test.compliance.query.QueryTestCase)
junit.framework.AssertionFailedError: FAILS IN JBossMX: expected
Hello(?:.) to match Hello(?:.)

* IIRC, spec ambiguity, Adrian might remember more on this.


I don't think any of the above needs fixing to port changes to jmx
layer.
The two errors on classloading and one error on classloading in
implementation suite however might be worth looking at.

-- Juha




---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-886544 ] serialized ObjectName canonical value not equal

[SourceForge.net]

Bugs item #886544, was opened at 2004-01-28 13:42
Message generated for change (Comment added) made by starksm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=886544group_id=22866

Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Jeff Haynie (jhaynie)
Assigned to: Scott M Stark (starksm)
Summary: serialized ObjectName canonical value not equal

Initial Comment:
If you serialize an ObjectName and de-serialize it, the 
canonical name (and toString()) are not equal - although 
the object equality is true.

Example to program illustrate problem:

public class foo
{
public static void main (String args[])
{
try
{
ObjectName obj=new ObjectName
(vocalos:type=Service,foo=bar,bar=foo);
System.out.println(obj);

ByteArrayOutputStream bos=new 
ByteArrayOutputStream();
ObjectOutputStream oos=new 
ObjectOutputStream(bos);
oos.writeObject(obj);

ByteArrayInputStream bis=new 
ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois=new ObjectInputStream
(bis);
ObjectName obj2 = (ObjectName)ois.readObject
();

// obj1 != obj2 (from a string value sense)
System.out.println(obj2);

System.out.println(obj.equals(obj2));

}
catch (Exception ex)
{
ex.printStackTrace();
}

}
}


--

Comment By: Scott M Stark (starksm)
Date: 2004-01-28 15:26

Message:
Logged In: YES 
user_id=175228

There are N! ways to write the toString() representation of
an ObjectName with N properties and only one ordered
representation, that given by ObjectName.getCanonicalName().
getCanonicalName() is used in the implementation of equals
which is why the given example works from the
obj.equals(obj2) perspective.
obj.toString().equals(obj2.toString()) has no guarentee of
equality while
obj.getCanonicalName().equals(obj2.getCanonicalName()) does.

Further, the jmx 1.2 javadocs for toString state:
pReturns a string representation of the object name.  The
format of this string is not specified, but users can expect
that two ObjectNames return the same string if and only if they
are equal.
/p

This does not imply that two ObjectNames which are equal
must return the same toString value.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=886544group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-886544 ] serialized ObjectName canonical value not equal

[SourceForge.net]

Bugs item #886544, was opened at 2004-01-28 16:42
Message generated for change (Comment added) made by jhaynie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=886544group_id=22866

Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Jeff Haynie (jhaynie)
Assigned to: Scott M Stark (starksm)
Summary: serialized ObjectName canonical value not equal

Initial Comment:
If you serialize an ObjectName and de-serialize it, the 
canonical name (and toString()) are not equal - although 
the object equality is true.

Example to program illustrate problem:

public class foo
{
public static void main (String args[])
{
try
{
ObjectName obj=new ObjectName
(vocalos:type=Service,foo=bar,bar=foo);
System.out.println(obj);

ByteArrayOutputStream bos=new 
ByteArrayOutputStream();
ObjectOutputStream oos=new 
ObjectOutputStream(bos);
oos.writeObject(obj);

ByteArrayInputStream bis=new 
ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois=new ObjectInputStream
(bis);
ObjectName obj2 = (ObjectName)ois.readObject
();

// obj1 != obj2 (from a string value sense)
System.out.println(obj2);

System.out.println(obj.equals(obj2));

}
catch (Exception ex)
{
ex.printStackTrace();
}

}
}


--

Comment By: Jeff Haynie (jhaynie)
Date: 2004-01-28 21:15

Message:
Logged In: YES 
user_id=4529

From a practical standpoint.

If you do a toString() on an object you expect that after
serialization toString() returns the same value, as should
hashCode() and equals().

There is no harm in fixing this such that this is the case
since the fix will service both purposes - it will return
the same value and continue to work as-is from a canonical
representation.

--

Comment By: Scott M Stark (starksm)
Date: 2004-01-28 18:26

Message:
Logged In: YES 
user_id=175228

There are N! ways to write the toString() representation of
an ObjectName with N properties and only one ordered
representation, that given by ObjectName.getCanonicalName().
getCanonicalName() is used in the implementation of equals
which is why the given example works from the
obj.equals(obj2) perspective.
obj.toString().equals(obj2.toString()) has no guarentee of
equality while
obj.getCanonicalName().equals(obj2.getCanonicalName()) does.

Further, the jmx 1.2 javadocs for toString state:
pReturns a string representation of the object name.  The
format of this string is not specified, but users can expect
that two ObjectNames return the same string if and only if they
are equal.
/p

This does not imply that two ObjectNames which are equal
must return the same toString value.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=886544group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-886791 ] on-find with commit option C don't work

[SourceForge.net]

Bugs item #886791, was opened at 2004-01-29 09:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=886791group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rafal Kedziorski (rafciom)
Assigned to: Nobody/Anonymous (nobody)
Summary: on-find with commit option C don't work

Initial Comment:
hi,

some weeks ago (I thinh it was JBoss 3.2.2) I posted
this bug to the jboss users. on-find is not working
in JBoss 3.2.2 (JBoss 3.2.3 I couldn't check, cause we
have other problems with this version) and with JBoss
3.2.4RC1 from CVS (last update 28.01.04).

This is my entity bean:

package net.magix.ejb.setting.entitybeans;

import javax.ejb.CreateException;
import javax.ejb.EntityBean;

import net.magix.ejb.entitybeans.AbstractEntityBean;

/**
 * Description of the Class
 *
 * @authorRafal Kedziorski
 * @version   $Id: Setting_2_UserBean.java,v 1.16
2004/01/29 07:28:36 rafal Exp $
 * @ejb.bean
 *   name = Setting_2_UserBean
 *   description = Setting_2_User Entity Bean
 *   display-name = Setting_2_User Entity Bean
 *   local-jndi-name = setting/Setting_2_UserBean
 *   view-type = local
 *   type = CMP
 *   cmp-version = 2.x
 *   schema = setting_2_user
 *   primkey-field = setting_2_user_id
 *
 * @ejb.finder
 *   view-type = local
 *   signature = java.util.Collection
findAllByUserId(java.lang.Long user_id)
 *   query = SELECT OBJECT(o) FROM setting_2_user
o WHERE o.user_id = ?1
 *   result-type-mapping = Local
 *
 * @ejb.finder
 *   view-type = local
 *   signature =
net.magix.ejb.setting.entitybeans.Setting_2_UserBeanLocalHome
findBySettingIdAndUserId(java.lang.Integer setting_id,
java.lang.Long user_id)
 *   query = SELECT OBJECT(o) FROM setting_2_user
o WHERE o.setting_id = ?1 AND o.user_id = ?2
 *   result-type-mapping = Local
 *
 * @ejb.security-identity
 *   use-caller-identity = true
 *
 * @ejb.transaction
 *   type = Mandatory
 *
 * @jboss.persistence
 *   row-locking = true
 *   list-cache-max = 2000
 *
 * @ejb.persistence
 *   table-name = setting_2_user
 *
 * @jboss.container-configuration
 *   name = Standard CMP 2.x EntityBean with
Commit Option C
 *
 * @jboss.read-ahead
 *   strategy = on-find
 *   page-size = 4
 *   eager-load-group = *
 *
 * @jboss.entity-command
 *   name = mysql-get-generated-keys
 *
 */
public abstract class Setting_2_UserBean extends
AbstractEntityBean implements EntityBean {
/**
 * Gets the setting_2_user_id attribute of the
Setting_2_UserBean object
 *
 * @return   The setting_2_user_id value
 * @ejb.pk-field
 *
 * @ejb.persistence
 *   column-name = setting_2_user_id
 *   sql-type = setting_2_user_id
 *
 * @jboss.persistence
 *   auto-increment = true
 *
 * @jboss.method-attributes
 *   read-only = true
 *
 * @ejb.interface-method
 *   view-type = local
 *
 */
public abstract Long getSetting_2_user_id();


/**
 * Sets the setting_2_user_id attribute of the
Setting_2_UserBean object
 *
 * @param setting_2_user_id  The new setting_id value
 */
public abstract void setSetting_2_user_id(Long
setting_2_user_id);


/**
 * Gets the setting_id attribute of the
Setting_2_UserBean object
 *
 * @return   The setting_id value
 * @ejb.persistence
 *   column-name = setting_id
 *   sql-type = setting_id
 *
 * @jboss.method-attributes
 *   read-only = true
 *
 * @ejb.interface-method
 *   view-type = local
 *
 */
public abstract Integer getSetting_id();


/**
 * Sets the setting_id attribute of the
Setting_2_UserBean object
 *
 * @param setting_id  The new setting_id value
 */
public abstract void setSetting_id(Integer setting_id);


/**
 * Gets the user_id attribute of the UserEntityBean
object
 *
 * @return   The user_id value
 * @ejb.persistence
 *   column-name = user_id
 *   sql-type = user_id
 *
 * @jboss.method-attributes
 *   read-only = true
 *
 * @ejb.interface-method
 *   view-type = local
 *
 */
public abstract Long getUser_id();


/**
 * Sets the user_id attribute of the UserEntityBean
object
 *
 * @param user_id  The new user_id value
 */
public abstract void setUser_id(Long user_id);


/**
 * Gets the value attribute of the
Setting_2_UserBean object
 *
 * @return   The value
 * @ejb.persistence
 *   column-name = value
 *   sql-type = value
 *
 * @jboss.method-attributes
 *   read-only = true
 *
 * @ejb.interface-method
 *   view-type = local
 *
 */
public abstract String getValue();

[JBoss-dev] [ jboss-Bugs-887491 ] Problem with non-English characters in UTF-8 encoded queries

[SourceForge.net]

Bugs item #887491, was opened at 2004-01-30 10:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=887491group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Milen Dyankov (azzazzel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with non-English characters in UTF-8 encoded queries

Initial Comment:
It seems that all characters coded with more than one
byte (2+ bytes) in UTF-8 encoded queries are
incorrectly parsed by [EJB/JBoss]QLParser as seen in
this log fragment:

...
2004-01-20 09:21:44,507 DEBUG
[plugins.cmp.jdbc.JDBCDynamicQLQuery.Company#ejbSelectGeneric]
DYNAMIC-QL: SELECT OBJECT(c) FROM Company c WHERE
((c.name LIKE '%#261;#281;#380;#378;#263;#347;#322;ó#324;%'))
2004-01-20 09:21:44,510 DEBUG
[plugins.cmp.jdbc.JDBCDynamicQLQuery.Company#ejbSelectGeneric]
 SQL: SELECT t0_c.symbol_ FROM COMPANY_ t0_c WHERE
(((t0_c.name_ LIKE '%|z[BóD%')))
2004-01-20 09:21:44,510 DEBUG
[plugins.cmp.jdbc.JDBCDynamicQLQuery.Company#ejbSelectGeneric]
Executing SQL: SELECT t0_c.symbol_ FROM COMPANY_ t0_c
WHERE (((t0_c.name_ LIKE '%|z[BóD%'))) 
...

I don't know much for JJTree but I feel these two
parameters:
UNICODE_INPUT = false;
JAVA_UNICODE_ESCAPE = true;
in JBossQLParser.jjt and EJBQLParser.jjt files are
responsible for this behaviour! I guess due to the way
the are set [EJB/JBoss]QLParser expects queries to be
non-Unicode encoded (1 character - 1 byte) with
characters not defined in current character set in
Unicode-escaped format (\u).
If I pass parameter like '\u0105' instead of '#261;' then
it works. 

Simply setting   JAVA_UNICODE_ESCAPE = false;
reverses the situation. I beleive this is supposed to
be the default. I have not checked if queries in other
encodings (like ISO-8859-X) work with this
configuration, but I don't see a reason why they should
not!

Tested on:
JBoss 3.2.1, 3.2.2 and 3.2.3
JVM 1.4.1_02 and 1.4.2_03
OS: Linux  2.4.22 and Widows 2000/XP

JBoss was started with -Dfile.encoding=UTF-8

 


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=887491group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-887648 ] Failed to connect to server

[SourceForge.net]

Bugs item #887648, was opened at 2004-01-30 09:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=887648group_id=22866

Category: Clustering
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim McCune (javajedi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Failed to connect to server

Initial Comment:
I've got a clustered environment (JBoss 3.2.2) where
one cluster node (not always the same one) will
sometimes just disappear from the cluster.  If I invoke
calls directly on that node, everything works fine, and
it can see the rest of the cluster fine.  However, the
rest of the cluster can't find it.  On the disappearing
node, I get this in my server.log at the time that it
disappears:

2004-01-29 19:53:49,630 INFO  [STDOUT]
---
GMS: address is blackwidow:32844
---

On the other cluster nodes, I get this:

2004-01-29 19:53:36,889 INFO 
[DefaultPartition:ReplicantManager] Dead members: 1
2004-01-29 19:53:36,889 DEBUG
[DefaultPartition:ReplicantManager] trying to remove
deadMember 192.168.1.127:1099 for key
jboss.j2ee:jndiName=com/hmsonline/harvester/control/client/Controller,service=EJB
2004-01-29 19:53:36,890 DEBUG
[DefaultPartition:ReplicantManager] 192.168.1.127:1099
was removed
2004-01-29 19:53:36,890 DEBUG
[DefaultPartition:ReplicantManager] notifyKeyListeners
2004-01-29 19:53:36,890 DEBUG
[DefaultPartition:ReplicantManager] notifying 2
listeners for key change:
jboss.j2ee:jndiName=com/hmsonline/harvester/control/client/Controller,service=EJB
2004-01-29 19:53:36,896 DEBUG
[DefaultPartition:ReplicantManager] trying to remove
deadMember 192.168.1.127:1099 for key HAJNDI
2004-01-29 19:53:36,896 DEBUG
[DefaultPartition:ReplicantManager] 192.168.1.127:1099
was removed
2004-01-29 19:53:36,896 DEBUG
[DefaultPartition:ReplicantManager] notifyKeyListeners
2004-01-29 19:53:36,896 DEBUG
[DefaultPartition:ReplicantManager] notifying 1
listeners for key change: HAJNDI
2004-01-29 19:53:36,896 DEBUG
[DefaultPartition:ReplicantManager] trying to remove
deadMember 192.168.1.127:1099 for key
jboss.j2ee:jndiName=com/hmsonline/harvester/control/client/PlanScheduler,service=EJB
2004-01-29 19:53:36,896 DEBUG
[DefaultPartition:ReplicantManager] 192.168.1.127:1099
was removed
2004-01-29 19:53:36,896 DEBUG
[DefaultPartition:ReplicantManager] notifyKeyListeners
2004-01-29 19:53:36,896 DEBUG
[DefaultPartition:ReplicantManager] notifying 2
listeners for key change:
jboss.j2ee:jndiName=com/hmsonline/harvester/control/client/PlanScheduler,service=EJB
2004-01-29 19:53:36,899 DEBUG
[DefaultPartition:ReplicantManager] trying to remove
deadMember 192.168.1.127:1099 for key
jboss.j2ee:jndiName=com/hmsonline/harvester/control/client/Historian,service=EJB
2004-01-29 19:53:36,899 DEBUG
[DefaultPartition:ReplicantManager] 192.168.1.127:1099
was removed
2004-01-29 19:53:36,899 DEBUG
[DefaultPartition:ReplicantManager] notifyKeyListeners
2004-01-29 19:53:36,899 DEBUG
[DefaultPartition:ReplicantManager] notifying 2
listeners for key change:
jboss.j2ee:jndiName=com/hmsonline/harvester/control/client/Historian,service=EJB
2004-01-29 19:53:36,902 DEBUG
[DefaultPartition:ReplicantManager] trying to remove
deadMember 192.168.1.127:1099 for key
jboss.j2ee:jndiName=com/hmsonline/harvester/control/client/PlanController,service=EJB
2004-01-29 19:53:36,902 DEBUG
[DefaultPartition:ReplicantManager] 192.168.1.127:1099
was removed
2004-01-29 19:53:36,902 DEBUG
[DefaultPartition:ReplicantManager] notifyKeyListeners
2004-01-29 19:53:36,902 DEBUG
[DefaultPartition:ReplicantManager] notifying 2
listeners for key change:
jboss.j2ee:jndiName=com/hmsonline/harvester/control/client/PlanController,service=EJB
2004-01-29 19:53:36,905 DEBUG
[DefaultPartition:ReplicantManager] trying to remove
deadMember 192.168.1.127:1099 for key
DCacheBridge-DefaultJGBridge
2004-01-29 19:53:36,905 DEBUG
[DefaultPartition:ReplicantManager] 192.168.1.127:1099
was removed
2004-01-29 19:53:36,905 DEBUG
[DefaultPartition:ReplicantManager] notifyKeyListeners
2004-01-29 19:53:36,906 DEBUG
[DefaultPartition:ReplicantManager] notifying 1
listeners for key change: DCacheBridge-DefaultJGBridge
2004-01-29 19:53:53,425 INFO 
[DefaultPartition:ReplicantManager] Dead members: 0
2004-01-29 19:53:59,629 WARN 
[org.jnp.interfaces.NamingContext] Failed to connect to
192.168.1.127:32844
javax.naming.CommunicationException: Failed to connect
to server 192.168.1.127:32844 [Root exception is
javax.naming.ServiceUnavailableException: Failed to
connect to server 192.168.1.127:32844 [Root exception
is java.net.ConnectException: Connection refused]]
at
org.jnp.interfaces.NamingContext.getServer(NamingContext.java:215)
at
org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1181)
at

[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file

[SourceForge.net]

Bugs item #870942, was opened at 2004-01-05 06:54
Message generated for change (Comment added) made by mhandwerker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=870942group_id=22866

Category: JBossMX
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Steve Wolfangel (swolfangel)
Assigned to: Scott M Stark (starksm)
Summary: Classloader problem with ear file

Initial Comment:
Hello,

I have an ear file that contains 2 stateless session 
beans and all the 3rd party jars required by the beans. 
The 3rd party jars contain older jdom classes than the 
jdom jar included in the jboss lib dir. I have a unique 
classloader setup (in the jboss-app.xml file) but I am 
having problems with jdom. It is finding the jboss jdom 
classes instead of the ones included in the ear. 

when I change the jboss-app.xml file to contain the 
following lines:

jboss-app
loader-repository
com.metamatrix:loader=MM.ear
loader-repository-
configjava2ParentDelegation=false/loader-repository-
config 
/loader-repository
/jboss-app

I get a NoClassDefFoundError. 

 java.lang.NoClassDefFoundError: java/sql/SQLException

This class is in the rt.jar file in the jdk!

I was under the impression that setting 
java2ParentDelegation to false meant that if the class 
was not found using the local classloader then the 
parent classloader would be called. 

In a nutshell, when I have java2ParentDelegation set to 
true, I get the jdom problem, when I have 
java2ParentDelegation set to false I am unable to see 
classes that are in the rt.jar file. 


Here is the output when starting the server.

[Server] Starting JBoss (MX MicroKernel)...
[Server] Release ID: JBoss [WonderLand] 3.2.3 (build: 
CVSTag=JBoss_3_2_3 date=200311301445)
[Server] Home Dir: D:\mm40\jb32\server\jboss
[Server] Home URL: file:/D:/mm40/jb32/server/jboss/
[Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/
[Server] Patch URL: null
[Server] Server Name: metamatrix
[Server] Server Home Dir: D:\mm40\jb32
\server\jboss\server\metamatrix
[Server] Server Home URL: 
file:/D:/mm40/jb32/server/jboss/server/metamatrix/
[Server] Server Data Dir: D:\mm40\jb32
\server\jboss\server\metamatrix\data
[Server] Server Temp Dir: D:\mm40\jb32
\server\jboss\server\metamatrix\tmp
[Server] Server Config URL: 
file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/
[Server] Server Library URL: 
file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/
[Server] Root Deployment Filename: jboss-service.xml
[Server] Starting General Purpose Architecture (GPA)...
[ServerInfo] Java version: 1.4.2,Sun Microsystems Inc.
[ServerInfo] Java VM: Java HotSpot(TM) Client VM 
1.4.2-b28,Sun Microsystems Inc.
[ServerInfo] OS-System: Windows XP 5.1,x86

--

Comment By: Martin Handwerker (mhandwerker)
Date: 2004-01-23 13:19

Message:
Logged In: YES 
user_id=952324

The jboss classloader should not be special-casing java.*, or 
any other package names (Scott-- my interpretation of your 
last comment is that you think it should).

Metamatrix probably shouldn't be redistributing java.sql 
classes with their ear, but if they do, those classes SHOULD 
override the system java.sql classes when referenced from 
the EAR.

Scott mentioned that there is a test-case for replacing the 
XML parser with a different version of Xerces.  We are doing 
just that with our EAR, and are finding that jboss is trying to 
use our Xerces classes when parsing our descriptors, even 
though we have java2ParentDelegation set to false in a jboss-
app.xml file.

--

Comment By: Scott M Stark (starksm)
Date: 2004-01-23 12:37

Message:
Logged In: YES 
user_id=175228

This is due to the use of scoped class loading that wants to
load classes from ear before the parent class loader, and
the inclusion of java.sql package classes in the ear:

+- metamatrix-server.jar (archive)
...
|  +- java/sql/Package.html
|  +- java/sql/ParameterMetaData.class
|  +- java/sql/Savepoint.class

classes in the java.* should not be able to override the
system classes, but this should not be preventing the load
of system classes so this is a bug.


--

Comment By: Scott M Stark (starksm)
Date: 2004-01-15 04:56

Message:
Logged In: YES 
user_id=175228

There is no zip file with the ucl.log attached to this bug,
only the server.log. If the zip file exceeds the attachment
size limit send it to [EMAIL PROTECTED]


--

Comment By: Steve Wolfangel (swolfangel)
Date: 2004-01-06 08:39

Message:
Logged In: YES 
user_id=541224

Is there any thing else I can do to help troubleshoot this 
problem?  

--

Comment By: Steve Wolfangel (swolfangel)

[JBoss-dev] [ jboss-Bugs-877172 ] NullPointerException in LoadMgr3

[SourceForge.net]

Bugs item #877172, was opened at 2004-01-14 13:59
Message generated for change (Comment added) made by jcalabrese
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=877172group_id=22866

Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim McCune (javajedi)
Assigned to: Scott M Stark (starksm)
Summary: NullPointerException in LoadMgr3

Initial Comment:
I get this error out of JBoss 3.2.2 on a fairly regular
basis.  I'm still not sure exactly how to reproduce it,
but since it's an NPE, I'm hoping that someone can
track down what would cause it to happen fairly easily.
 Once it occurs for a particular class, the only fix is
to restart JBoss.  I never had this problem on 3.2.0.

java.lang.NullPointerException at
org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119)
at
org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:169)
at
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:123)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:235) 
   at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)

Looking at the code, the UnifiedLoaderRepository3 that
is passed into beginLoadTask as the 2nd parameter must
be null.  UnifiedClassLoader3, line 118 does a null
check for repository just a few lines before calling
loadClassImpl, so I'm assuming that this is a valid
state for the class loader to be in.  That would mean
that beginLoadTask in LoadMgr3 needs to handle the
situation where repository is null.

--

Comment By: Jason Calabrese (jcalabrese)
Date: 2004-01-30 10:31

Message:
Logged In: YES 
user_id=300014

Thanks for the quick response. 
 
Yes, this is just a standalone war in the deploy 
directory. 
 
I rolled back to 3.2.0 and now I don't get the NPE after 
redeploy. 

--

Comment By: Scott M Stark (starksm)
Date: 2004-01-30 10:01

Message:
Logged In: YES 
user_id=175228

And this is a standalone war sitting in the deploy
directory? A potential issue looking at this trace is that
since your going into the JCE layer, there might be caching
of the previous classes and they are using their original
class loader which has been destroyed. Unless all references
to the previous deployments classes are free to be garbage
collected, there is the potential for the NPE when
additional classes need to be loaded when access the
previous version classes.

--

Comment By: Jason Calabrese (jcalabrese)
Date: 2004-01-30 09:47

Message:
Logged In: YES 
user_id=300014

I'm having the same problem with 3.2.3. 
 
Everything works fine and then I redeploy the war and get 
the NPE.   
 
Here's my stack trace: 
 
09:42:22,108 ERROR [STDERR] java.lang.NullPointerException 
09:42:22,109 ERROR [STDERR] at 
org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119) 
09:42:22,110 ERROR [STDERR] at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:169) 
09:42:22,112 ERROR [STDERR] at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:123) 
09:42:22,113 ERROR [STDERR] at 
java.lang.ClassLoader.loadClass(ClassLoader.java:235) 
09:42:22,114 ERROR [STDERR] at 
javax.crypto.SunJCE_b.c(DashoA6275) 
09:42:22,115 ERROR [STDERR] at 
javax.crypto.SunJCE_b.a(DashoA6275) 
09:42:22,116 ERROR [STDERR] at 
javax.crypto.Cipher.a(DashoA6275) 
09:42:22,117 ERROR [STDERR] at 
javax.crypto.Cipher.getInstance(DashoA6275) 
09:42:22,118 ERROR [STDERR] at 
com.contentscan.openpgp.OpenPGPUtil.getCipher(OpenPGPUtil.java:169) 
09:42:22,119 ERROR [STDERR] at 
com.contentscan.domeLogic.DomeSessionMgr.decrypt(DomeSessionMgr.java:612) 
09:42:22,120 ERROR [STDERR] at 
com.contentscan.domeLogic.DomeSessionMgr.decryptSessionKey(DomeSessionMgr.java:629) 
09:42:22,121 ERROR [STDERR] at 
com.contentscan.domeLogic.DomeSessionMgr.validateSession(DomeSessionMgr.java:280) 
09:42:22,123 ERROR [STDERR] at 
com.contentscan.webdome.WebEnvironment.establishSession(WebEnvironment.java:229) 
09:42:22,123 ERROR [STDERR] at 
com.contentscan.webdome.WebEnvironment.init(WebEnvironment.java:143) 
09:42:22,125 ERROR [STDERR] at 
com.contentscan.webdome.WebEnvironment.init(WebEnvironment.java:48) 
09:42:22,126 ERROR [STDERR] at 
org.apache.jsp.welcome_jsp._jspService(welcome_jsp.java:89) 
09:42:22,127 ERROR [STDERR] at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137) 
09:42:22,128 ERROR [STDERR] at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 
09:42:22,129 ERROR [STDERR] at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:210) 
09:42:22,130 ERROR [STDERR] at 

[JBoss-dev] [ jboss-Bugs-780746 ] Unable to passivate due

[SourceForge.net]

Bugs item #780746, was opened at 2003-07-31 05:55
Message generated for change (Comment added) made by rmchan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=780746group_id=22866

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Meyer (mmrmichael)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to passivate due

Initial Comment:

OS : Linux
JDK : 1.4.2
JBoss Version : 3.2.2 RC1 

I got the following error (on console) :

WARN [AbstractInstanceCache] Unable to passivate due to
ctx lock, id = xxx.

The result of this error is the complete use of memory
and I have to restart the server.


Michael Meyer


--

Comment By: Russell Chan (rmchan)
Date: 2004-01-28 19:32

Message:
Logged In: YES 
user_id=793049

Hi,

Scott, here's the original email.

For further info, I can email you the little test case that
I use, (needs xdoclet and ant to build), but I happen to use
jython (Java python - www.jython.org) to test it.  (This, of
course, is a remote not-in VM program).

My very simple jython/python test is as follows

-- script start --
ic = InitialContext()
bhome = ic.lookup(ejb/TestSFSB)
b1 = bhome.create(1)
handle = b1.getHandle()
# everything is fine up to here

b2 = handle.getEJBObject()

#as soon as I ussue the above  command, the 
#unable to passivates start showing up.

--script end--



I can email you a tarred version of the build tree for test
bean, but it's really nothing more than a stateful bean with
the default container settings.

I'd attach something, but this sourceforge interface doesn't
appear to let me do that.


Some more info that I also posted to the list:

--Email start--
Some more info... This behaviour happens regardless of being
in a
transaction...
   

If I run a jython (python in a java interpreter - useful for
testing!)
connecting to the jboss server, I get the Unable to
passivate message as soon as I call handle.getEJBObject()
from the remote client, and the passivation thread runs.
   

The jboss management console just shows the 
statefulSessionInstanceCache for the stateful bean growing
larger and larger as more instances of the stateful bean are
created.
   

The pool management works fine, however.
--Email end--



 I've been wrestling with this problem for a little while.

 Environment: JBoss 3.2.3, Sun JDK 1.4.2_01 on linux (debian)

 I have a stateful bean which appears to work fine for the
most part.
 I can generally do some operations on it, within a
transaction, and then
 remove the bean.  I've set the passivation time very low
(20 secs) as
 well as the expiry times on the bean as below:

remover-period10/remover-period
overager-period10/overager-period
max-bean-life60/max-bean-life
max-bean-age20/max-bean-age


 I've found one case however, where this can cause a
problem.  If I get a
 handle from the stateful bean, in order to use it (
possibly to put in
 an HTTPSession, or someother) that works fine.

 Restoring the bean (and possibly activating it) from the
container also
 works fine.  HOWEVER, I have found that if the remote stub
does that,
 OUTSIDE of a transaction context, there is a ref lock left
on the
 stateful session bean, and from there it won't passivate
properly - is
 this proper behaviour??  (BTW, I haven't yet tried this
within a
 UserTransaction).


 Lots of warning like this:

 15:20:32,559 WARN  [AbstractInstanceCache] Unable to
passivate due to
 ctx lock, id=dpsp9lca-7
 15:20:52,597 WARN  [AbstractInstanceCache] Unable to
passivate due to
 ctx lock, id=dpsp9lca-7
 15:21:12,639 WARN  [AbstractInstanceCache] Unable to
passivate due to
 ctx lock, id=dpsp9lca-7

 There's some more detail in the  snippet of log attached.



Here's the log...

 2004-01-23 15:20:06,567 DEBUG
[org.jboss.ejb.plugins.LogInterceptor] InvokeHome:
getEJBObject(dpsp9lca-7)
 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.plugins.TxInterceptorCMT] Current transaction
in MI is null
 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.plugins.TxInterceptorCMT] TX_REQUIRED for
getEJBObject
 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.plugins.TxInterceptorCMT] Thread came in with
tx null
 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.plugins.TxInterceptorCMT] Starting new tx
TransactionImpl:XidImpl [FormatId=257, GlobalId=blade//41,
BranchQual=]
 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
HOMEMETHOD coming in
 2004-01-23 15:20:06,567 TRACE

[JBoss-dev] [ jboss-Bugs-885357 ] BMP ejbStore loop

[SourceForge.net]

Bugs item #885357, was opened at 2004-01-27 11:00
Message generated for change (Comment added) made by loubyansky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=885357group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: John Wagg (waggj)
Assigned to: Nobody/Anonymous (nobody)
Summary: BMP ejbStore loop

Initial Comment:
I am having a problem porting our application from JBoss 
3.2.1 to 3.2.3. My current problem is an infinite loop 
occuring during an update of a BMP entity bean. The 
outer session bean method has a transaction attribute 
of 'required'. This method uses a BMP home interface to 
do a findByPrimaryKey. It does this again for a second 
BMP entity bean. It then does a get for just one column 
in the first entity. Then it does a different get for the 
second entity bean. All the BMP entity bean methods 
have a 'required' transaction attribute. On calling the 
second get method JBoss has decided that it needs to 
update the first BMP entity bean. i.e. it calls ejbStore on 
the bean. I'm not sure why it should feel the need to do 
this but it does. The problem is that it then gets into a 
loop. The ejbStore method for the bean is doing a 
findByPrimaryKey and a series of sets for one of two 
possible CMP entity beans. All the methods for these 
two CMP beans are 'required' transaction attributes as 
well. It eventually gets a stack overflow but the stack 
trace shows that the update for the CMP bean it has 
chosen forces another ejbStore for the BMP bean and so 
on. 

Here's a section of the stack trace showing one loop 

at 
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeH
ome(BaseLocalProxyFactory.java:293) 
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke
(LocalHomeProxy.java:110) 
at $Proxy214.findByPrimaryKey(Unknown Source) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.update(DFCamatgrpBean.java:555) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.ejbStore(DFCamatgrpBean.java:459) 
at sun.reflect.GeneratedMethodAccessor52.invoke
(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:324) 
at 
org.jboss.ejb.plugins.BMPPersistenceManager.storeEntity
(BMPPersistenceManager.java:454) 
at 
org.jboss.resource.connectionmanager.CachedConnectio
nInterceptor.storeEntity
(CachedConnectionInterceptor.java:387) 
at org.jboss.ejb.EntityContainer.storeEntity
(EntityContainer.java:714) 
at org.jboss.ejb.GlobalTxEntityMap.synchronizeEntities
(GlobalTxEntityMap.java:149) 
at 
org.jboss.ejb.EntityContainer.synchronizeEntitiesWithinTr
ansaction(EntityContainer.java:119) 
at org.jboss.ejb.EntityContainer.findLocal
(EntityContainer.java:607) 
at sun.reflect.GeneratedMethodAccessor48.invoke
(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:324) 
at 
org.jboss.ejb.EntityContainer$ContainerInterceptor.invok
eHome(EntityContainer.java:1043) 
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome
(AbstractInterceptor.java:88) 
at 
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv
okeHome(EntitySynchronizationInterceptor.java:197) 
at 
org.jboss.resource.connectionmanager.CachedConnectio
nInterceptor.invokeHome
(CachedConnectionInterceptor.java:214) 
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome
(AbstractInterceptor.java:88) 
at 
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHo
me(EntityInstanceInterceptor.java:89) 
at 
org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome
(EntityLockInterceptor.java:61) 
at 
org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHo
me(EntityCreationInterceptor.java:28) 
at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:88) 
at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:267) 
at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome
(TxInterceptorCMT.java:98) 
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome
(SecurityInterceptor.java:92) 
at org.jboss.ejb.plugins.LogInterceptor.invokeHome
(LogInterceptor.java:120) 
at 
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok
eHome(ProxyFactoryFinderInterceptor.java:93) 
at org.jboss.ejb.EntityContainer.internalInvokeHome
(EntityContainer.java:483) 
at org.jboss.ejb.Container.invoke(Container.java:720) 
at 
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeH
ome(BaseLocalProxyFactory.java:293) 
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke
(LocalHomeProxy.java:110) 
at $Proxy214.findByPrimaryKey(Unknown Source) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.update(DFCamatgrpBean.java:555) 
at 
com.axxia.pkc.core.afcl.entity.common.dualfuel.DFCamat
grpBean.ejbStore(DFCamatgrpBean.java:459) 
at sun.reflect.GeneratedMethodAccessor52.invoke
(Unknown 

[JBoss-dev] [ jboss-Bugs-887654 ] EJB-jar w/o jboss.xml defaults to other EJB-jar's jboss.xml

[SourceForge.net]

Bugs item #887654, was opened at 2004-01-30 09:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=887654group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: John Casey (johnqueso)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB-jar w/o jboss.xml defaults to other EJB-jar's jboss.xml

Initial Comment:
This bug was produced with JBoss 3.2.3 on WinXP Pro
with JDK 1.4.1, although I have no reason to believe
that it would be constrained to this environment.

Somehow, if one of your EJB-jars (in an EAR) doesn't
specify a jboss.xml descriptor, this descriptor is
picked up from another EJB-jar in the EAR, which will
result in the following error:

09:26:14,746 ERROR [XmlFileLoader] failed to load
jboss.xml. There could be a syntax error.
org.jboss.deployment.DeploymentException: Error in
jboss.xml for Bean SubscriptionList: found in jboss.xml
but not in ejb-jar.xml


Basically, here is the setup:

\EAR
--\EJB1
\META-INF\jboss.xml
\META-INF\ejb-jar.xml
--\EJB2
\META-INF\ejb-jar.xml

Now, when JBoss deploys the EAR file, it gets through
the initialization of EJB1 just fine. However, when it
gets to EJB2, it reads the ejb-jar.xml and initializes
the ApplicationMetaData , and then tries to augment it
from the jboss.xml file. Both of these are read with
calls similar to:

getClassloader().getResource(META-INF/ejb-jar.xml);
getClassloader().getResource(META-INF/jboss.xml);

In this case, EJB2 has no jboss.xml, and therefore the
classloader hierarchy being used by the XMLFileLoader
seems to move up a step and look at the wider EAR.
Since the last EJB, EJB1 was placed in this
classloader, it immediately finds META-INF/jboss.xml
from _that_ jar, and loads it. This results in searches
for the EJB's defined in EJB1 inside the
ApplicationMetaData which was setup based on the
ejb-jar.xml file in EJB2.

I know that this is not the desired behavior, but I'm
not well enough versed in the internals of JBoss to
come up with an adequate patch.  I'm not even sure
where the defaults are stored for the case where an EJB
deployed in isolation doesn't contain a jboss.xml file.
I'm sure you all have a default scenario, to make JBoss
as user-friendly as possible, but in the case of an
EAR, this logical path will never be traversed.

For my initial postings/musings/explorations on this
bug, see the Forum:

http://jboss.org/index.html?module=bbop=viewtopict=44884



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=887654group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 30-January-2004

[noreply]

Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 30-January-2004


JBoss daily test results

SUMMARY

Number of tests run:   1651



Successful tests:  1630

Errors:10

Failures:  11





[time of test: 2004-01-30.06-48 GMT]
[java.version: 1.4.2_03]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.4.2_03-b02]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.20-9smp]

Useful resources:

- http://jboss.sourceforge.net//junit-results/32/2004-01-30.06-48 for
the junit report of this test.


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.

It is assumed that whoever makes change(s) to jboss that 
break the test will be fixing the test or jboss, as appropriate!





DETAILS OF ERRORS



Suite:   org.jboss.test.cts.test.StatefulSessionUnitTestCase
Test:testStrictPooling
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: SessionInvoker.runEx != null
-



Suite:   org.jboss.test.exception.EntityExceptionUnitTestCase
Test:testNotDiscardedApplicationExceptionInTxMarkRollback_remote
Type:error
Exception:   net.sourceforge.junitejb.RemoteTestException
Message: Error, bean instance was discarded!
-



Suite:   org.jboss.test.exception.EntityExceptionUnitTestCase
Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_remote
Type:error
Exception:   net.sourceforge.junitejb.RemoteTestException
Message: Error, bean instance was discarded!
-



Suite:   org.jboss.test.exception.EntityExceptionUnitTestCase
Test:testNotDiscardedApplicationExceptionNoTx_remote
Type:error
Exception:   net.sourceforge.junitejb.RemoteTestException
Message: Error, bean instance was discarded!
-



Suite:   org.jboss.test.exception.EntityExceptionUnitTestCase
Test:testNotDiscardedApplicationExceptionInTxMarkRollback_local
Type:error
Exception:   net.sourceforge.junitejb.RemoteTestException
Message: Error, bean instance was discarded!
-



Suite:   org.jboss.test.exception.EntityExceptionUnitTestCase
Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_local
Type:error
Exception:   net.sourceforge.junitejb.RemoteTestException
Message: Error, bean instance was discarded!
-



Suite:   org.jboss.test.exception.EntityExceptionUnitTestCase
Test:testNotDiscardedApplicationExceptionNoTx_local
Type:error
Exception:   net.sourceforge.junitejb.RemoteTestException
Message: Error, bean instance was discarded!
-



Suite:   org.jboss.test.jmx.test.DeployServiceUnitTestCase
Test:testSpaceInClasspath
Type:error
Exception:   org.jboss.deployment.DeploymentException
Message: /starksm/JBoss/jboss-3.2/testsuite/output/lib; - nested throwable: 
(java.io.FileNotFoundException: /starksm/JBoss/jboss-3.2/testsuite/output/lib)
-



Suite:   org.jboss.test.naming.test.SimpleUnitTestCase
Test:testNameChanges
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: name.equals(copy), name=jmx
-



Suite:   org.jboss.test.webservice.external.ExternalUnitTestCase
Test:testFederated
Type:failure
Exception:   junit.framework.ComparisonFailure
Message: got the translation right expected:JBoss ist ein M�rderbediener und 
Herr Fleury ist ein verdammtes Genie  but was:This service is currently disabled.
-



Suite:   org.jboss.test.naming.test.SecurityUnitTestCase
Test:testSecureHttpInvoker
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: Should not have been able to lookup(invokers)
-



Suite:   org.jboss.test.security.test.EJBSpecUnitTestCase
Test:testMDBRunAs
Type:error
Exception:   java.lang.NullPointerException
Message: 
-



Suite:   org.jboss.test.bank.test.BankEJB20StressTestCase
Test:testMultiThread
Type:error
Exception:   org.jboss.test.bank.interfaces.BankException
Message: Could not transfer -50.0 from bank/Account:5678.Marc.1075446682573 to 
bank/Account:5678.Rickard.1075446682574
-



Suite:   org.jboss.test.deadlock.test.BeanStressTestCase
Test:testAllCompleteOrFail
Type:failure
Exception:   

[JBoss-dev] [ jboss-Bugs-887832 ] finder does not find existing data

[SourceForge.net]

Bugs item #887832, was opened at 2004-01-30 21:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=887832group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Langelage (lafr)
Assigned to: Nobody/Anonymous (nobody)
Summary: finder does not find existing data

Initial Comment:
Bean MbiMenue with this finder-declaration processed by
XDoclet:
 * @ejb.finder signature=java.util.Collection
findByUsernameSprachKbez (java.lang.String username,
java.lang.String sprach_kbez)
 *   view-type=local
 *   query=SELECT OBJECT(o) FROM MbiMenue AS o WHERE
o.username = ?1 AND o.sprachKbez = ?2
 *   result-type-mapping=Local

This finder does not find data.
If I replace the variables ?1 and ?2 by constant values
the data is found.
I swichted on log level trace an saw, that the
variables are filled correctly, but they are filled as
jdbc-type VARCHAR.

But field username is defined
 *  column-name=username
 *  sql-type=CHAR(8)
 *  jdbc-type=CHAR
and field sprach_kbez
 *  column-name=sprach_kbez
 *  sql-type=CHAR(2)
 *  jdbc-type=CHAR

The table is created by jboss and the columns are of
the expected type.
If I switch the Oracle9i mapping for String from
VARCHAR to CHAR  the jdbc-type of the variables changes
from VARCHAR to CHAR but finder does not find anything.

System:
- current JBoss-3.2 branch
- JDK 1.4.2_03
- Solaris 9 on Sparc
- XDoclet 1.2
- Oracle 9i 9.2.0.4




--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=887832group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] test

[julien viet]

email test


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] test again

[julien viet]

email test again


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] a third test

[julien viet]

email test again


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-887832 ] finder does not find existing data

[SourceForge.net]

Bugs item #887832, was opened at 2004-01-30 22:56
Message generated for change (Comment added) made by loubyansky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=887832group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Langelage (lafr)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: finder does not find existing data

Initial Comment:
Bean MbiMenue with this finder-declaration processed by
XDoclet:
 * @ejb.finder signature=java.util.Collection
findByUsernameSprachKbez (java.lang.String username,
java.lang.String sprach_kbez)
 *   view-type=local
 *   query=SELECT OBJECT(o) FROM MbiMenue AS o WHERE
o.username = ?1 AND o.sprachKbez = ?2
 *   result-type-mapping=Local

This finder does not find data.
If I replace the variables ?1 and ?2 by constant values
the data is found.
I swichted on log level trace an saw, that the
variables are filled correctly, but they are filled as
jdbc-type VARCHAR.

But field username is defined
 *  column-name=username
 *  sql-type=CHAR(8)
 *  jdbc-type=CHAR
and field sprach_kbez
 *  column-name=sprach_kbez
 *  sql-type=CHAR(2)
 *  jdbc-type=CHAR

The table is created by jboss and the columns are of
the expected type.
If I switch the Oracle9i mapping for String from
VARCHAR to CHAR  the jdbc-type of the variables changes
from VARCHAR to CHAR but finder does not find anything.

System:
- current JBoss-3.2 branch
- JDK 1.4.2_03
- Solaris 9 on Sparc
- XDoclet 1.2
- Oracle 9i 9.2.0.4




--

Comment By: Alexey Loubyansky (loubyansky)
Date: 2004-02-03 03:00

Message:
Logged In: YES 
user_id=543482

If you try the same SQL with direct JDBC from JBoss will it
return the data?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=887832group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] JBoss Shutdown Failed! JBoss (HEAD/winxp/1.4.1_06) [AUTOMATED]

[chris]

===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
Tue Feb  3 01:12:31 GMTST 2004
===
HERE ARE THE LAST 100 LINES OF THE LOG:
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
javax.naming.NamingException: Could not dereference object.  Root exception is 
javax.naming.CommunicationException.  Root exception is 
java.lang.ClassNotFoundException: org.jboss.jmx.adaptor.rmi.RMIAdaptor (no security 
manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:521)
at java.rmi.server.RMIClassLoader$2.loadProxyClass(RMIClassLoader.java:639)
at java.rmi.server.RMIClassLoader.loadProxyClass(RMIClassLoader.java:309)
at 
sun.rmi.server.MarshalInputStream.resolveProxyClass(MarshalInputStream.java:241)
at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1469)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1432)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:30)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:550)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:964)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:613)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at org.jboss.Shutdown.main(Shutdown.java:182)
Exception in thread main JBOSS SHUTDOWN FAILED

===
Tue Feb  3 01:12:31 GMTST 2004
===
CYGWIN_NT-5.1 quarks2 1.5.4(0.94/3/2) 2003-09-12 23:08 i686 unknown unknown Cygwin
===
java -version
java version 1.4.1_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_06-b01)
Java HotSpot(TM) Client VM (build 1.4.1_06-b01, mixed mode)


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-889390 ] CMR's don't outer-join when they should

[SourceForge.net]

Bugs item #889390, was opened at 2004-02-03 01:36
Message generated for change (Settings changed) made by loubyansky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889390group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Handwerker (mhandwerker)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: CMR's don't outer-join when they should

Initial Comment:
When I add the following EJB-QL finder to an entity bean:

SELECT DISTINCT OBJECT(a) FROM Acl a WHERE 
(a.accessorGuid = ?1) and (a.objectTypeAsString = ?3 
and (a.vCObject is null or a.vCObject.guid = ?2))

JDBCEJBQLCompiler generates the following incorrect 
SQL:

SELECT DISTINCT t0_a.acl_pk FROM vc_acl t0_a, 
vc_object t1_a_vCObject WHERE ((t0_a.accessor_guid 
= ?) AND (t0_a.object_type = ? AND (t0_a.obj_fk IS 
NULL OR t1_a_vCObject.obj_pk = ?)) AND 
t0_a.obj_fk=t1_a_vCObject.obj_pk)

Notice that there is a container-managed relationship 
between the AclBean and VCObjectBean on the obj_fk 
database column.

Because the EJB-QL mentions the guid field of 
VCObjectBean (a.vCObject.guid = ?2), 
JDBCEJBQLCompiler generates a join to VCObject accross 
the obj_fk foreign key field (...AND 
t0_a.obj_fk=t1_a_vCObject.obj_pk).  It incorrectly 
generates an inner-join, when an outer-join is required.  
If Acl.obj_fk is null, t0_a.obj_fk IS NULL should allow 
that Acl instance to be found, but it will not be found, 
because the inner-join to VCObject fails.

BEA Weblogic 7.x, 8.1, and IBM WebSphere 4.0.x and 
5.0 all correctly generate an outer join for this query.

I am running JBoss version 3.2.3 against Microsoft 
SQLServer 2000.

Martin Handwerker
Celequest Corporation
Work: (650) 637-2168
Email: mhandwerker AT celequest DOT com


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889390group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-889337 ] Read-ahead fails on one-to-one relationship

[SourceForge.net]

Bugs item #889337, was opened at 2004-02-03 00:10
Message generated for change (Settings changed) made by loubyansky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889337group_id=22866

Category: JBossCMP
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich C. (rchristy63)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: Read-ahead fails on one-to-one relationship

Initial Comment:
OS: Linux Redhat 9/Windows XP 
JDK: 1.4.2
JBOSS version: cvs head as of 1/21/03 (3.2.4 R1)

Since JBOSS only allows one table per bean, we simulate
inheritance of entity beans using delegation.So say
Bean A is a base class, Bean B has a getBeanA() method
which delegates all inherited calls through this
one-to-one relationship.   This has worked correctly on
past releases of JBOSS.  However in the version I built
off the cvs head, we noticed the following behavior by
stepping through the cmp code.  If Bean B has a preload
strategy of none, than everything works correctly.  I
can read one or many Bean Bs and everything works. 
However, changing preload strategy to either
on-find/on-load, causes the following exception only if
multiple bean Bs are returned by a finder (the first
one successfully is read and cached, the error occurs
on the second bean always retrieving the getBeanA
relation from the preload cache)

15:30:08,759 ERROR [LogInterceptor]
TransactionRolledbackLocalException in method: public
abstract java.util.Map
com.rcm.securitiesservice.ejbinterfaces.domain.Security.getSecurityProperties(),
causedBy:
javax.ejb.NoSuchObjectLocalException: New value
[2850513] of a foreign key field securityID changed the
value of a primary key field securityID[null]
at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:142)
at
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:89)
at
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:54)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:313)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:147)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at
org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:489)
at
org.jboss.ejb.Container.invoke(Container.java:700)
at
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:375)
at
org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
at $Proxy1441.getSecurityProperties(Unknown Source)
at
com.rcm.securitiesservice.serversupport.SecuritiesValueObjectFactory.fillSecurityValueObject(SecuritiesValueObjectFactory.java:499)


We are just if something has changed to cause this to
no longer work.  Preloading strategy seems to work
correctly for other one-to-one relationships, just not
this particular relationship

Thanks,

Rich


--

Comment By: Rich C. (rchristy63)
Date: 2004-02-03 00:14

Message:
Logged In: YES 
user_id=959867

Just to clarify, this works correctly with JBOSS version
3.2.2RC4 and 3.2.3RC1, but not in 3.2.4RC1 that we built
from the cvs head.

Thanks again,

Rich

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=889337group_id=22866


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] test from the website

[julien viet]

test from the website


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [Test Forum] - message from Test forum

[cooper]

View the original post : 
http://www.jboss.org/index.html?module=bbop=viewtopicp=3819985#3819985

Reply to the post : 
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3819985

message from Test forum


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [Development] - test post from the Nukes development forum

[nukes-user]

View the original post : 
http://www.jboss.org/index.html?module=bbop=viewtopicp=3819986#3819986

Reply to the post : 
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3819986

test post from the Nukes development forum


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [JBoss.net] - JBoss.net HTTP Basic Authentication problem

[jcurt]

View the original post : 
http://www.jboss.org/index.html?module=bbop=viewtopicp=3819987#3819987

Reply to the post : 
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3819987

I'm seeing unexpected behavior when accessing a secured JBoss.net web service.  The 
web service is configured to require HTTP Basic Authentication.  Here are the 3 cases, 
the third one is the problem:



1.  If the SOAP/HTTP request contains a valid username/password (i.e. Authentication 
header field is set to a valid username+password) then the service can be accessed as 
expected.



2.  If the request contains an incorrect username/password (i.e. Authentication header 
field set, but invalid username and/or password), then the server returns 401 
Unauthorized as expected.



3.  If the request does not contain an Authentication header field entry, the server 
returns 500 Internal Server Error.



In this case, the server should return 401 Unauthorized so the client's HTTP layer 
knows that it needs to obtain authorization information (i.e. prompt user for a 
username  password).  As it is, the client has no idea how to deal with the error.



I have verified this behavior using a TCP Monitor.  Also, I have verified that web 
applications on JBoss do NOT exhibit this behavior, i.e. they behave as expected in 
case #3 when accessing a secured html or jsp page.



I am using server version: jboss 3.2.1 w/tomcat 4.1.24



Has anyone else dealt with this?



Thanks,

-Curt




---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Expansion of service dependencies to redeployment

[Scott M Stark]

classpath and manifest refs only affect the classpath associated with a
deployment though, and generally this is incomplete because users rely
on the flat type model to not have to explicitly reference every source
of class they use. If the class loader associated with a deployed
tracked
what other deployments it used for classes(I don't see a need to track
down to the class level as the deployment has to be redeployed in order
for classes to be redeployed), this would form a dynamic usage
dependency
graph that could be used to pickup type based redeployments.

I agree there should be a dependency on a given deployment to is
deployer so
that we can remove the current logic where by the MainDeployer tries to
stop
all the deployments of a deployer when the deployer stops. This would be
an
automatic feature of the deployer/deployee dependency.

Likewise I agree that the deployment process needs better definition
such
as having a complete deployment graph before we start deploying
components.
I do think dependency should delay component creation in addition to
dispatch
of lifecycle ops.


Scott Stark
Chief Technology Officer
JBoss Group, LLC
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Monday, February 02, 2004 5:19 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Expansion of service dependencies to
redeployment

Hi Scott,

Our deployments generally boil down to a classpath and a set of mbeans.

There is also a contract to define a directed graph across deployments
which orders the mbean lifecycle invocations using depends

There are also implicit rules like:
1) deployments wait for their deployer
2) russian doll
3) deployment sorter

It appears to me, that what is missing is the ability to define the
directed graph for classloading.
Changing a parent deployment in this graph would require a redeployment
of children because the classloaders need to reconstructed.

To make it work, there needs to be enough information available to
define the graph.

The simplest approach would be to change the meaning of classpath to
define the graph/dependencies. The use of manifest.mf would also be
included.
i.e. each deployment explicity states which jars it uses.

More implicit rules could be defined:
1) A deployer could define its implementation jars which all its
deployments inherit in case a deployer is restarted.
2) There was an attempt early in 3.0 to define an MBeanClassLoader that
recorded which classes were actually used by a deployment. A
redeployment of those classes would force a redeployment of the mbean.
3) The MBeanClassLoader misses classes passed by reference across the
MBus where the signature is an interface, but this could be added.
4) There are other mechanisms where classes get passed by reference,
e.g. jndi. 
Mechanisms involving serialization
would be caught by the MBeanClassLoader.

Regards,
Adrian




---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development