Re: JBoss 3.0.4 ? (Re: [JBoss-dev] Upcoming releases)

[Scott M Stark]

When some outstanding bugs due to be fixed in 3.0.4 are fully tested.
A day, or two perhaps.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: Andreas Kuckartz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, October 27, 2002 11:06 PM
Subject: JBoss 3.0.4 ? (Re: [JBoss-dev] Upcoming releases)


 Due to this announcement of the precise release date of version 3.0.4 I have
 delayed work till today but I can not find the version on sourceforge.net.
 
 Any new date for the release of that version?
 
 Andreas



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: Re[2]: [JBoss-dev] -service.xml generator

[Sacha Labourey]

Hello,

Exactly, it may help to solve one of the current biggest issue wrt
configuration: any configuration done through any GUI (or mbean, etc.) is
not persisted = only transient configuration can be started remotly or
programatically. Having a generic way to build new persisted mbean
definition is important.

But we spoke about this on this ML a few weeks ago and we still have some
issues wrt implicit dependencies. Anyway, we need a way to persist
configuration that is currently only transient.

cheers,


Sacha

 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]De la part de Alex
 Loubyansky
 Envoye : lundi, 28 octobre 2002 07:17
 A : Anatoly Akkerman
 Objet : Re[2]: [JBoss-dev] -service.xml generator


 Anatoly, this looks cool and draws other perspectives. I'm in thought.

 Any other thoughts/comments?
 Thanks.

 alex

 Sunday, October 27, 2002, 4:07:15 PM, you wrote:

 AA Hi, Alex

 AA Jelly would give you similar ease of use but without having
 to write any
 AA XSL. You would initialize the JellyContext by creating in
 first and then
 AA setting variables in it from attributes like this:
 AA ctx.setVariable(name, value);

 AA (values can be any Java objects)

 AA you load your modified *-service.xml script from a URL into Jelly and
 AA run it as a script in the context which you just set up. The
 result of
 AA this operation is XML again.

 AA This is simplest usage of Jelly. You do need a library, though, and
 AA possibly, not one but a bunch from jakarta-commons.

 AA I am using Jelly in a slightly more advanced fashion. I wrote
 a few very
 AA simple tags that allow output of Jelly to be a jar file.
 Something like:
 AA j:jelly xmlns:j=jelly:core xmlns:zipper=jelly:mypackage.MyTagLib
 AA zipper:zip
 AA zipper:entry name=META-INF/ejb-jar.xml 
 AA parametrized ejb-jar.xml contents go here
 AA /zipper:entry
 AA zipper:entry name=META-INF/jboss.xml 
 AA parametrized jboss-xml contents go here
 AA /zipper:entry
 AA /zipper:zip
 AA /j:jelly

 AA Set up the JellyContext for running this script with appropriately
 AA configured variables (say from a DB of configurations or from
 attributes
 AA of an MBean). Run the script in the context.
 AA After running this script, the JellyContext contains a Jar
 archive (as a
 AA byte[] stored under some variable name) of reconfigured descriptors.

 AA The way I use it is to have a servlet that parses its path
 request and
 AA deduces from the path request which script to run and which
 AA configuration to pull from storage. The servlet outputs either XML or
 AA JAR depending on the requested module and its script.

 AA So, you can just point the JBoss deployer to deploy a URL of the kind:

 AA myservlet/componentA/configX.jar
 AA or
 AA myservlet/serviceB/configY.xml
 AA and the servlet automatically generates properly configured jar or xml
 AA which the Deployer happily deploys.

 AA Jelly has many usages this is just what I could come up with.
 It would
 AA be more than adequate for what you need to do, but if you are
 AA dissatisfied with JBoss library dependency growth, then,
 Jelly is out of
 AA the picture.

 AA Alex Loubyansky wrote:
  Thanks, Anatoly. I'll check it. Also I thought about Velocity which
  looks similar to Jelly from your description, though I am not familiar
  with the last one.
 
  Could you, please, look at the following idea with XML/XSL, compare it
  with Jelly and give your opinion?
  - before transformation, each MBean's attribute is set as a
 parameter to
  the Transformer with Transformer.setParameter(...) with the name equal
  to the corresponding parameter name used in XSL stylesheet;
  - transform XML template with Transformer and XSL stylesheet.
 
  As for me, XML/XSL requires two templates (XML and XSL) while
  Jelly/Velocity requires only one.
 
  Also, I wouldn't add any thirdparty library unless it really
 helps. The
  JBoss becomes so heavy. I think it's problem.


 --
 Best regards,
  Alex Loubyansky




 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re[4]: [JBoss-dev] -service.xml generator

[Alex Loubyansky]

Hello Sacha,

I thought about it too. As alternative or other implementation of
MBean persistence. Though, I am not familiar with MBean persistence stuff yet.
Are they meant to be serialized as java objects?
I think, having MBeans persisted in xml form is much better. Because I
can see what is persisted and change something manually.

alex

Monday, October 28, 2002, 10:06:36 AM, you wrote:

SL Hello,

SL Exactly, it may help to solve one of the current biggest issue wrt
SL configuration: any configuration done through any GUI (or mbean, etc.) is
not persisted = only transient configuration can be started remotly or
SL programatically. Having a generic way to build new persisted mbean
SL definition is important.

SL But we spoke about this on this ML a few weeks ago and we still have some
SL issues wrt implicit dependencies. Anyway, we need a way to persist
SL configuration that is currently only transient.

SL cheers,


SL Sacha

 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]De la part de Alex
 Loubyansky
 Envoye : lundi, 28 octobre 2002 07:17
 A : Anatoly Akkerman
 Objet : Re[2]: [JBoss-dev] -service.xml generator


 Anatoly, this looks cool and draws other perspectives. I'm in thought.

 Any other thoughts/comments?
 Thanks.

 alex

 Sunday, October 27, 2002, 4:07:15 PM, you wrote:

 AA Hi, Alex

 AA Jelly would give you similar ease of use but without having
 to write any
 AA XSL. You would initialize the JellyContext by creating in
 first and then
 AA setting variables in it from attributes like this:
 AA ctx.setVariable(name, value);

 AA (values can be any Java objects)

 AA you load your modified *-service.xml script from a URL into Jelly and
 AA run it as a script in the context which you just set up. The
 result of
 AA this operation is XML again.

 AA This is simplest usage of Jelly. You do need a library, though, and
 AA possibly, not one but a bunch from jakarta-commons.

 AA I am using Jelly in a slightly more advanced fashion. I wrote
 a few very
 AA simple tags that allow output of Jelly to be a jar file.
 Something like:
 AA j:jelly xmlns:j=jelly:core xmlns:zipper=jelly:mypackage.MyTagLib
 AA zipper:zip
 AA zipper:entry name=META-INF/ejb-jar.xml 
 AA parametrized ejb-jar.xml contents go here
 AA /zipper:entry
 AA zipper:entry name=META-INF/jboss.xml 
 AA parametrized jboss-xml contents go here
 AA /zipper:entry
 AA /zipper:zip
 AA /j:jelly

 AA Set up the JellyContext for running this script with appropriately
 AA configured variables (say from a DB of configurations or from
 attributes
 AA of an MBean). Run the script in the context.
 AA After running this script, the JellyContext contains a Jar
 archive (as a
 AA byte[] stored under some variable name) of reconfigured descriptors.

 AA The way I use it is to have a servlet that parses its path
 request and
 AA deduces from the path request which script to run and which
 AA configuration to pull from storage. The servlet outputs either XML or
 AA JAR depending on the requested module and its script.

 AA So, you can just point the JBoss deployer to deploy a URL of the kind:

 AA myservlet/componentA/configX.jar
 AA or
 AA myservlet/serviceB/configY.xml
 AA and the servlet automatically generates properly configured jar or xml
 AA which the Deployer happily deploys.

 AA Jelly has many usages this is just what I could come up with.
 It would
 AA be more than adequate for what you need to do, but if you are
 AA dissatisfied with JBoss library dependency growth, then,
 Jelly is out of
 AA the picture.

 AA Alex Loubyansky wrote:
  Thanks, Anatoly. I'll check it. Also I thought about Velocity which
  looks similar to Jelly from your description, though I am not familiar
  with the last one.
 
  Could you, please, look at the following idea with XML/XSL, compare it
  with Jelly and give your opinion?
  - before transformation, each MBean's attribute is set as a
 parameter to
  the Transformer with Transformer.setParameter(...) with the name equal
  to the corresponding parameter name used in XSL stylesheet;
  - transform XML template with Transformer and XSL stylesheet.
 
  As for me, XML/XSL requires two templates (XML and XSL) while
  Jelly/Velocity requires only one.
 
  Also, I wouldn't add any thirdparty library unless it really
 helps. The
  JBoss becomes so heavy. I think it's problem.


 --
 Best regards,
  Alex Loubyansky




 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


-- 
Best regards,
 Alex Loubyansky




---
This 

Re[2]: [JBoss-dev] -service.xml generator

[Alex Loubyansky]

I am thinking about this stuff of reconfiguring and redeployment.
It would be cool to have metadata of the deployed apps to be exposed
for modifications through jmx-console. And not only for changing
existing attributes but adding some resource references etc.
Then one can modify some stuff and redeploy the app.

alex

Sunday, October 27, 2002, 4:07:15 PM, you wrote:

AA Hi, Alex

AA Jelly would give you similar ease of use but without having to write any 
AA XSL. You would initialize the JellyContext by creating in first and then 
AA setting variables in it from attributes like this:
AA ctx.setVariable(name, value);

AA (values can be any Java objects)

AA you load your modified *-service.xml script from a URL into Jelly and 
AA run it as a script in the context which you just set up. The result of 
AA this operation is XML again.

AA This is simplest usage of Jelly. You do need a library, though, and 
AA possibly, not one but a bunch from jakarta-commons.

AA I am using Jelly in a slightly more advanced fashion. I wrote a few very 
AA simple tags that allow output of Jelly to be a jar file. Something like:
AA j:jelly xmlns:j=jelly:core xmlns:zipper=jelly:mypackage.MyTagLib
AA zipper:zip
AA zipper:entry name=META-INF/ejb-jar.xml 
AA parametrized ejb-jar.xml contents go here
AA /zipper:entry
AA zipper:entry name=META-INF/jboss.xml 
AA parametrized jboss-xml contents go here
AA /zipper:entry 
AA /zipper:zip
AA /j:jelly

AA Set up the JellyContext for running this script with appropriately 
AA configured variables (say from a DB of configurations or from attributes 
AA of an MBean). Run the script in the context.
AA After running this script, the JellyContext contains a Jar archive (as a 
AA byte[] stored under some variable name) of reconfigured descriptors.

AA The way I use it is to have a servlet that parses its path request and 
AA deduces from the path request which script to run and which 
AA configuration to pull from storage. The servlet outputs either XML or 
AA JAR depending on the requested module and its script.

AA So, you can just point the JBoss deployer to deploy a URL of the kind:

AA myservlet/componentA/configX.jar
AA or
AA myservlet/serviceB/configY.xml
AA and the servlet automatically generates properly configured jar or xml
AA which the Deployer happily deploys.

AA Jelly has many usages this is just what I could come up with. It would 
AA be more than adequate for what you need to do, but if you are 
AA dissatisfied with JBoss library dependency growth, then, Jelly is out of 
AA the picture.

AA Alex Loubyansky wrote:
 Thanks, Anatoly. I'll check it. Also I thought about Velocity which 
 looks similar to Jelly from your description, though I am not familiar 
 with the last one.
 
 Could you, please, look at the following idea with XML/XSL, compare it 
 with Jelly and give your opinion?
 - before transformation, each MBean's attribute is set as a parameter to 
 the Transformer with Transformer.setParameter(...) with the name equal 
 to the corresponding parameter name used in XSL stylesheet;
 - transform XML template with Transformer and XSL stylesheet.
 
 As for me, XML/XSL requires two templates (XML and XSL) while 
 Jelly/Velocity requires only one.
 
 Also, I wouldn't add any thirdparty library unless it really helps. The 
 JBoss becomes so heavy. I think it's problem.


-- 
Best regards,
 Alex Loubyansky




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: Re[2]: [JBoss-dev] -service.xml generator

[Sacha Labourey]

... and making these changes persistent! ;)

Yes, that would be really cool

 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]De la part de Alex
 Loubyansky
 Envoye : lundi, 28 octobre 2002 10:03
 A : Anatoly Akkerman
 Objet : Re[2]: [JBoss-dev] -service.xml generator


 I am thinking about this stuff of reconfiguring and redeployment.
 It would be cool to have metadata of the deployed apps to be exposed
 for modifications through jmx-console. And not only for changing
 existing attributes but adding some resource references etc.
 Then one can modify some stuff and redeploy the app.

 alex

 Sunday, October 27, 2002, 4:07:15 PM, you wrote:

 AA Hi, Alex

 AA Jelly would give you similar ease of use but without having
 to write any
 AA XSL. You would initialize the JellyContext by creating in
 first and then
 AA setting variables in it from attributes like this:
 AA ctx.setVariable(name, value);

 AA (values can be any Java objects)

 AA you load your modified *-service.xml script from a URL into Jelly and
 AA run it as a script in the context which you just set up. The
 result of
 AA this operation is XML again.

 AA This is simplest usage of Jelly. You do need a library, though, and
 AA possibly, not one but a bunch from jakarta-commons.

 AA I am using Jelly in a slightly more advanced fashion. I wrote
 a few very
 AA simple tags that allow output of Jelly to be a jar file.
 Something like:
 AA j:jelly xmlns:j=jelly:core xmlns:zipper=jelly:mypackage.MyTagLib
 AA zipper:zip
 AA zipper:entry name=META-INF/ejb-jar.xml 
 AA parametrized ejb-jar.xml contents go here
 AA /zipper:entry
 AA zipper:entry name=META-INF/jboss.xml 
 AA parametrized jboss-xml contents go here
 AA /zipper:entry
 AA /zipper:zip
 AA /j:jelly

 AA Set up the JellyContext for running this script with appropriately
 AA configured variables (say from a DB of configurations or from
 attributes
 AA of an MBean). Run the script in the context.
 AA After running this script, the JellyContext contains a Jar
 archive (as a
 AA byte[] stored under some variable name) of reconfigured descriptors.

 AA The way I use it is to have a servlet that parses its path
 request and
 AA deduces from the path request which script to run and which
 AA configuration to pull from storage. The servlet outputs either XML or
 AA JAR depending on the requested module and its script.

 AA So, you can just point the JBoss deployer to deploy a URL of the kind:

 AA myservlet/componentA/configX.jar
 AA or
 AA myservlet/serviceB/configY.xml
 AA and the servlet automatically generates properly configured jar or xml
 AA which the Deployer happily deploys.

 AA Jelly has many usages this is just what I could come up with.
 It would
 AA be more than adequate for what you need to do, but if you are
 AA dissatisfied with JBoss library dependency growth, then,
 Jelly is out of
 AA the picture.

 AA Alex Loubyansky wrote:
  Thanks, Anatoly. I'll check it. Also I thought about Velocity which
  looks similar to Jelly from your description, though I am not familiar
  with the last one.
 
  Could you, please, look at the following idea with XML/XSL, compare it
  with Jelly and give your opinion?
  - before transformation, each MBean's attribute is set as a
 parameter to
  the Transformer with Transformer.setParameter(...) with the name equal
  to the corresponding parameter name used in XSL stylesheet;
  - transform XML template with Transformer and XSL stylesheet.
 
  As for me, XML/XSL requires two templates (XML and XSL) while
  Jelly/Velocity requires only one.
 
  Also, I wouldn't add any thirdparty library unless it really
 helps. The
  JBoss becomes so heavy. I think it's problem.


 --
 Best regards,
  Alex Loubyansky




 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock

[noreply]

Bugs item #617574, was opened at 2002-10-02 07:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866

Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M Stark (starksm)
Summary: Classloader deadlock

Initial Comment:
We have for the third time in quite some weeks
experienced a partial lookup
of the JBoss server (some services responsive, others
not). The bug is not deterministically reproducible for us.
But this time we luckily had a debugger online and
drilled down
to what seems to be a classloader deadlock.

This was under NT4.0 (it happend before under W2000 also)
We used Branch_3_2 (checkout 12 hours before it went beta)
under JDK1.4.0-b92.

It happened when many separate ear-scoped mbeans
and dependent MDBs got deployed in a short time.
Many of the mbeans are JMSProviders and the MDBs
recieve external messages almost immediatelly after
startup, so they all try to load classes simultaneously.

Most of the threads were waiting for a lock at line 84
in the loadClass()
of HeirarchicalLoaderRepository2; only one threads was
locked
in loadClass() of  java.lang.ClassLoader.

The two threads which seem to have caused the deadlock were
Thread-47 (java.util.TimerThread) and
Thread Pool Worker-0 (EDU.oswego.blablaWorker),
both childs of the ThreadGroup ASF Session Pool Threads.

===
Thread-47 has the following trace:
loadClass() at line 84 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
loadClass() at line 262 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
===
Thread Pool Worker-0 has the following trace:
loadClass() at line 295 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
loadClass() at line 88 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
===

...so the deadlock seems evident. 


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 01:45

Message:
Logged In: YES 
user_id=175228

This was another variation on a lost notification. In this case 
an exception thrown from LoadMgr.beginLoadTask would 
bypass the call to LoadMgr.endLoadTask and leave a thread 
assigned as the owner of a UCL when it was not. If a load 
task was assigned to this thread an infinite wait could ensue 
if the assigned thread never loaded another class.

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-27 20:42

Message:
Logged In: YES 
user_id=175228

Enable tracing of the org.jboss.mx.loading category by 
adding a section like the following to the conf/log4j.xml file:

  category name=org.jboss.system
priority value=TRACE 
class=org.jboss.logging.XLevel/
  /category

and attach the log file of the TRACE level msgs.



--

Comment By: Stephen Coy (scoy)
Date: 2002-10-27 20:28

Message:
Logged In: YES 
user_id=463096

I've just refreshed my Branch_3_0 from cvs, cleaned and rebuilt, but the 
problem is still  there:

SocketListener-3 prio=5 tid=0x48620b0 nid=0x4811140 runnable 
[0xf0d99000..0xf0d9aba0]
at java.lang.Object.wait(Native Method)
at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader
3.java:152)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.beans.Introspector.instantiate(Introspector.java:1061)
at java.beans.Introspector.findInformant(Introspector.java:303)
at java.beans.Introspector.init(Introspector.java:251)
at java.beans.Introspector.getBeanInfo(Introspector.java:76)
at 
org.apache.struts.util.PropertyUtils.getPropertyDescriptors(PropertyUtils
.java:552)
at 
org.apache.struts.util.PropertyUtils.getPropertyDescriptor(PropertyUtils.j
ava:516)
at 
org.apache.struts.util.PropertyUtils.getSimpleProperty(PropertyUtils.java
:706)
at 
org.apache.struts.util.PropertyUtils.getNestedProperty(PropertyUtils.java
:426)
at 
org.apache.struts.util.PropertyUtils.getProperty(PropertyUtils.java:453)
at 
org.apache.struts.taglib.logic.CompareTagBase.condition(CompareTagB
ase.java:228)
at 
org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:90)
at 
org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(Conditiona
lTagBase.java:218)
at 
JspServ.online.workList.actionBar._jspService(actionBar.java:309)
at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 

Re[4]: [JBoss-dev] -service.xml generator

[Alex Loubyansky]

Yes. And by the way there are to ways.
The first is MBean persistence.
The second is changing the app's DDs themself.
As I understand right, Anatoly uses the last one.

alex

Monday, October 28, 2002, 11:46:57 AM, you wrote:

SL ... and making these changes persistent! ;)

SL Yes, that would be really cool

 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]De la part de Alex
 Loubyansky
 Envoye : lundi, 28 octobre 2002 10:03
 A : Anatoly Akkerman
 Objet : Re[2]: [JBoss-dev] -service.xml generator


 I am thinking about this stuff of reconfiguring and redeployment.
 It would be cool to have metadata of the deployed apps to be exposed
 for modifications through jmx-console. And not only for changing
 existing attributes but adding some resource references etc.
 Then one can modify some stuff and redeploy the app.

 alex

 Sunday, October 27, 2002, 4:07:15 PM, you wrote:

 AA Hi, Alex

 AA Jelly would give you similar ease of use but without having
 to write any
 AA XSL. You would initialize the JellyContext by creating in
 first and then
 AA setting variables in it from attributes like this:
 AA ctx.setVariable(name, value);

 AA (values can be any Java objects)

 AA you load your modified *-service.xml script from a URL into Jelly and
 AA run it as a script in the context which you just set up. The
 result of
 AA this operation is XML again.

 AA This is simplest usage of Jelly. You do need a library, though, and
 AA possibly, not one but a bunch from jakarta-commons.

 AA I am using Jelly in a slightly more advanced fashion. I wrote
 a few very
 AA simple tags that allow output of Jelly to be a jar file.
 Something like:
 AA j:jelly xmlns:j=jelly:core xmlns:zipper=jelly:mypackage.MyTagLib
 AA zipper:zip
 AA zipper:entry name=META-INF/ejb-jar.xml 
 AA parametrized ejb-jar.xml contents go here
 AA /zipper:entry
 AA zipper:entry name=META-INF/jboss.xml 
 AA parametrized jboss-xml contents go here
 AA /zipper:entry
 AA /zipper:zip
 AA /j:jelly

 AA Set up the JellyContext for running this script with appropriately
 AA configured variables (say from a DB of configurations or from
 attributes
 AA of an MBean). Run the script in the context.
 AA After running this script, the JellyContext contains a Jar
 archive (as a
 AA byte[] stored under some variable name) of reconfigured descriptors.

 AA The way I use it is to have a servlet that parses its path
 request and
 AA deduces from the path request which script to run and which
 AA configuration to pull from storage. The servlet outputs either XML or
 AA JAR depending on the requested module and its script.

 AA So, you can just point the JBoss deployer to deploy a URL of the kind:

 AA myservlet/componentA/configX.jar
 AA or
 AA myservlet/serviceB/configY.xml
 AA and the servlet automatically generates properly configured jar or xml
 AA which the Deployer happily deploys.

 AA Jelly has many usages this is just what I could come up with.
 It would
 AA be more than adequate for what you need to do, but if you are
 AA dissatisfied with JBoss library dependency growth, then,
 Jelly is out of
 AA the picture.

 AA Alex Loubyansky wrote:
  Thanks, Anatoly. I'll check it. Also I thought about Velocity which
  looks similar to Jelly from your description, though I am not familiar
  with the last one.
 
  Could you, please, look at the following idea with XML/XSL, compare it
  with Jelly and give your opinion?
  - before transformation, each MBean's attribute is set as a
 parameter to
  the Transformer with Transformer.setParameter(...) with the name equal
  to the corresponding parameter name used in XSL stylesheet;
  - transform XML template with Transformer and XSL stylesheet.
 
  As for me, XML/XSL requires two templates (XML and XSL) while
  Jelly/Velocity requires only one.
 
  Also, I wouldn't add any thirdparty library unless it really
 helps. The
  JBoss becomes so heavy. I think it's problem.


-- 
Best regards,
 Alex Loubyansky




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Upcoming releases

[Jules Gosnell]

Scott M Stark wrote:


I'm planning on the following releases so time your work accordingly:

2002-10-25jboss-2.4.10
2002-10-27jboss-3.0.4


Is the 3.0.4 release on ?

I haven't seen anything over the weekend indicating yes - but then I 
haven't seen a no either

Have I missed something somewhere ?


Jules

2002-11-03jboss-3.0.2beta2
2002-12-22jboss-4.0alpha


Scott Stark
Chief Technology Officer
JBoss Group, LLC



---
This sf.net email is sponsored by:
Access Your PC Securely with GoToMyPC. Try Free Now
https://www.gotomypc.com/s/OSND/DD
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
 






This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Upcoming releases

[Jules Gosnell]

A sudden rush of mail has answered my question for me.

Jules


Jules Gosnell wrote:


Scott M Stark wrote:


I'm planning on the following releases so time your work accordingly:

2002-10-25jboss-2.4.10
2002-10-27jboss-3.0.4


Is the 3.0.4 release on ?

I haven't seen anything over the weekend indicating yes - but then I 
haven't seen a no either

Have I missed something somewhere ?


Jules

2002-11-03jboss-3.0.2beta2
2002-12-22jboss-4.0alpha


Scott Stark
Chief Technology Officer
JBoss Group, LLC



---
This sf.net email is sponsored by:
Access Your PC Securely with GoToMyPC. Try Free Now
https://www.gotomypc.com/s/OSND/DD
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
 






This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development







This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: Re[4]: [JBoss-dev] -service.xml generator

[Matt Munz]

Alex  group,

  I've meant to add some MBean persistence docs, but haven't gotten to it
yet.  IMO, *-service.xml *is* a form of persistence.  It represents state of
the server that is present after server restart.  It is great, flexible,
easy to understand, etc., but with all due respect, not overly robust or
featureful as a persistence mechanism per se.

  The MBean persistence mechanism I've implemented includes a default
persistence engine that uses Object Streams (derived from an example in
Juha's JMX book).  As I've mentioned before, this should be supplemented
with XML and possibly JDBC versions.  Since an Object Stream is not
human-readible, I believe it provides a sub-optimal alternative for
persistence in this case.

  As I also mentioned previously, there are several places in the JBoss
codebase where text (de)serialization of MBeans occurs.  Notably, this
includes the *-service.xml reading and jmx-console writing parts of the
server.  One of the next steps to make MBean persistence widely usable is to
re-use this serialization code for the purpose of reading and writing MBean
info and MBean state XML.

  I believe that this code relies on the PropertyEditor mechanism -- a
solution which appears to be a good fit for the job.  I hope that someone
familiar with this code/process might jump into this work.  When appropriate
for my current work, I'll try to do this myself, but the opportunity may not
appear for a while.  In the meantime, I'm happy to answer any questions on
the subject...

  - Matt Munz

-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Alex
Loubyansky
Sent: Monday, October 28, 2002 3:26 AM
To: Sacha Labourey
Subject: Re[4]: [JBoss-dev] -service.xml generator


Hello Sacha,

I thought about it too. As alternative or other implementation of
MBean persistence. Though, I am not familiar with MBean persistence stuff
yet.
Are they meant to be serialized as java objects?
I think, having MBeans persisted in xml form is much better. Because I
can see what is persisted and change something manually.

alex

Monday, October 28, 2002, 10:06:36 AM, you wrote:

SL Hello,

SL Exactly, it may help to solve one of the current biggest issue wrt
SL configuration: any configuration done through any GUI (or mbean, etc.)
is
not persisted = only transient configuration can be started remotly or
SL programatically. Having a generic way to build new persisted mbean
SL definition is important.

SL But we spoke about this on this ML a few weeks ago and we still have
some
SL issues wrt implicit dependencies. Anyway, we need a way to persist
SL configuration that is currently only transient.

SL cheers,


SL Sacha

 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]De la part de Alex
 Loubyansky
 Envoye : lundi, 28 octobre 2002 07:17
 A : Anatoly Akkerman
 Objet : Re[2]: [JBoss-dev] -service.xml generator


 Anatoly, this looks cool and draws other perspectives. I'm in thought.

 Any other thoughts/comments?
 Thanks.

 alex

 Sunday, October 27, 2002, 4:07:15 PM, you wrote:

 AA Hi, Alex

 AA Jelly would give you similar ease of use but without having
 to write any
 AA XSL. You would initialize the JellyContext by creating in
 first and then
 AA setting variables in it from attributes like this:
 AA ctx.setVariable(name, value);

 AA (values can be any Java objects)

 AA you load your modified *-service.xml script from a URL into Jelly and
 AA run it as a script in the context which you just set up. The
 result of
 AA this operation is XML again.

 AA This is simplest usage of Jelly. You do need a library, though, and
 AA possibly, not one but a bunch from jakarta-commons.

 AA I am using Jelly in a slightly more advanced fashion. I wrote
 a few very
 AA simple tags that allow output of Jelly to be a jar file.
 Something like:
 AA j:jelly xmlns:j=jelly:core
xmlns:zipper=jelly:mypackage.MyTagLib
 AA zipper:zip
 AA zipper:entry name=META-INF/ejb-jar.xml 
 AA parametrized ejb-jar.xml contents go here
 AA /zipper:entry
 AA zipper:entry name=META-INF/jboss.xml 
 AA parametrized jboss-xml contents go here
 AA /zipper:entry
 AA /zipper:zip
 AA /j:jelly

 AA Set up the JellyContext for running this script with appropriately
 AA configured variables (say from a DB of configurations or from
 attributes
 AA of an MBean). Run the script in the context.
 AA After running this script, the JellyContext contains a Jar
 archive (as a
 AA byte[] stored under some variable name) of reconfigured descriptors.

 AA The way I use it is to have a servlet that parses its path
 request and
 AA deduces from the path request which script to run and which
 AA configuration to pull from storage. The servlet outputs either XML or
 AA JAR depending on the requested module and its 

[JBoss-dev] [ jboss-Patches-629903 ] fix for can't disable pass-by-reference

[noreply]

Patches item #629903, was opened at 2002-10-28 15:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376687aid=629903group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich Tong (rtong)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for can't disable pass-by-reference

Initial Comment:
I would like to submit a fix for bug that pass-by-reference 
optimization for intraVM invocation can't be disabled. This is 
for v3.2beta. The fix is described as following. Thanks.

1.for org.jboss.invocation.InvokerInterceptor
use the following for method invoke():

  public Object invoke(Invocation invocation)
  throws Exception
   {
  // optimize if calling another bean in same EJB-
application
  //RT: fix 
  InvocationContext context = 
invocation.getInvocationContext();
  Boolean intraVMOptimization = (Boolean)
context.getValue(Optimized);
  //by default, use optimization
  boolean optimized = (intraVMOptimization == null? true: 
intraVMOptimization.booleanValue());
  
  //allow user to turn off local optimization
  if (isLocal()  optimized) {
 // The payload as is is good
 return localInvoker.invoke(invocation);
  }
  else {
 // this payload will go through marshalling
 return invocation.getInvocationContext().getInvoker
().invoke(invocation);
  }   
   }

2.for org.jboss.proxy.ejb.ProxyFactory
(1)add a method

protected void setIntraVMOptimization(InvocationContext 
context) throws Exception{

  boolean optimized = 
MetaData.getOptionalChildBooleanContent
(invokerMetaData.getProxyFactoryConfig(), Optimized);

  context.setValue(Optimized, new Boolean(optimized));
}

(2)add codes to method 
 public Object getStatefulSessionEJBObject(Object id)
   {
  ...
  context.setInvokerProxyBinding
(invokerMetaData.getName());
  
 //RT: fix intraVM optimization problem
 try{
 setIntraVMOptimization(context);
 }catch(Exception e){
//do nothing
;
 }
  ...
}

(3)add codes to method
  public Object getEntityEJBObject(Object id)
   {
  ...
  context.setInvokerProxyBinding
(invokerMetaData.getName());

 //RT: fix intraVM optimization problem
 try{
 setIntraVMOptimization(context);
 }catch(Exception e){
//do nothing
;
 }
  ...
}

(4)add codes to method
  public Collection getEntityCollection(Collection ids)
   {
  ...
 context.setInvokerProxyBinding
(invokerMetaData.getName());
  
 //RT: fix intraVM optimization problem
 try{
 setIntraVMOptimization(context);
 }catch(Exception e){
//do nothing
;
 }
...
}

(5)add codes to method
 protected void bindProxy() throws Exception
   {
   ...
 context.setInvokerProxyBinding
(invokerMetaData.getName());
 
 //RT: to provide intra-VM optimization flag
 setIntraVMOptimization(context);
 ...
}

--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Patches-629915 ] fix for a potential bug in XmlFileLoader

[noreply]

Patches item #629915, was opened at 2002-10-28 15:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376687aid=629915group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich Tong (rtong)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for a potential bug in XmlFileLoader

Initial Comment:
in XmlFileLoader.java load() method, META-INF/ejb-
jar.xml and META-INF/jboss.xml are loaded by class 
loader's getResource() method. This could potentially 
retrieve the wrong files in the classpath. (It happened in my 
machine environment, which picks up another component's 
META-INF directory.) A simple fix would be use 
URLClassLoader.findResource() instead. Please see 
attached XmlFileLoader.java

--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] checkout jboss in eclipse

[Emerson Cargnin - SICREDI Serviços]

did anyone used jboss to checkout jboss??

I did it, in the jboss repository i choosed branch Branch_3_0 and module 
jboss-3.0

and when i try to executed through build.sh  i got :


~/eclipse/workspace/jboss-3.0/build ./build.sh
Searching for build.xml ...
Buildfile: /home/emersonc/eclipse/workspace/jboss-3.0/build/build.xml

BUILD FAILED
Error reading project file: unknown protocol: resource

Total time: 4 seconds


it looks like a problem in eclipse cvs...

--

| Emerson Cargnin  |
| Analista de Sistemas Sr. |
| Tel : (051) 3358-4959|
| SICREDI Serviços |
| Porto Alegre - Brasil|
|xx|



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] jboss-applications build problem

[Pavel Kolesnikov]

I've just found it builds with j2sdk 1.4 (my problems mentioned
below occured only with jdk 1.3).

If it's not intentional, could anyone who's more familiar
with the build system look at it and try to fix it (or say
it does work for him? :-)

Thanks

Pavel

On Thu, 24 Oct 2002, Pavel Kolesnikov wrote:

 On Tue, 22 Oct 2002, [iso-8859-1] julien viet wrote:
 
  basically you don't have to put anything in your
  classpath, jboss builds it ofr itself. try without.
  
  also checkout latest version.
 
 Still the some problem.
 
 I did
 
 $  cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/jboss co 
jboss-applications
 ...
 $ cd applications
 $ ./build/build.sh -Dmodules=forums
 build.sh: Executing: /home/koles/eclipse/tmp/applications/tools/bin/ant 
 -logger org.apache.tools.ant.NoBannerLogger -Dmodules=forums
 Buildfile: build.xml
 
 BUILD FAILED
 XML parser factory has not been configured correctly: Provider 
 org.apache.crimson.jaxp.SAXParserFactoryImpl not found
 
 Or
 
 $ ./forums/build.sh with the same result
 
 BTW when I checked out the original CVS module (just after it was 
 created), the same problem occured, but I solved it by putting 
 tools/lib*.jar.
 
 Thanks,
 
 Pavel
  
   --- Pavel Kolesnikov [EMAIL PROTECTED] a crit:  Hello,
   
   I've checked out jboss-applications module from CVS,
   put all jars from jboss-applications/tools/lib/
   including
   crimson.jar into my CLASSPATH, but build.sh tells
   me:
   
 $ ./build.sh
 build.sh: Executing: 

  
  /home/koles/eclipse/workspace/jboss-applications/tools/bin/ant
   -logger 
 org.apache.tools.ant.NoBannerLogger
 Buildfile: build.xml
   
 BUILD FAILED
 XML parser factory has not been configured
   correctly: Provider 
   org.apache.crimson.jaxp.SAXParserFactoryImpl not
   found
   
   Does anybody have an idea what I am doing wrong? 
   
   The version I've checked out before Jason's CVS
   changes works
   OK, but I can't say if there's any connection or if
   it's just coincidence.
   
   I'm using JDK 1.3.1_04 on RedHat 7.3
   
   Thanks for any suggestions.
   
   Pavel
   
   
   
   
   
  
  ---
   This sf.net emial is sponsored by: Influence the
   future of 
   Java(TM) technology. Join the Java Community
   Process(SM) (JCP(SM)) 
   program now.
   http://ad.doubleclick.net/clk;4699841;7576301;v?
   http://www.sun.com/javavote
   ___
   Jboss-development mailing list
   [EMAIL PROTECTED]
  
  https://lists.sourceforge.net/lists/listinfo/jboss-development 
  
  ___
  Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en franais !
  Yahoo! Mail : http://fr.mail.yahoo.com
  
  
  ---
  This sf.net emial is sponsored by: Influence the future 
  of Java(TM) technology. Join the Java Community 
  Process(SM) (JCP(SM)) program now. 
  http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
  
 
 
 
 
 ---
 This sf.net email is sponsored by: Influence the future 
 of Java(TM) technology. Join the Java Community 
 Process(SM) (JCP(SM)) program now. 
 http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Feature Requests-630002 ] PLEASE UPDATE HYPERSONIC DB

[noreply]

Feature Requests item #630002, was opened at 2002-10-28 20:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376688aid=630002group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Maxim (kimerinn)
Assigned to: Nobody/Anonymous (nobody)
Summary: PLEASE UPDATE HYPERSONIC DB

Initial Comment:
Guys, old version of Hypersonic Db that is bundled with
JBoss contains serious bug. It can't store fields
larger than 64 Kb. Please update it with the latest
release 1.7.1 that works correctly. I tried to change
the old hsqldb.jar with the new one, but JBoss crashed 
( java.lang.NoClassDefFoundError:
org/hsqldb/Embedded_Server )
I have not enough time to manually configure JBoss for
new hypersonic.
Please, update hypersonic database
(http://hsqldb.sourceforge.net/).

Kimerinn.

--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re[2]: [JBoss-dev] -service.xml generator

[Alex Loubyansky]

Hello David,

DJ how does what you want differ from the *-ds.xml deployer in 3.2 and 4?

just dealing with JMX agent view and not XML files. I think, it
would be easier, especially to start, to use some GUI instead of XML.
I am not talking about datasources only. Do you really think it's an overlap?

DJ It uses a chainable xsl-sub-deployer that transforms dd's on the fly.  I
DJ suspect there is considerable overlap with the foe-deployer transformation
DJ stuff.

Not yet. It just transforms DDs and doesn't generate/setup other services
like datasources, connection factories and so on.

Thanks.

alex

DJ david jencks

DJ On 2002.10.26 09:11:31 -0400 Alex Loubyansky wrote:
 I am thinking about writting an MBean that will generate *-service.xml
 files 
 for datasources.
 I see it the following way.
 - MBean attributes corresponding to values needed to construct
 -service.xml 
 (such as url, driver, user, password, etc);
 - XML template with dummy/default values;
 - XSL stylesheet similar to what David wrote for -ds.xml;
 - managed operation 'generate' that will transform XML template,
 probably, 
 mostly substituting dummy values with managed attribute values.
 
 Actually, I am looking for a nice way to configure datasources in
 FoeDeployer 
 but I think it could be useful behind it.
 Also the same way any -service.xml file can be generated.
 
 Any thoughts?
 Thanks.


-- 
Best regards,
 Alex Loubyansky




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-620890 ] Struts with JBoss 3.0.3_Tomcat_4.1.12

[noreply]

Bugs item #620890, was opened at 2002-10-09 10:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=620890group_id=22866

Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Theo Harper (btharper)
Assigned to: Scott M Stark (starksm)
Summary: Struts with JBoss 3.0.3_Tomcat_4.1.12

Initial Comment:
JBoss-3.0.3_Tomcat-4.1.12 does to allow a WAR file to 
be deployed that uses the Struts 1.1b2.

For example, try deploying the 
http://jakarta.apache.org/builds/jakarta-
struts/release/v1.1-b2/jakarta-struts-1.1-b2-blank.war 
causes a ClassNotFoundException (XmlDefinition) when 
reading tiles-defs.xml.

Deploying this with JBoss3.0.2_Tomcat-4.0.4 works 
okay. 

Deploying to a vanilla Tomcat4.1.12 (downloaded from 
jakarta.apache.org) works okay.

It looks like the class loader used by common-digester 
is not the one created from WEB-INF/classes and WEB-
INF/lib but the classes loader common-digester was 
loaded from.  Commons-digester has the option to use 
the thread context class loader but this is not enabled.



--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 11:26

Message:
Logged In: YES 
user_id=175228

The struts layer has to allow the Digester to use the thread 
context class loader. Tomcat-4.0.4 does not use the 
common-digester package and so in this case the WEB-
INF/lib version is used and the Digester class loader is the 
web app class loader. Report this a problem in the 
configuration of struts. You need to be able to specify that 
the thread context class loader is used to create objects.

Alternatively you could enable the servlet 2.3 class loading 
model that loads classes from the web app before the parent 
by setting the Java2ClassLoadingCompliance attribute to 
false as shown here:

 mbean 
code=org.jboss.web.catalina.EmbeddedCatalinaService41
   name=jboss.web:service=EmbeddedCatalina41
   attribute 
name=Java2ClassLoadingCompliancefalse/attribute
...


--

Comment By: Halil-C. Gürsoy (che---)
Date: 2002-10-17 03:32

Message:
Logged In: YES 
user_id=455149

Hi Folks,

after i have copied all JAR's (commons-...) from the lib-Dir
in the struts-validator.war into the the lib directory from
my default config i was able to deploy
jakarta-struts-1.1-b2-blank.war and the exampels without any
further problems in JB 3.0.3/TC 4.1.12

With should work as a qd workaround until this is fixed.



--

Comment By: Theo Harper (btharper)
Date: 2002-10-09 12:20

Message:
Logged In: YES 
user_id=73492

I have found commons-digester in jboss-3.0.3_tomcat-
4.1.12/tomcat-4.1.x/server/lib/commons-digester.jar.

It's getting loaded up when the tomcat service starts.

--

Comment By: Theo Harper (btharper)
Date: 2002-10-09 12:11

Message:
Logged In: YES 
user_id=73492

It seems that the Digester is getting loaded by a classLoader 
not associated with the WebApp, the WebappClassLoader is 
not being called when new 
org.apache.commons.digester.Digester() is executed (I 
assume something has loaded it already).

This means the classLoader used by the Digester only has 
itself on its classpath.

I have attached some output that might help ...



--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] checkout jboss in eclipse

[Jason Dillon]

The 3.0 build system will not work out of the box.  You can probably hackup 
your environment to get it to work, or you can use the build.[sh|bat] 
scripts.

--jason


On Mon, 28 Oct 2002, Emerson Cargnin - SICREDI Serviços wrote:

 did anyone used jboss to checkout jboss??
 
 I did it, in the jboss repository i choosed branch Branch_3_0 and module 
 jboss-3.0
 
 and when i try to executed through build.sh  i got :
 
 
 ~/eclipse/workspace/jboss-3.0/build ./build.sh
 Searching for build.xml ...
 Buildfile: /home/emersonc/eclipse/workspace/jboss-3.0/build/build.xml
 
 BUILD FAILED
 Error reading project file: unknown protocol: resource
 
 Total time: 4 seconds
 
 
 it looks like a problem in eclipse cvs...
 
 



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Is the testsuite not working - or is it just me?

[Chris Kimpton]

Hi,

I am trying to track this down - but I am not getting anywhere - can
someone point me at the buildmagic docs - I thought it was on the
jboss site - but I can't find it.

What does this execmlodules task require?  It was working before the
recent changes.

I could just hardcode the call - its not like this task is generic
anyway...

Chris


--- Chris Kimpton [EMAIL PROTECTED] wrote:
 Hi,
 
 I get this error:
 
 run-testsuite:
 [execmodules] Missing build file; skipping module: testsuite
 
 when using target testsuite in the build directory.
 
 Has this target/directory changed too?
 
 Thanks,
 Chris
 


=


__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-626893 ] Suggestion to CMP (relations read-ahead)

[noreply]

Bugs item #626893, was opened at 2002-10-22 12:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=626893group_id=22866

Category: JBossCMP
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 8
Submitted By: Emerson Cargnin (echofloripa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Suggestion to CMP (relations read-ahead)

Initial Comment:
I have a suggestion regarding to CMP : why not create a
configuration to a find method to allow the container
to load the relationships of a bean?

This could be useful in the cases you have to read all
the beans(or a good amount of then) and all (or almost
all) relationships of them. eg : in a report you will
have a sql to finding the pk's, one (at least) to load
the bean data and one sql to each relation you have to
report (for each bean).

I think that one of the worse problem with CMP is that
: database overhead. CMP generates too much sql
commands that in some cases could be handled by fewer
(if not one) sql commands. The DBA's in my company
didn't like very much the trace they saw in the
database for a very simple app.


--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] checkout jboss in eclipse

[Emerson Cargnin - SICREDI Serviços]

i'm using the build.sh as you can see in my previous email.
the problem is when checking-out using eclipse or using command line cvs 
commands. In the last it work nice, but in eclipse it doens't. I'd like 
to use eclipse so i can do a synchronize looking exacly what have change 
from builds to builds.

Jason Dillon wrote:
The 3.0 build system will not work out of the box.  You can probably hackup 
your environment to get it to work, or you can use the build.[sh|bat] 
scripts.

--jason


On Mon, 28 Oct 2002, Emerson Cargnin - SICREDI Serviços wrote:


did anyone used jboss to checkout jboss??

I did it, in the jboss repository i choosed branch Branch_3_0 and module 
jboss-3.0

and when i try to executed through build.sh  i got :


~/eclipse/workspace/jboss-3.0/build ./build.sh
Searching for build.xml ...
Buildfile: /home/emersonc/eclipse/workspace/jboss-3.0/build/build.xml

BUILD FAILED
Error reading project file: unknown protocol: resource

Total time: 4 seconds


it looks like a problem in eclipse cvs...






---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




--

| Emerson Cargnin  |
| Analista de Sistemas Sr. |
| Tel : (051) 3358-4959|
| SICREDI Serviços |
| Porto Alegre - Brasil|
|xx|



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols in SELECT clause

[noreply]

Bugs item #591835, was opened at 2002-08-06 22:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=591835group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Dain Sundstrom (dsundstrom)
Summary: Include ORDER BY cols in SELECT clause

Initial Comment:
Some databases, Oracle in particular, require that columns named 
in an ORDER BY clause be included in the SELECT clause when 
SELECT DISTINCT is used.

Here is some text from current Oracle documentation:

Restrictions on the order_by_clause:

*   If you have specified the DISTINCT operator in this statement, 
then this clause cannot refer to columns unless they appear in the 
select list.

*   An order_by_clause can contain no more than 255 expressions.


This can be worked around using on-find loading with load groups, 
but it sure would be useful if JBoss managed it for us.



--

Comment By: Emerson Cargnin (echofloripa)
Date: 2002-10-28 17:57

Message:
Logged In: YES 
user_id=378942

the workaround is useless if I use a dynamic-ql, correct me
if I'm wrong

--

Comment By: Emerson Cargnin (echofloripa)
Date: 2002-10-15 16:23

Message:
Logged In: YES 
user_id=378942

For oracle users, this is really a showstopper bug. I'll try
to undertand to (maybe) try to solve that : ) obs: i think
it'll take too long to me to take this : )

--

Comment By: Dain Sundstrom (dsundstrom)
Date: 2002-08-23 22:00

Message:
Logged In: YES 
user_id=251431

This is really a bug.  

--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-620440 ] Hot deploy DeploymentException

[noreply]

Bugs item #620440, was opened at 2002-10-08 13:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=620440group_id=22866

Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Don Laidlaw (dlaidlaw)
Assigned to: Scott M Stark (starksm)
Summary: Hot deploy DeploymentException

Initial Comment:
jboss 3.0.3 with tomcat 4.1.12 bundle
Windows XP, 2000, NT
Java 1.3.1_03 and 4.1.1
Happening on combinations of the above!

I am hot deploying an ear file, everwriting the existing 
one of the same name in the deploy directory.

The undeploy is throwing the exception as it undeploys 
the war part of the ear. Undeploys the ejb part just fine.



2002-10-07 20:00:22,035 INFO 
[org.jboss.deployment.MainDeployer] Undeploying 
file:/C:/Java/jboss/server/eBuy/deploy/eBuy.ear
2002-10-07 20:00:22,045 INFO 
[org.jboss.ejb.EjbModule] Stopping
2002-10-07 20:00:22,075 INFO 
[org.jboss.ejb.EjbModule] Stopped
2002-10-07 20:00:22,075 INFO 
[org.jboss.web.catalina.EmbeddedCatalinaService41] 
undeploy, ctxPath=/eBuy, 
warUrl=file:/C:/Java/jboss/server/eBuy/tmp/deploy/server/
eBuy/deploy/eBuy.ear/91.eBuy.ear-contents/eBuy-
web.war
2002-10-07 20:00:22,085 INFO 
[org.jboss.web.localhost.Engine] StandardHost
[localhost]: Removing web application at context 
path /eBuy
2002-10-07 20:00:22,165 ERROR 
[org.jboss.deployment.MainDeployer] Undeployment 
failed: 
file:/C:/Java/jboss/server/eBuy/tmp/deploy/server/eBuy/d
eploy/eBuy.ear/91.eBuy.ear-contents/eBuy-web.war
org.jboss.deployment.DeploymentException: Error 
during deploy; - nested throwable: 
(java.lang.NullPointerException)
at org.jboss.web.AbstractWebContainer.stop
(AbstractWebContainer.java:355)
at org.jboss.deployment.MainDeployer.stop
(MainDeployer.java:469)
at org.jboss.deployment.MainDeployer.stop
(MainDeployer.java:481)
at org.jboss.deployment.MainDeployer.undeploy
(MainDeployer.java:443)
at org.jboss.deployment.MainDeployer.undeploy
(MainDeployer.java:438)
at org.jboss.deployment.MainDeployer.undeploy
(MainDeployer.java:411)
at java.lang.reflect.Method.invoke(Native Method)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy4.undeploy(Unknown Source)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.
undeploy(URLDeploymentScanner.java:457)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.
scan(URLDeploymentScanner.java:552)
at 
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.doScan
(AbstractDeploymentScanner.java:212)
at 
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.loop
(AbstractDeploymentScanner.java:225)
at 
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.run
(AbstractDeploymentScanner.java:202)
+ nested throwable: 
java.lang.NullPointerException
at org.jboss.util.file.Files.delete(Files.java:39)
at 
org.jboss.web.catalina.EmbeddedCatalinaService41.perfo
rmUndeploy(EmbeddedCatalinaService41.java:330)
at org.jboss.web.AbstractWebContainer.stop
(AbstractWebContainer.java:345)
at org.jboss.deployment.MainDeployer.stop
(MainDeployer.java:469)
at org.jboss.deployment.MainDeployer.stop
(MainDeployer.java:481)
at org.jboss.deployment.MainDeployer.undeploy
(MainDeployer.java:443)
at org.jboss.deployment.MainDeployer.undeploy
(MainDeployer.java:438)
at org.jboss.deployment.MainDeployer.undeploy
(MainDeployer.java:411)
at java.lang.reflect.Method.invoke(Native Method)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy4.undeploy(Unknown Source)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.
undeploy(URLDeploymentScanner.java:457)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.
scan(URLDeploymentScanner.java:552)
at 
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.doScan
(AbstractDeploymentScanner.java:212)
at 
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.loop
(AbstractDeploymentScanner.java:225)
at 
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.run
(AbstractDeploymentScanner.java:202)
2002-10-07 20:00:22,406 INFO 
[org.jboss.deployment.EARDeployer] Undeploying J2EE 
application, destroy step: 
file:/C:/Java/jboss/server/eBuy/deploy/eBuy.ear
2002-10-07 20:00:22,416 INFO 
[org.jboss.ejb.EjbModule] Destroying
2002-10-07 20:00:22,446 INFO 
[org.jboss.ejb.EjbModule] Remove JSR-77 EJB Module: 
jboss.management.single:J2EEApplication=eBuy.ear,J2
EEServer=Single,j2eeType=EJBModule,name=eBuy-
ejb.jar
2002-10-07 20:00:22,456 INFO 
[org.jboss.ejb.EjbModule] Destroyed
2002-10-07 20:00:22,466 INFO 
[org.jboss.deployment.MainDeployer] not deleting 
localUrl, it is null or not 

[JBoss-dev] [ jboss-Bugs-471714 ] getPrimaryKey() on a session bean

[noreply]

Bugs item #471714, was opened at 2001-10-16 06:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=471714group_id=22866

Category: None
Group: v2.4 (stable)
Status: Closed
Resolution: Later
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Scott M Stark (starksm)
Summary: getPrimaryKey() on a session bean

Initial Comment:
Calling getPrimaryKey() on a session bean should 
result in java.rmi.RemoteException, as specified in 
the EJB1.1 spec, par 5.8.3.


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 12:07

Message:
Logged In: YES 
user_id=175228

Who cares?

--

Comment By: Scott M Stark (starksm)
Date: 2001-10-18 17:59

Message:
Logged In: YES 
user_id=175228

This is due to the current implementation of the equals 
operation which is performed on the client. The 
StatelessSessionProxy and 
StatefulSessionProxy implementations need to be updated to 
not base equals() on the getPrimaryKey method.



--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] checkout jboss in eclipse

[Jason Dillon]

Send me the output from `find ~/eclipse/workspace/jboss-3.0/tools`

--jason


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:jboss-
 [EMAIL PROTECTED]] On Behalf Of Emerson Cargnin
-
 SICREDI Serviços
 Sent: Monday, October 28, 2002 10:57 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] checkout jboss in eclipse
 
 i'm using the build.sh as you can see in my previous email.
 the problem is when checking-out using eclipse or using command line
cvs
 commands. In the last it work nice, but in eclipse it doens't. I'd
like
 to use eclipse so i can do a synchronize looking exacly what have
change
 from builds to builds.
 
 Jason Dillon wrote:
  The 3.0 build system will not work out of the box.  You can probably
 hackup
  your environment to get it to work, or you can use the
build.[sh|bat]
  scripts.
 
  --jason
 
 
  On Mon, 28 Oct 2002, Emerson Cargnin - SICREDI Serviços wrote:
 
 
 did anyone used jboss to checkout jboss??
 
 I did it, in the jboss repository i choosed branch Branch_3_0 and
module
 jboss-3.0
 
 and when i try to executed through build.sh  i got :
 
 
 ~/eclipse/workspace/jboss-3.0/build ./build.sh
 Searching for build.xml ...
 Buildfile:
/home/emersonc/eclipse/workspace/jboss-3.0/build/build.xml
 
 BUILD FAILED
 Error reading project file: unknown protocol: resource
 
 Total time: 4 seconds
 
 
 it looks like a problem in eclipse cvs...
 
 
 
 
 
 
  ---
  This sf.net email is sponsored by:ThinkGeek
  Welcome to geek heaven.
  http://thinkgeek.com/sf
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 --
 
 | Emerson Cargnin  |
 | Analista de Sistemas Sr. |
 | Tel : (051) 3358-4959|
 | SICREDI Serviços |
 | Porto Alegre - Brasil|
 |xx|
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Oracle, table locks and CMP2 incompatibility

[Michael Bartmann]

Hallo db gurus,

we have for some time experienced nasty timeouts on oracle
without jboss deadlock detection (or oracle deadlock detection)
kicking in. We might have found the solution today, allthough
this is not verified, perhaps only time will show.
(...or some db guru will tell me that my following explanation is
severly misguided.)

The EJB locking is based on entity locks. If you have an underlying
database which does locking too, it has to use row level locking,
(as opposed to table level locking) or else jboss detect deadlocks
on the database, as the check which detects deadlocks is based on a
graph representing locks on entity (row) level.

But there are circumstances, under which oracle does not use row
level locking even if with row level locking configured to always.

This happens when a table TableA has a dependent table TableB in a
1:n relationship (i.e. TableB has a foreign key pointing to TableA.)
If a row of TableA gets updated, oracle tries to lock all entries in
TableB with matching foreign key.

Here comes the vital point: If there is no index on the foreign key
columns of TableB, oracle does a shared lock on _table_ level. This
is probably because otherwise oracle would need to do a full table
scan on the fly to find the matching rows in TableB.

So if you configure jboss to generate the foreign key constraints
you are walking on thin ice; you have to generate indices on the
foreign key columns by hand, or else this effect might hount you.

Solution:
1) [workaround] disable foreign key (or their generation), and let
   CMP2 itself take care of the constraints
or
2) implement generation of foreign key indices in jboss. (I'm not fully
   convinced that this would suffice; jboss deadlock detection would
   have to lock the same entities and avoid race conditions).

Does this sound reasonable to you?

Regards,
Michael Bartmann



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Oracle, table locks and CMP2 incompatibility

[Catalin Teodorescu]

Check this link.

http://asktom.oracle.com/pls/ask/f?p=4950:8:1513219::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:292016138754,%7Bprimary%7D%20and%20%7Bkey%7D%20and%20%7Bupdate%7D%20and%20%7Btable%7D%20and%20%7Block%7D


Dan

-Original Message-
From: Michael Bartmann [mailto:michael.bartmann;lisytec.de]
Sent: Monday, October 28, 2002 12:21 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Oracle, table locks and CMP2 incompatibility


Hallo db gurus,

we have for some time experienced nasty timeouts on oracle
without jboss deadlock detection (or oracle deadlock detection)
kicking in. We might have found the solution today, allthough
this is not verified, perhaps only time will show.
(...or some db guru will tell me that my following explanation is
severly misguided.)

The EJB locking is based on entity locks. If you have an underlying
database which does locking too, it has to use row level locking,
(as opposed to table level locking) or else jboss detect deadlocks
on the database, as the check which detects deadlocks is based on a
graph representing locks on entity (row) level.

But there are circumstances, under which oracle does not use row
level locking even if with row level locking configured to always.

This happens when a table TableA has a dependent table TableB in a
1:n relationship (i.e. TableB has a foreign key pointing to TableA.)
If a row of TableA gets updated, oracle tries to lock all entries in
TableB with matching foreign key.

Here comes the vital point: If there is no index on the foreign key
columns of TableB, oracle does a shared lock on _table_ level. This
is probably because otherwise oracle would need to do a full table
scan on the fly to find the matching rows in TableB.

So if you configure jboss to generate the foreign key constraints
you are walking on thin ice; you have to generate indices on the
foreign key columns by hand, or else this effect might hount you.

Solution:
1) [workaround] disable foreign key (or their generation), and let
CMP2 itself take care of the constraints
or
2) implement generation of foreign key indices in jboss. (I'm not fully
convinced that this would suffice; jboss deadlock detection would
have to lock the same entities and avoid race conditions).

Does this sound reasonable to you?

Regards,
Michael Bartmann



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols in SELECTclause

[Emerson Cargnin - SICREDI Serviços]

if you read carefully the above bug  you will see that it's a oracle 
issue, the solution here will not generate any orderby, but when it's 
used (jboss-ql order by) it uses the fields in orderby clause in the 
select [fiels] where ...

Hunter Hillegas wrote:
Will this be something that is configurable per datasource type or mandated
in JBossCMP as the default? Will there be any way to tell JBoss *not* to add
these order bys in the event we don't want them?

Hunter



From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Oct 2002 11:57:13 -0800
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols in SELECT
clause

Bugs item #591835, was opened at 2002-08-06 22:46
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=591835group_id=2
2866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Dain Sundstrom (dsundstrom)
Summary: Include ORDER BY cols in SELECT clause

Initial Comment:
Some databases, Oracle in particular, require that columns named
in an ORDER BY clause be included in the SELECT clause when
SELECT DISTINCT is used.

Here is some text from current Oracle documentation:

Restrictions on the order_by_clause:

*If you have specified the DISTINCT operator in this statement,
then this clause cannot refer to columns unless they appear in the
select list.

*An order_by_clause can contain no more than 255 expressions.


This can be worked around using on-find loading with load groups,
but it sure would be useful if JBoss managed it for us.



--

Comment By: Emerson Cargnin (echofloripa)
Date: 2002-10-28 17:57

Message:
Logged In: YES 
user_id=378942

the workaround is useless if I use a dynamic-ql, correct me
if I'm wrong

--

Comment By: Emerson Cargnin (echofloripa)
Date: 2002-10-15 16:23

Message:
Logged In: YES 
user_id=378942

For oracle users, this is really a showstopper bug. I'll try
to undertand to (maybe) try to solve that : ) obs: i think
it'll take too long to me to take this : )

--

Comment By: Dain Sundstrom (dsundstrom)
Date: 2002-08-23 22:00

Message:
Logged In: YES 
user_id=251431

This is really a bug.

--

You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=591835group_id=2
2866


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




--

| Emerson Cargnin  |
| Analista de Sistemas Sr. |
| Tel : (051) 3358-4959|
| SICREDI Serviços |
| Porto Alegre - Brasil|
|xx|



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 28-October-2002

[scott . stark]

Number of tests run:   984



Successful tests:  982
Errors:1
Failures:  1



[time of test: 28 October 2002 12:55 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2.1]

See http://lubega.com/testarchive/${build.uid} for details of this test.

See http://lubega.com for general test information.

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!





Oh dear - still got some errors!



Thanks for all your effort - we really do love you!




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-589808 ] EJB Jars already deployed by MANIFEST.MF

[noreply]

Bugs item #589808, was opened at 2002-08-01 20:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=589808group_id=22866

Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB Jars already deployed by MANIFEST.MF

Initial Comment:
It is currently impossible to use auxiliary code 
belonging to one EJB Jar EJB1.jar in another EJB Jar, 
EJB2.jar.

This problem arises now when (finally, after a few wronly 
claimed closures) the handling of dependent Jars, 
through MANIFEST.MF, really looks in the right 
directory (it used to look in EJB2.jar itself, no good...)

Since JBoss does not make a clear distinction between 
EJB-deployments and regular JAR-deployments, the 
deployment of EJB1.jar fails with an error: 

javax.management.InstanceAlreadyExistsException: 
blah,blah,blah (no this is not important, since the 
problem is very clearly defined)...-contents/EJB1.jar 
already registered.

I.e., the MANIFEST.MF-deployment process beats the 
regular EJB-deployer to the EJB1.jar.

We can also bypass this problem by enforcing ALL 
auxiliary code to be put in non-EJB Jars, but would it not 
be nicer to be able to deploy any J2EE-compliant 
application.

So, we (I am not an active member) have to either (1) 
differentiate between real deployment (e.g. EJBs) and 
MANIFEST-dependent deployments, or (2) be silent 
when we encounter a MANIFEST-deployed module 
again.

Thanks for a great product!

--

Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 21:05

Message:
Logged In: YES 
user_id=71283

Does anybody with a good enough knowledge of JBoss have the
bandwidth to fix this bug? It is a pretty serious
non-compliance with the J2EE 1.3 spec, which makes it a big
pain sometimes to deploy third party EJBs without having to
do modifications on them.

Given that the spec says this behaviour should be allowed,
that should completely be the end of the argument. Even if
as mentioned previously (by Scott), it is possible in your
own projects to set up your beans so they don't have
manifest classpath references to jars containing other beans
(and forcing the current JBOSS code to try to redploy thos
other beans again), a number of 3rd party EJBs do include
such references. To use these EJBs I now have to go into
them and modify the entries.

What is interesting (and relevant) is that if the
application is not deployed as an ear but rather as an
exploded directory version of that ear, the problem does not
happen.  If it can work properly for exploded ears, what is
the issue with normal ears?

Regards,

Colin


--

Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-02 17:04

Message:
Logged In: NO 

My post of 2002-10-02 09:57 refers to JBoss version 3.0.2.
Cheers, Matt

--

Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-02 16:57

Message:
Logged In: NO 

I've come across the same problem (I think). I have a 3rd
party supplied JAR, up.jar, which contains client code *and*
EJB code including the ejb-jar.xml deployment descriptor.

I've have listed up.jar in my WAR's manifest classpath. Both
the WAR and up.jar are packaged in an EAR. The
application.xml only defines the WAR as a module.

As JBoss deploys the WAR, the EJBs in up.jar are also
getting deployed even though the application.xml does not
list up.jar as an EJB module.

I would expect *only* the modules explicitly defined in
application.xml to get deployed but it seems that anything
that looks even vaguely deployable is getting deployed.

--

Comment By: David Bergman (davber)
Date: 2002-08-01 21:47

Message:
Logged In: YES 
user_id=395691

The situation of having code in one EJB jar being used by the 
code in another EJB jar in the manner described is obviously 
a bit contrived, and one should clearly put auxiliary classes 
in a separate jar file, just as you suggested.

However, I have not seen that restriction in the J2EE specs, 
but instead seen the phrase Any deployment descriptors in 
references .jar files are ignored when processing the 
referencing .jar file. This phrase not only suggests that it 
indead is possible, according to specs, to have an EJB jar in 
the MANIFEST ClassPath, but also that the current full-
fledged nested deployment of JBoss is wrong.

Am still waiting for you to show me my mistake. It is better 
for everyone if we do not assume people to be wrong from the 
start...

The current behavior of failing to deploy in this case is simply 
wrong. It is easy to fix in the current implementation, though.

Thanks,

David

--

Comment By: David Bergman (davber)

Re: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols in SELECTclause

[Dain Sundstrom]

Agreed.  This should be a flag in the datasource mapping.

-dain

Hunter Hillegas wrote:

I saw that it was Oracle specific, but I didn't see it mentioned that it
only kicked in when using the JBoss-QL order-by.

Also, I still think it would be useful to have it only kick in for databases
that require it... The behavior required by Oracle isn't part of the SQL
spec is it?

Hunter



From: Emerson Cargnin - SICREDI Serviços [EMAIL PROTECTED]
Organization: SICREDI
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Oct 2002 17:57:24 -0200
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols in SELECT
clause

if you read carefully the above bug  you will see that it's a oracle
issue, the solution here will not generate any orderby, but when it's
used (jboss-ql order by) it uses the fields in orderby clause in the
select [fiels] where ...

Hunter Hillegas wrote:


Will this be something that is configurable per datasource type or mandated
in JBossCMP as the default? Will there be any way to tell JBoss *not* to add
these order bys in the event we don't want them?

Hunter




From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Oct 2002 11:57:13 -0800
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols in SELECT
clause

Bugs item #591835, was opened at 2002-08-06 22:46
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=591835group_id
=2
2866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Dain Sundstrom (dsundstrom)
Summary: Include ORDER BY cols in SELECT clause

Initial Comment:
Some databases, Oracle in particular, require that columns named
in an ORDER BY clause be included in the SELECT clause when
SELECT DISTINCT is used.

Here is some text from current Oracle documentation:

Restrictions on the order_by_clause:

*If you have specified the DISTINCT operator in this statement,
then this clause cannot refer to columns unless they appear in the
select list.

*An order_by_clause can contain no more than 255 expressions.


This can be worked around using on-find loading with load groups,
but it sure would be useful if JBoss managed it for us.



--

Comment By: Emerson Cargnin (echofloripa)
Date: 2002-10-28 17:57

Message:
Logged In: YES 
user_id=378942

the workaround is useless if I use a dynamic-ql, correct me
if I'm wrong

--

Comment By: Emerson Cargnin (echofloripa)
Date: 2002-10-15 16:23

Message:
Logged In: YES 
user_id=378942

For oracle users, this is really a showstopper bug. I'll try
to undertand to (maybe) try to solve that : ) obs: i think
it'll take too long to me to take this : )

--

Comment By: Dain Sundstrom (dsundstrom)
Date: 2002-08-23 22:00

Message:
Logged In: YES 
user_id=251431

This is really a bug.

--

You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=591835group_id
=2
2866


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




--

| Emerson Cargnin  |
| Analista de Sistemas Sr. |
| Tel : (051) 3358-4959|
| SICREDI Serviços |
| Porto Alegre - Brasil|
|xx|



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



--

Dain Sundstrom
Chief Architect JBossCMP
JBoss Group, LLC




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: [JBoss-dev] Is the testsuite not working - or is it just me?

[Jason Dillon]

What is the problem?

--jason


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:jboss-
 [EMAIL PROTECTED]] On Behalf Of Chris Kimpton
 Sent: Monday, October 28, 2002 11:35 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Is the testsuite not working - or is it just
me?
 
 Hi,
 
 I am trying to track this down - but I am not getting anywhere - can
 someone point me at the buildmagic docs - I thought it was on the
 jboss site - but I can't find it.
 
 What does this execmlodules task require?  It was working before the
 recent changes.
 
 I could just hardcode the call - its not like this task is generic
 anyway...
 
 Chris
 
 
 --- Chris Kimpton [EMAIL PROTECTED] wrote:
  Hi,
 
  I get this error:
 
  run-testsuite:
  [execmodules] Missing build file; skipping module: testsuite
 
  when using target testsuite in the build directory.
 
  Has this target/directory changed too?
 
  Thanks,
  Chris
 
 
 
 =
 
 
 __
 Do you Yahoo!?
 Y! Web Hosting - Let the expert host your web site
 http://webhosting.yahoo.com/
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-589808 ] EJB Jars already deployed by MANIFEST.MF

[noreply]

Bugs item #589808, was opened at 2002-08-01 16:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=589808group_id=22866

Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB Jars already deployed by MANIFEST.MF

Initial Comment:
It is currently impossible to use auxiliary code 
belonging to one EJB Jar EJB1.jar in another EJB Jar, 
EJB2.jar.

This problem arises now when (finally, after a few wronly 
claimed closures) the handling of dependent Jars, 
through MANIFEST.MF, really looks in the right 
directory (it used to look in EJB2.jar itself, no good...)

Since JBoss does not make a clear distinction between 
EJB-deployments and regular JAR-deployments, the 
deployment of EJB1.jar fails with an error: 

javax.management.InstanceAlreadyExistsException: 
blah,blah,blah (no this is not important, since the 
problem is very clearly defined)...-contents/EJB1.jar 
already registered.

I.e., the MANIFEST.MF-deployment process beats the 
regular EJB-deployer to the EJB1.jar.

We can also bypass this problem by enforcing ALL 
auxiliary code to be put in non-EJB Jars, but would it not 
be nicer to be able to deploy any J2EE-compliant 
application.

So, we (I am not an active member) have to either (1) 
differentiate between real deployment (e.g. EJBs) and 
MANIFEST-dependent deployments, or (2) be silent 
when we encounter a MANIFEST-deployed module 
again.

Thanks for a great product!

--

Comment By: David Bergman (davber)
Date: 2002-10-28 16:20

Message:
Logged In: YES 
user_id=395691

I can easily fix this problem. Just got a bit tired of starksm 
comments, and temporary inability to see this as the obvious 
non-compliance to the J2EE 1.3 it actually is. I appreciate he 
has got a lot to do, not always having time to penetrate each 
comment thoroughly.

One just have to add a flag to the JAR deployment informing 
whether it should be J2EE-deployed or merely added to the 
internal classpath, and use the latter variant when dealing 
with indirect (through MANIFEST.MF) deployables. And, of 
course, make sure that a subsequent real deployment 
(through application.xml etc.) of the JAR does not choke on 
the previous partial deployment, but rather just leave 
classpath forest as is, and add the J2EE stuff... 

If I get a message from starksm that he realizes that the 
current behavior is non-compliant, I will attach updated files, 
fixing this problem.

Sometimes Open Source means a gang of presumed 
geniuses showing off their superiority, and even sharing their 
creations with less fortunate developers. In this particular 
case, the gang even make money on the Open Source 
product (documentation, consulting etc..) But, this semi-
openess has actually led to a great product, so it might be 
the way to go.

Best

--

Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 16:05

Message:
Logged In: YES 
user_id=71283

Does anybody with a good enough knowledge of JBoss have the
bandwidth to fix this bug? It is a pretty serious
non-compliance with the J2EE 1.3 spec, which makes it a big
pain sometimes to deploy third party EJBs without having to
do modifications on them.

Given that the spec says this behaviour should be allowed,
that should completely be the end of the argument. Even if
as mentioned previously (by Scott), it is possible in your
own projects to set up your beans so they don't have
manifest classpath references to jars containing other beans
(and forcing the current JBOSS code to try to redploy thos
other beans again), a number of 3rd party EJBs do include
such references. To use these EJBs I now have to go into
them and modify the entries.

What is interesting (and relevant) is that if the
application is not deployed as an ear but rather as an
exploded directory version of that ear, the problem does not
happen.  If it can work properly for exploded ears, what is
the issue with normal ears?

Regards,

Colin


--

Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-02 13:04

Message:
Logged In: NO 

My post of 2002-10-02 09:57 refers to JBoss version 3.0.2.
Cheers, Matt

--

Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-02 12:57

Message:
Logged In: NO 

I've come across the same problem (I think). I have a 3rd
party supplied JAR, up.jar, which contains client code *and*
EJB code including the ejb-jar.xml deployment descriptor.

I've have listed up.jar in my WAR's manifest classpath. Both
the WAR and up.jar are packaged in an EAR. The
application.xml only defines the WAR as a module.

As JBoss deploys the WAR, the EJBs in up.jar are also
getting deployed even though the 

Re: [JBoss-dev] Oracle, table locks and CMP2 incompatibility

[danch]

Catalin Teodorescu wrote:

Check this link.

http://asktom.oracle.com/pls/ask/f?p=4950:8:1513219::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:292016138754,%7Bprimary%7D%20and%20%7Bkey%7D%20and%20%7Bupdate%7D%20and%20%7Btable%7D%20and%20%7Block%7D


Dan

-Original Message-
From: Michael Bartmann [mailto:michael.bartmann;lisytec.de]
Sent: Monday, October 28, 2002 12:21 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Oracle, table locks and CMP2 incompatibility


Hallo db gurus,

we have for some time experienced nasty timeouts on oracle
without jboss deadlock detection (or oracle deadlock detection)
kicking in. We might have found the solution today, allthough
this is not verified, perhaps only time will show.
(...or some db guru will tell me that my following explanation is
severly misguided.)

The EJB locking is based on entity locks. If you have an underlying
database which does locking too, it has to use row level locking,
(as opposed to table level locking) or else jboss detect deadlocks
on the database, as the check which detects deadlocks is based on a
graph representing locks on entity (row) level.

But there are circumstances, under which oracle does not use row
level locking even if with row level locking configured to always.

This happens when a table TableA has a dependent table TableB in a
1:n relationship (i.e. TableB has a foreign key pointing to TableA.)
If a row of TableA gets updated, oracle tries to lock all entries in
TableB with matching foreign key.

Here comes the vital point: If there is no index on the foreign key
columns of TableB, oracle does a shared lock on _table_ level. This
is probably because otherwise oracle would need to do a full table
scan on the fly to find the matching rows in TableB.

So if you configure jboss to generate the foreign key constraints
you are walking on thin ice; you have to generate indices on the
foreign key columns by hand, or else this effect might hount you.

Solution:
1) [workaround] disable foreign key (or their generation), and let
CMP2 itself take care of the constraints
or
2) implement generation of foreign key indices in jboss. (I'm not fully
convinced that this would suffice; jboss deadlock detection would
have to lock the same entities and avoid race conditions).


Even ignoring the table-lock escalation issue, this is what should 
happen. In fact, I'm a little surprised that Oracle doesn't just create 
the indices: I believe PostgreSQL does.


Does this sound reasonable to you?

Regards,
Michael Bartmann






---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-589808 ] EJB Jars already deployed by MANIFEST.MF

[noreply]

Bugs item #589808, was opened at 2002-08-01 13:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=589808group_id=22866

Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB Jars already deployed by MANIFEST.MF

Initial Comment:
It is currently impossible to use auxiliary code 
belonging to one EJB Jar EJB1.jar in another EJB Jar, 
EJB2.jar.

This problem arises now when (finally, after a few wronly 
claimed closures) the handling of dependent Jars, 
through MANIFEST.MF, really looks in the right 
directory (it used to look in EJB2.jar itself, no good...)

Since JBoss does not make a clear distinction between 
EJB-deployments and regular JAR-deployments, the 
deployment of EJB1.jar fails with an error: 

javax.management.InstanceAlreadyExistsException: 
blah,blah,blah (no this is not important, since the 
problem is very clearly defined)...-contents/EJB1.jar 
already registered.

I.e., the MANIFEST.MF-deployment process beats the 
regular EJB-deployer to the EJB1.jar.

We can also bypass this problem by enforcing ALL 
auxiliary code to be put in non-EJB Jars, but would it not 
be nicer to be able to deploy any J2EE-compliant 
application.

So, we (I am not an active member) have to either (1) 
differentiate between real deployment (e.g. EJBs) and 
MANIFEST-dependent deployments, or (2) be silent 
when we encounter a MANIFEST-deployed module 
again.

Thanks for a great product!

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 13:43

Message:
Logged In: YES 
user_id=175228

And my comment date 2002-08-01 14:23
 clearly states I agree this is a problem: The spec states 
that jars referenced through manifests should not be used as 
j2ee component deployments.

Perhaps if you weren't being such a pious jackass here more 
developers would be inclined to help you out.

--

Comment By: David Bergman (davber)
Date: 2002-10-28 13:20

Message:
Logged In: YES 
user_id=395691

I can easily fix this problem. Just got a bit tired of starksm 
comments, and temporary inability to see this as the obvious 
non-compliance to the J2EE 1.3 it actually is. I appreciate he 
has got a lot to do, not always having time to penetrate each 
comment thoroughly.

One just have to add a flag to the JAR deployment informing 
whether it should be J2EE-deployed or merely added to the 
internal classpath, and use the latter variant when dealing 
with indirect (through MANIFEST.MF) deployables. And, of 
course, make sure that a subsequent real deployment 
(through application.xml etc.) of the JAR does not choke on 
the previous partial deployment, but rather just leave 
classpath forest as is, and add the J2EE stuff... 

If I get a message from starksm that he realizes that the 
current behavior is non-compliant, I will attach updated files, 
fixing this problem.

Sometimes Open Source means a gang of presumed 
geniuses showing off their superiority, and even sharing their 
creations with less fortunate developers. In this particular 
case, the gang even make money on the Open Source 
product (documentation, consulting etc..) But, this semi-
openess has actually led to a great product, so it might be 
the way to go.

Best

--

Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 13:05

Message:
Logged In: YES 
user_id=71283

Does anybody with a good enough knowledge of JBoss have the
bandwidth to fix this bug? It is a pretty serious
non-compliance with the J2EE 1.3 spec, which makes it a big
pain sometimes to deploy third party EJBs without having to
do modifications on them.

Given that the spec says this behaviour should be allowed,
that should completely be the end of the argument. Even if
as mentioned previously (by Scott), it is possible in your
own projects to set up your beans so they don't have
manifest classpath references to jars containing other beans
(and forcing the current JBOSS code to try to redploy thos
other beans again), a number of 3rd party EJBs do include
such references. To use these EJBs I now have to go into
them and modify the entries.

What is interesting (and relevant) is that if the
application is not deployed as an ear but rather as an
exploded directory version of that ear, the problem does not
happen.  If it can work properly for exploded ears, what is
the issue with normal ears?

Regards,

Colin


--

Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-02 10:04

Message:
Logged In: NO 

My post of 2002-10-02 09:57 refers to JBoss version 3.0.2.
Cheers, Matt

--

Comment By: Nobody/Anonymous (nobody)
Date: 

Re: [JBoss-dev] Oracle, table locks and CMP2 incompatibility

[Michael Bartmann]

Hmmm.. if I understand this paper right,
it would mean that the child table is only
locked if:

a) one deletes records of the parent table
or
b) if one changes the pk value in the parent table.

which would not not be as bad as I thought when reading
other sources, which imply that a simple update on
the parent table would suffice to lock the associated
child rows.

Regards,
Michael Bartmann


Catalin Teodorescu wrote:

Check this link.

http://asktom.oracle.com/pls/ask/f?p=4950:8:1513219::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:292016138754,%7Bprimary%7D%20and%20%7Bkey%7D%20and%20%7Bupdate%7D%20and%20%7Btable%7D%20and%20%7Block%7D


Dan

-Original Message-
From: Michael Bartmann [mailto:michael.bartmann;lisytec.de]
Sent: Monday, October 28, 2002 12:21 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Oracle, table locks and CMP2 incompatibility


Hallo db gurus,

we have for some time experienced nasty timeouts on oracle
without jboss deadlock detection (or oracle deadlock detection)
kicking in. We might have found the solution today, allthough
this is not verified, perhaps only time will show.
(...or some db guru will tell me that my following explanation is
severly misguided.)

The EJB locking is based on entity locks. If you have an underlying
database which does locking too, it has to use row level locking,
(as opposed to table level locking) or else jboss detect deadlocks
on the database, as the check which detects deadlocks is based on a
graph representing locks on entity (row) level.

But there are circumstances, under which oracle does not use row
level locking even if with row level locking configured to always.

This happens when a table TableA has a dependent table TableB in a
1:n relationship (i.e. TableB has a foreign key pointing to TableA.)
If a row of TableA gets updated, oracle tries to lock all entries in
TableB with matching foreign key.

Here comes the vital point: If there is no index on the foreign key
columns of TableB, oracle does a shared lock on _table_ level. This
is probably because otherwise oracle would need to do a full table
scan on the fly to find the matching rows in TableB.

So if you configure jboss to generate the foreign key constraints
you are walking on thin ice; you have to generate indices on the
foreign key columns by hand, or else this effect might hount you.

Solution:
1) [workaround] disable foreign key (or their generation), and let
CMP2 itself take care of the constraints
or
2) implement generation of foreign key indices in jboss. (I'm not fully
convinced that this would suffice; jboss deadlock detection would
have to lock the same entities and avoid race conditions).

Does this sound reasonable to you?

Regards,
Michael Bartmann



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-589808 ] EJB Jars already deployed by MANIFEST.MF

[noreply]

Bugs item #589808, was opened at 2002-08-01 20:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=589808group_id=22866

Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB Jars already deployed by MANIFEST.MF

Initial Comment:
It is currently impossible to use auxiliary code 
belonging to one EJB Jar EJB1.jar in another EJB Jar, 
EJB2.jar.

This problem arises now when (finally, after a few wronly 
claimed closures) the handling of dependent Jars, 
through MANIFEST.MF, really looks in the right 
directory (it used to look in EJB2.jar itself, no good...)

Since JBoss does not make a clear distinction between 
EJB-deployments and regular JAR-deployments, the 
deployment of EJB1.jar fails with an error: 

javax.management.InstanceAlreadyExistsException: 
blah,blah,blah (no this is not important, since the 
problem is very clearly defined)...-contents/EJB1.jar 
already registered.

I.e., the MANIFEST.MF-deployment process beats the 
regular EJB-deployer to the EJB1.jar.

We can also bypass this problem by enforcing ALL 
auxiliary code to be put in non-EJB Jars, but would it not 
be nicer to be able to deploy any J2EE-compliant 
application.

So, we (I am not an active member) have to either (1) 
differentiate between real deployment (e.g. EJBs) and 
MANIFEST-dependent deployments, or (2) be silent 
when we encounter a MANIFEST-deployed module 
again.

Thanks for a great product!

--

Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 21:58

Message:
Logged In: YES 
user_id=71283

Is there any chance the two of you put aside the history on
this topic and somebody can get the code in, given that
everybody agrees the code needs to be fixed, and David has
offered to do the fix?

I think there was some confusion/misunderstanding here. To
be fair to David, when I read your post in question, Scott,
it was not terribly clear (to me) that you were in fact
agreeing that it was a problem which should be fixed. The
first sentence did quote the proper behaviour from the spec,
but then the rest of the same paragraph went on to basically
say nobody should be doing this anyways.

Regards,

Colin


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 21:43

Message:
Logged In: YES 
user_id=175228

And my comment date 2002-08-01 14:23
 clearly states I agree this is a problem: The spec states 
that jars referenced through manifests should not be used as 
j2ee component deployments.

Perhaps if you weren't being such a pious jackass here more 
developers would be inclined to help you out.

--

Comment By: David Bergman (davber)
Date: 2002-10-28 21:20

Message:
Logged In: YES 
user_id=395691

I can easily fix this problem. Just got a bit tired of starksm 
comments, and temporary inability to see this as the obvious 
non-compliance to the J2EE 1.3 it actually is. I appreciate he 
has got a lot to do, not always having time to penetrate each 
comment thoroughly.

One just have to add a flag to the JAR deployment informing 
whether it should be J2EE-deployed or merely added to the 
internal classpath, and use the latter variant when dealing 
with indirect (through MANIFEST.MF) deployables. And, of 
course, make sure that a subsequent real deployment 
(through application.xml etc.) of the JAR does not choke on 
the previous partial deployment, but rather just leave 
classpath forest as is, and add the J2EE stuff... 

If I get a message from starksm that he realizes that the 
current behavior is non-compliant, I will attach updated files, 
fixing this problem.

Sometimes Open Source means a gang of presumed 
geniuses showing off their superiority, and even sharing their 
creations with less fortunate developers. In this particular 
case, the gang even make money on the Open Source 
product (documentation, consulting etc..) But, this semi-
openess has actually led to a great product, so it might be 
the way to go.

Best

--

Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 21:05

Message:
Logged In: YES 
user_id=71283

Does anybody with a good enough knowledge of JBoss have the
bandwidth to fix this bug? It is a pretty serious
non-compliance with the J2EE 1.3 spec, which makes it a big
pain sometimes to deploy third party EJBs without having to
do modifications on them.

Given that the spec says this behaviour should be allowed,
that should completely be the end of the argument. Even if
as mentioned previously (by Scott), it is possible in your
own projects to set up your beans so they don't have
manifest classpath references to jars containing other beans
(and forcing the current JBOSS code to try 

[JBoss-dev] [ jboss-Bugs-589808 ] EJB Jars already deployed by MANIFEST.MF

[noreply]

Bugs item #589808, was opened at 2002-08-01 16:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=589808group_id=22866

Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB Jars already deployed by MANIFEST.MF

Initial Comment:
It is currently impossible to use auxiliary code 
belonging to one EJB Jar EJB1.jar in another EJB Jar, 
EJB2.jar.

This problem arises now when (finally, after a few wronly 
claimed closures) the handling of dependent Jars, 
through MANIFEST.MF, really looks in the right 
directory (it used to look in EJB2.jar itself, no good...)

Since JBoss does not make a clear distinction between 
EJB-deployments and regular JAR-deployments, the 
deployment of EJB1.jar fails with an error: 

javax.management.InstanceAlreadyExistsException: 
blah,blah,blah (no this is not important, since the 
problem is very clearly defined)...-contents/EJB1.jar 
already registered.

I.e., the MANIFEST.MF-deployment process beats the 
regular EJB-deployer to the EJB1.jar.

We can also bypass this problem by enforcing ALL 
auxiliary code to be put in non-EJB Jars, but would it not 
be nicer to be able to deploy any J2EE-compliant 
application.

So, we (I am not an active member) have to either (1) 
differentiate between real deployment (e.g. EJBs) and 
MANIFEST-dependent deployments, or (2) be silent 
when we encounter a MANIFEST-deployed module 
again.

Thanks for a great product!

--

Comment By: David Bergman (davber)
Date: 2002-10-28 17:05

Message:
Logged In: YES 
user_id=395691

Scott,

It is easy to become a jackass when you are treated in a 
jackassingly fashion. You showed no interest in the issue, 
and certainly did not confess that it was a problem at all.

But, it is. A problem for JBoss, so this is about helping JBoss 
out in becoming a better, and even more compliant, product. 
It is certainly not about helping me out, since I can always 
apply the proper changes locally.

Did you get hurt by my former comment? If so, I apologize, 
but that is the feeling I and others (in offline discussions) 
get sometimes. So, there might be reason to change the 
attitude and really treat people (experienced people, with 
some having IQs well above 160) and their comments 
seriously. That is the way to spread this product further.

Your comment including hard words does not help in that 
respect. I did not use strong words and will not it either.

Else, we pious people will find other venues for our creativity 
and our strive to produce the best J2EE infrastructure.

Best,

David Pious Bergman

--

Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 16:58

Message:
Logged In: YES 
user_id=71283

Is there any chance the two of you put aside the history on
this topic and somebody can get the code in, given that
everybody agrees the code needs to be fixed, and David has
offered to do the fix?

I think there was some confusion/misunderstanding here. To
be fair to David, when I read your post in question, Scott,
it was not terribly clear (to me) that you were in fact
agreeing that it was a problem which should be fixed. The
first sentence did quote the proper behaviour from the spec,
but then the rest of the same paragraph went on to basically
say nobody should be doing this anyways.

Regards,

Colin


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 16:43

Message:
Logged In: YES 
user_id=175228

And my comment date 2002-08-01 14:23
 clearly states I agree this is a problem: The spec states 
that jars referenced through manifests should not be used as 
j2ee component deployments.

Perhaps if you weren't being such a pious jackass here more 
developers would be inclined to help you out.

--

Comment By: David Bergman (davber)
Date: 2002-10-28 16:20

Message:
Logged In: YES 
user_id=395691

I can easily fix this problem. Just got a bit tired of starksm 
comments, and temporary inability to see this as the obvious 
non-compliance to the J2EE 1.3 it actually is. I appreciate he 
has got a lot to do, not always having time to penetrate each 
comment thoroughly.

One just have to add a flag to the JAR deployment informing 
whether it should be J2EE-deployed or merely added to the 
internal classpath, and use the latter variant when dealing 
with indirect (through MANIFEST.MF) deployables. And, of 
course, make sure that a subsequent real deployment 
(through application.xml etc.) of the JAR does not choke on 
the previous partial deployment, but rather just leave 
classpath forest as is, and add the J2EE stuff... 

If I get a message from starksm that he realizes that the 
current behavior 

RE: [JBoss-dev] Oracle, table locks and CMP2 incompatibility

[Catalin Teodorescu]

Check out also the Oracle doc for the version you use.
There are some improvements in 9i.

Dan


-Original Message-
From: Michael Bartmann [mailto:michael.bartmann;lisytec.de]
Sent: Monday, October 28, 2002 13:41 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Oracle, table locks and CMP2 incompatibility


Hmmm.. if I understand this paper right,
it would mean that the child table is only
locked if:

a) one deletes records of the parent table
or
b) if one changes the pk value in the parent table.

which would not not be as bad as I thought when reading
other sources, which imply that a simple update on
the parent table would suffice to lock the associated
child rows.

Regards,
Michael Bartmann


Catalin Teodorescu wrote:
 Check this link.
 
 
http://asktom.oracle.com/pls/ask/f?p=4950:8:1513219::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:292016138754,%7Bprimary%7D%20and%20%7Bkey%7D%20and%20%7Bupdate%7D%20and%20%7Btable%7D%20and%20%7Block%7D
 
 
 Dan
 
 -Original Message-
 From: Michael Bartmann [mailto:michael.bartmann;lisytec.de]
 Sent: Monday, October 28, 2002 12:21 PM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] Oracle, table locks and CMP2 incompatibility
 
 
 Hallo db gurus,
 
 we have for some time experienced nasty timeouts on oracle
 without jboss deadlock detection (or oracle deadlock detection)
 kicking in. We might have found the solution today, allthough
 this is not verified, perhaps only time will show.
 (...or some db guru will tell me that my following explanation is
 severly misguided.)
 
 The EJB locking is based on entity locks. If you have an underlying
 database which does locking too, it has to use row level locking,
 (as opposed to table level locking) or else jboss detect deadlocks
 on the database, as the check which detects deadlocks is based on a
 graph representing locks on entity (row) level.
 
 But there are circumstances, under which oracle does not use row
 level locking even if with row level locking configured to always.
 
 This happens when a table TableA has a dependent table TableB in a
 1:n relationship (i.e. TableB has a foreign key pointing to TableA.)
 If a row of TableA gets updated, oracle tries to lock all entries in
 TableB with matching foreign key.
 
 Here comes the vital point: If there is no index on the foreign key
 columns of TableB, oracle does a shared lock on _table_ level. This
 is probably because otherwise oracle would need to do a full table
 scan on the fly to find the matching rows in TableB.
 
 So if you configure jboss to generate the foreign key constraints
 you are walking on thin ice; you have to generate indices on the
 foreign key columns by hand, or else this effect might hount you.
 
 Solution:
 1) [workaround] disable foreign key (or their generation), and let
 CMP2 itself take care of the constraints
 or
 2) implement generation of foreign key indices in jboss. (I'm not fully
 convinced that this would suffice; jboss deadlock detection would
 have to lock the same entities and avoid race conditions).
 
 Does this sound reasonable to you?
 
 Regards,
 Michael Bartmann
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Oracle, table locks and CMP2 incompatibility

[Jeremy Boynes]

danch wrote:
Even ignoring the table-lock escalation issue, this is what should
happen. In fact, I'm a little surprised that Oracle doesn't just create
the indices: I believe PostgreSQL does.


I believe it's because they want to allow a DBA to configure the index in a
specific way e.g. in a specific tablespace, with additional columns for
index-only joins, as part of the PK (leading to CMR problems :-( ), and so
on.

I don't think MS-SQL creates an index either (although it's self-tuning
mechanism may add one later).



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-589808 ] EJB Jars already deployed by MANIFEST.MF

[noreply]

Bugs item #589808, was opened at 2002-08-01 13:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=589808group_id=22866

Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB Jars already deployed by MANIFEST.MF

Initial Comment:
It is currently impossible to use auxiliary code 
belonging to one EJB Jar EJB1.jar in another EJB Jar, 
EJB2.jar.

This problem arises now when (finally, after a few wronly 
claimed closures) the handling of dependent Jars, 
through MANIFEST.MF, really looks in the right 
directory (it used to look in EJB2.jar itself, no good...)

Since JBoss does not make a clear distinction between 
EJB-deployments and regular JAR-deployments, the 
deployment of EJB1.jar fails with an error: 

javax.management.InstanceAlreadyExistsException: 
blah,blah,blah (no this is not important, since the 
problem is very clearly defined)...-contents/EJB1.jar 
already registered.

I.e., the MANIFEST.MF-deployment process beats the 
regular EJB-deployer to the EJB1.jar.

We can also bypass this problem by enforcing ALL 
auxiliary code to be put in non-EJB Jars, but would it not 
be nicer to be able to deploy any J2EE-compliant 
application.

So, we (I am not an active member) have to either (1) 
differentiate between real deployment (e.g. EJBs) and 
MANIFEST-dependent deployments, or (2) be silent 
when we encounter a MANIFEST-deployed module 
again.

Thanks for a great product!

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 14:48

Message:
Logged In: YES 
user_id=175228

And for now the third time in this bug report I am stating that I 
agree this is a problem. As you state its easy to work around 
and so when I have time I will fix it. Your whinning in this 
report most likely put off others developers who could also 
have fixed this issue. The bulk of this report is now rambling 
junk off the topic of the bug which I don't appreciate. If you 
want to rant use the forums or dev list.

--

Comment By: David Bergman (davber)
Date: 2002-10-28 14:05

Message:
Logged In: YES 
user_id=395691

Scott,

It is easy to become a jackass when you are treated in a 
jackassingly fashion. You showed no interest in the issue, 
and certainly did not confess that it was a problem at all.

But, it is. A problem for JBoss, so this is about helping JBoss 
out in becoming a better, and even more compliant, product. 
It is certainly not about helping me out, since I can always 
apply the proper changes locally.

Did you get hurt by my former comment? If so, I apologize, 
but that is the feeling I and others (in offline discussions) 
get sometimes. So, there might be reason to change the 
attitude and really treat people (experienced people, with 
some having IQs well above 160) and their comments 
seriously. That is the way to spread this product further.

Your comment including hard words does not help in that 
respect. I did not use strong words and will not it either.

Else, we pious people will find other venues for our creativity 
and our strive to produce the best J2EE infrastructure.

Best,

David Pious Bergman

--

Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 13:58

Message:
Logged In: YES 
user_id=71283

Is there any chance the two of you put aside the history on
this topic and somebody can get the code in, given that
everybody agrees the code needs to be fixed, and David has
offered to do the fix?

I think there was some confusion/misunderstanding here. To
be fair to David, when I read your post in question, Scott,
it was not terribly clear (to me) that you were in fact
agreeing that it was a problem which should be fixed. The
first sentence did quote the proper behaviour from the spec,
but then the rest of the same paragraph went on to basically
say nobody should be doing this anyways.

Regards,

Colin


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 13:43

Message:
Logged In: YES 
user_id=175228

And my comment date 2002-08-01 14:23
 clearly states I agree this is a problem: The spec states 
that jars referenced through manifests should not be used as 
j2ee component deployments.

Perhaps if you weren't being such a pious jackass here more 
developers would be inclined to help you out.

--

Comment By: David Bergman (davber)
Date: 2002-10-28 13:20

Message:
Logged In: YES 
user_id=395691

I can easily fix this problem. Just got a bit tired of starksm 
comments, and temporary inability to see this as the obvious 
non-compliance to the J2EE 1.3 it actually is. I appreciate he 
has got a lot to do, not 

[JBoss-dev] [ jboss-Bugs-589808 ] EJB Jars already deployed by MANIFEST.MF

[noreply]

Bugs item #589808, was opened at 2002-08-01 16:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=589808group_id=22866

Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB Jars already deployed by MANIFEST.MF

Initial Comment:
It is currently impossible to use auxiliary code 
belonging to one EJB Jar EJB1.jar in another EJB Jar, 
EJB2.jar.

This problem arises now when (finally, after a few wronly 
claimed closures) the handling of dependent Jars, 
through MANIFEST.MF, really looks in the right 
directory (it used to look in EJB2.jar itself, no good...)

Since JBoss does not make a clear distinction between 
EJB-deployments and regular JAR-deployments, the 
deployment of EJB1.jar fails with an error: 

javax.management.InstanceAlreadyExistsException: 
blah,blah,blah (no this is not important, since the 
problem is very clearly defined)...-contents/EJB1.jar 
already registered.

I.e., the MANIFEST.MF-deployment process beats the 
regular EJB-deployer to the EJB1.jar.

We can also bypass this problem by enforcing ALL 
auxiliary code to be put in non-EJB Jars, but would it not 
be nicer to be able to deploy any J2EE-compliant 
application.

So, we (I am not an active member) have to either (1) 
differentiate between real deployment (e.g. EJBs) and 
MANIFEST-dependent deployments, or (2) be silent 
when we encounter a MANIFEST-deployed module 
again.

Thanks for a great product!

--

Comment By: David Bergman (davber)
Date: 2002-10-28 18:09

Message:
Logged In: YES 
user_id=395691

Scott,

this is the first time, but enough ranting, as you said.

Look at the problem when you have time and get back if you 
want me to later upload my suggested solution to this all-or-
nothing deployment problem.

Best,

Your pious colleague ;-)

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 17:48

Message:
Logged In: YES 
user_id=175228

And for now the third time in this bug report I am stating that I 
agree this is a problem. As you state its easy to work around 
and so when I have time I will fix it. Your whinning in this 
report most likely put off others developers who could also 
have fixed this issue. The bulk of this report is now rambling 
junk off the topic of the bug which I don't appreciate. If you 
want to rant use the forums or dev list.

--

Comment By: David Bergman (davber)
Date: 2002-10-28 17:05

Message:
Logged In: YES 
user_id=395691

Scott,

It is easy to become a jackass when you are treated in a 
jackassingly fashion. You showed no interest in the issue, 
and certainly did not confess that it was a problem at all.

But, it is. A problem for JBoss, so this is about helping JBoss 
out in becoming a better, and even more compliant, product. 
It is certainly not about helping me out, since I can always 
apply the proper changes locally.

Did you get hurt by my former comment? If so, I apologize, 
but that is the feeling I and others (in offline discussions) 
get sometimes. So, there might be reason to change the 
attitude and really treat people (experienced people, with 
some having IQs well above 160) and their comments 
seriously. That is the way to spread this product further.

Your comment including hard words does not help in that 
respect. I did not use strong words and will not it either.

Else, we pious people will find other venues for our creativity 
and our strive to produce the best J2EE infrastructure.

Best,

David Pious Bergman

--

Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 16:58

Message:
Logged In: YES 
user_id=71283

Is there any chance the two of you put aside the history on
this topic and somebody can get the code in, given that
everybody agrees the code needs to be fixed, and David has
offered to do the fix?

I think there was some confusion/misunderstanding here. To
be fair to David, when I read your post in question, Scott,
it was not terribly clear (to me) that you were in fact
agreeing that it was a problem which should be fixed. The
first sentence did quote the proper behaviour from the spec,
but then the rest of the same paragraph went on to basically
say nobody should be doing this anyways.

Regards,

Colin


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 16:43

Message:
Logged In: YES 
user_id=175228

And my comment date 2002-08-01 14:23
 clearly states I agree this is a problem: The spec states 
that jars referenced through manifests should not be used as 
j2ee component deployments.

Perhaps if you weren't being such a pious jackass here more 
developers 

[JBoss-dev] [ jboss-Bugs-564411 ] Error in TimedInstancePoolFeeder

[noreply]

Bugs item #564411, was opened at 2002-06-04 08:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=564411group_id=22866

Category: JBossServer
Group: v3.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Philipp Meier (llucifer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in TimedInstancePoolFeeder 

Initial Comment:
17:30:21,462 INFO  [Server] JBoss Release:
JBoss-3.1.0alpha CVSTag=HEAD
---
17:30:23,001 INFO  [ServerInfo] Java version:
1.3.1,Blackdown Java-Linux Team
17:30:23,026 INFO  [ServerInfo] Java VM: Classic VM
Blackdown-1.3.1-FCS,Blackdown Java-Linux Team
17:30:23,026 INFO  [ServerInfo] OS-System: Linux
2.4.17-686,i386
---
After calling a PortableRemoteObject.narrow(o, k) with
k beeing a wrong HomeInterface I first get (correctly)
the following Exception on the client side: 

 1)
testGetSchema(de.meisterbohne.cms.ejb.PropertySetManagerTest)
java.rmi.ServerException: RemoteException occurred in
server thread; nested exception is: 
java.rmi.ServerException: null
Embedded Exception
null; nested exception is: 
javax.ejb.EJBException: nested exception is:
java.lang.ClassCastException
java.rmi.ServerException: null
Embedded Exception
null; nested exception is: 
javax.ejb.EJBException: nested exception is:
java.lang.ClassCastException
javax.ejb.EJBException: nested exception is:
java.lang.ClassCastException
java.lang.ClassCastException
javax.ejb.EJBException: nested exception is:
java.lang.ClassCastException
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:245)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
at
org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown
Source)
at
org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:127)
at
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:92)
at
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:51)
at
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:48)
at
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:111)
at
org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:83)
at $Proxy1.createPropertySet(Unknown Source)
at
de.meisterbohne.cms.ejb.PropertySetManagerTest.testGetSchema(PropertySetManagerTest.java:31)

---

But since then the server logs an error in 1 sec interval:
17:33:12,694 ERROR [TimedInstancePoolFeeder] Unexpcted
failure; ignoring
javax.ejb.EJBException: null
Embedded Exception
null
at
org.jboss.ejb.StatelessSessionEnterpriseContext.init(StatelessSessionEnterpriseContext.java:59)
at
org.jboss.ejb.plugins.StatelessSessionInstancePool.create(StatelessSessionInstancePool.java:46)
at
org.jboss.ejb.plugins.AbstractInstancePool.add(AbstractInstancePool.java:148)
at
org.jboss.ejb.plugins.TimedInstancePoolFeeder.run(TimedInstancePoolFeeder.java:61)
at java.util.TimerThread.mainLoop(Timer.java:435)
at java.util.TimerThread.run(Timer.java:385)
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:296)
at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
at
de.meisterbohne.cms.ejb.AbstractEnterpriseBean.lookup(AbstractEnterpriseBean.java:34)
at
de.meisterbohne.cms.ejb.PropertySetManagerBean.lookupRefs(PropertySetManagerBean.java:262)
at
de.meisterbohne.cms.ejb.PropertySetManagerBean.ejbCreate(PropertySetManagerBean.java:256)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.ejb.StatelessSessionEnterpriseContext.init(StatelessSessionEnterpriseContext.java:52)
at
org.jboss.ejb.plugins.StatelessSessionInstancePool.create(StatelessSessionInstancePool.java:46)
at
org.jboss.ejb.plugins.AbstractInstancePool.add(AbstractInstancePool.java:148)
at
org.jboss.ejb.plugins.TimedInstancePoolFeeder.run(TimedInstancePoolFeeder.java:61)
at java.util.TimerThread.mainLoop(Timer.java:435)
at java.util.TimerThread.run(Timer.java:385)
17:33:13,121 ERROR [TimedInstancePoolFeeder] Unexpcted
failure; ignoring
javax.ejb.EJBException: null
Embedded Exception
null
at
org.jboss.ejb.StatelessSessionEnterpriseContext.init(StatelessSessionEnterpriseContext.java:59)
at
org.jboss.ejb.plugins.StatelessSessionInstancePool.create(StatelessSessionInstancePool.java:46)
at
org.jboss.ejb.plugins.AbstractInstancePool.add(AbstractInstancePool.java:148)
at
org.jboss.ejb.plugins.TimedInstancePoolFeeder.run(TimedInstancePoolFeeder.java:61)
at java.util.TimerThread.mainLoop(Timer.java:435)
at java.util.TimerThread.run(Timer.java:385)
java.lang.ClassCastException

[JBoss-dev] [ jboss-Bugs-617585 ] NullPointerException depl. WAR on 3.0.3

[noreply]

Bugs item #617585, was opened at 2002-10-02 07:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=617585group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: PEte Clark (pc3)
Assigned to: Nobody/Anonymous (nobody)
Summary: NullPointerException depl. WAR on 3.0.3 

Initial Comment:
I'm trying to deploy my war file on jboss 3.0.3. 
Everything worked fine on 3.0.2, I moved my necessary 
lib files in, etc. I get this exception when I start jboss 
with my .war file in there:

13:53:19,310 ERROR [URLDeploymentScanner] Failed 
to deploy: 
org.jboss.deployment.scanner.URLDeploymentScanner$
DeployedUR
L@88446927{ url=file:/C:/jboss-
3.0.3/server/all/deploy/bobo.war, 
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: - nested 
throwable: (java.lang.NullPointerException)
at org.jboss.jetty.Jetty.deploy(Jetty.java:434)
at org.jboss.jetty.JettyService.performDeploy
(JettyService.java:243)
at org.jboss.web.AbstractWebContainer.start
(AbstractWebContainer.java:300)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:802)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:616)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:580)
at sun.reflect.GeneratedMethodAccessor14.invoke
(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy4.deploy(Unknown Source)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.
deploy(URLDeploymentScanner.java:427)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.
scanDirectory(URLDeploymentScanner.java:648)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.
scan(URLDeploymentScanner.java:499)
at 
org.jboss.deployment.scanner.AbstractDeploymentScan
ner.startService(AbstractDeploymentScanner.java:261)
at org.jboss.system.ServiceMBeanSupport.start
(ServiceMBeanSupport.java:164)
at sun.reflect.GeneratedMethodAccessor9.invoke
(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at 
org.jboss.system.ServiceController$ServiceProxy.invoke
(ServiceController.java:976)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start
(ServiceController.java:397)
at sun.reflect.GeneratedMethodAccessor7.invoke
(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy3.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start
(SARDeployer.java:249)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:802)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:616)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:580)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:564)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.system.server.ServerImpl.doStart
(ServerImpl.java:324)
at org.jboss.system.server.ServerImpl.start
(ServerImpl.java:221)
at org.jboss.Main.boot(Main.java:148)
at org.jboss.Main$1.run(Main.java:381)
at java.lang.Thread.run(Thread.java:536)
Caused by: java.lang.NullPointerException
at org.mortbay.j2ee.session.Manager.start
(Manager.java:159)
at org.mortbay.jetty.servlet.ServletHandler.start
(ServletHandler.java:409)
at org.mortbay.jetty.servlet.WebApplicationHandler.start
(WebApplicationHandler.java:142)
at org.mortbay.http.HttpContext.startHandlers
(HttpContext.java:1780)


--

Comment By: Laurent Etiemble (letiemble)
Date: 2002-10-02 08:36

Message:
Logged In: YES 
user_id=437455

Hi all,

I have the same problem on my WAR :
- deploys fine in 3.0.1
- deploys fine in 3.0.2
- NPE in 3.0.3.

I made some investigations, and here is what I 

[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock

[noreply]

Bugs item #617574, was opened at 2002-10-03 00:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866

Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M Stark (starksm)
Summary: Classloader deadlock

Initial Comment:
We have for the third time in quite some weeks
experienced a partial lookup
of the JBoss server (some services responsive, others
not). The bug is not deterministically reproducible for us.
But this time we luckily had a debugger online and
drilled down
to what seems to be a classloader deadlock.

This was under NT4.0 (it happend before under W2000 also)
We used Branch_3_2 (checkout 12 hours before it went beta)
under JDK1.4.0-b92.

It happened when many separate ear-scoped mbeans
and dependent MDBs got deployed in a short time.
Many of the mbeans are JMSProviders and the MDBs
recieve external messages almost immediatelly after
startup, so they all try to load classes simultaneously.

Most of the threads were waiting for a lock at line 84
in the loadClass()
of HeirarchicalLoaderRepository2; only one threads was
locked
in loadClass() of  java.lang.ClassLoader.

The two threads which seem to have caused the deadlock were
Thread-47 (java.util.TimerThread) and
Thread Pool Worker-0 (EDU.oswego.blablaWorker),
both childs of the ThreadGroup ASF Session Pool Threads.

===
Thread-47 has the following trace:
loadClass() at line 84 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
loadClass() at line 262 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
===
Thread Pool Worker-0 has the following trace:
loadClass() at line 295 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
loadClass() at line 88 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
===

...so the deadlock seems evident. 


--

Comment By: Stephen Coy (scoy)
Date: 2002-10-29 10:41

Message:
Logged In: YES 
user_id=463096

This appears to be working now.


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 20:45

Message:
Logged In: YES 
user_id=175228

This was another variation on a lost notification. In this case 
an exception thrown from LoadMgr.beginLoadTask would 
bypass the call to LoadMgr.endLoadTask and leave a thread 
assigned as the owner of a UCL when it was not. If a load 
task was assigned to this thread an infinite wait could ensue 
if the assigned thread never loaded another class.

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 15:42

Message:
Logged In: YES 
user_id=175228

Enable tracing of the org.jboss.mx.loading category by 
adding a section like the following to the conf/log4j.xml file:

  category name=org.jboss.system
priority value=TRACE 
class=org.jboss.logging.XLevel/
  /category

and attach the log file of the TRACE level msgs.



--

Comment By: Stephen Coy (scoy)
Date: 2002-10-28 15:28

Message:
Logged In: YES 
user_id=463096

I've just refreshed my Branch_3_0 from cvs, cleaned and rebuilt, but the 
problem is still  there:

SocketListener-3 prio=5 tid=0x48620b0 nid=0x4811140 runnable 
[0xf0d99000..0xf0d9aba0]
at java.lang.Object.wait(Native Method)
at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader
3.java:152)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.beans.Introspector.instantiate(Introspector.java:1061)
at java.beans.Introspector.findInformant(Introspector.java:303)
at java.beans.Introspector.init(Introspector.java:251)
at java.beans.Introspector.getBeanInfo(Introspector.java:76)
at 
org.apache.struts.util.PropertyUtils.getPropertyDescriptors(PropertyUtils
.java:552)
at 
org.apache.struts.util.PropertyUtils.getPropertyDescriptor(PropertyUtils.j
ava:516)
at 
org.apache.struts.util.PropertyUtils.getSimpleProperty(PropertyUtils.java
:706)
at 
org.apache.struts.util.PropertyUtils.getNestedProperty(PropertyUtils.java
:426)
at 
org.apache.struts.util.PropertyUtils.getProperty(PropertyUtils.java:453)
at 
org.apache.struts.taglib.logic.CompareTagBase.condition(CompareTagB
ase.java:228)
at 
org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:90)
at 
org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(Conditiona
lTagBase.java:218)
at 
JspServ.online.workList.actionBar._jspService(actionBar.java:309)
   

[JBoss-dev] TODO: Easy task for someone looking to help...

[Jason Dillon]

I have an easy task for someone who is looking to help out.  I want to
get the README.*  LICENSE.* files sorted out for all of the /thirdparty
repository.  Some modules do not have them, some do.  Some are in odd
locations and in differing formats.

So, the task is to:

 a) Come up with a standard format and naming scheme for these files and
let 
jboss-dev know what it is, so we can discuses.

 b) Implement the scheme for the current /thirdparty repository (ie. cvs
get 
thirdparty and go from there, or better yet, look at the web cvs for
the 
list)

 c) Send me the output (or if you already have have rw), then commit it 
yourself.

 * * *

Any takers?  Let me know if you have any questions or comments.

--jason



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-625277 ] Servlet classloader static classes

[noreply]

Bugs item #625277, was opened at 2002-10-18 08:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=625277group_id=22866

Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Dani G. (danig)
Assigned to: Scott M Stark (starksm)
Summary: Servlet classloader  static classes

Initial Comment:
Java version: 1.4.0,Sun Microsystems Inc.
Java VM: Java HotSpot(TM) Client VM 1.4.0-b92,Sun 
OS-System: Windows NT 4.0,x86
JBoss: jboss-3.0.3_tomcat-4.0.5

I have two ear files that are nearly identical. Each 
contains one jar file and one war file. The jar files contain 
only stateless session beans.

The only differences between the two ear files are the 
ear file name (DaniTest.ear vs DaniTest2.ear), the web 
context root (DaniTest vs DaniTest2), and the jndi 
names to which the stateless session beans in the jar 
files are bound (ie ejb/DaniTest/BookCtrl vs 
ejb/DaniTest2/BookCtrl). The web.xml files also differ by 
having two different values for an environment variable 
indicating the application name (DaniTest vs DaniTest2).

The war files contain a jar file named sfxcommon.jar in 
WEB-INF/lib. One of the classes in this jar file is 
JNDIUtil, which is an abstract utility class with static 
methods used in the servlet and throughout the EJB's to 
get instances of stateless session beans without having 
to rewrite the code to get initial contexts, narrow( ), etc. 
JNDIUtil contains a static private variable to store the 
base JNDI path to use in retrieving the EJB's, 
ie ejb/DaniTest or ejb/DaniTest2.

This private static variable is initialized the first time it is 
used based on the app-name environment variable 
mentioned above. The first time JNDIUtil gets used is 
always in the servlet.

The problem is that when both DaniTest and DaniTest2 
are deployed, they *both* use the same JNDIUtil in the 
servlets, thereby both using the same base path, for 
example always ejb/DaniTest. This causes the EJB's 
in one application to be used by the servlets in both 
applications.

The above example works on WebLogic, so my initial 
inclination is to believe that it is a bug either in Tomcat 
itself or in the JBoss code that interacts with Tomcat.

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 16:28

Message:
Logged In: YES 
user_id=175228

EJBs cannot see into a war WEB-INF/lib so are you sure 
that JNDIUtil is not in a jar referenced by the ejb jars? The 
behavior you describe indicates that this is the case, and is 
expected given the 3.0 flat classes namespace. To isolate 
the ears from each other you need to use scoped class 
loading on the ear as described in the the 3.0 change note 
numbered 558189.


--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: Re[4]: [JBoss-dev] can't add a dir to thirdparty

[Jason Dillon]

Apache commons collections has been imported in apache-commons.

--jason


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:jboss-
 [EMAIL PROTECTED]] On Behalf Of Alex Loubyansky
 Sent: Friday, October 25, 2002 1:30 PM
 To: Jason Dillon
 Subject: Re[4]: [JBoss-dev] can't add a dir to thirdparty
 
 You are cool. I respect you.
 
 Please, guide me through this.
 I have jboss-head/thirdparty/tmp/ that contains:
 readme
 lib/
META-INF/
   license
   manifest.mf
*.class
 
 Then I execute the following:
 cvs import -mimported apache commons-collections version 2.0, dated
 02/04/2002. thirdparty/apache/commons-collections apache commons-
 collections_2_0
 
 How can I edit modules file? Were is it?
 
 alex
 
  I want to add to thirdparty the following:
  apache-commons/
readme
lib/
   commons-collections.jar
 
  I started with 'cvs add apache-commons' and got the error I wrote
  about.
 
  As to the jar, I would add the following way:
  cvs add -kb commons-collections.jar
  cvs ci -mapache commons collections commons-collections.jar
 
  Is it correct?
 
 JD Nope.  The thirdparty module is setup in a different fashion from
how
 it
 JD is checked out.  Perhaps that should be changed eventually, but
for
 now
 JD that is how it works.  I think the build system faq covers this,
but I
 JD will give you the short version.
 
 JD The physical repository looks like this:
 
 JD  /thirdparty/
 JD  apache/
 JD log4j/
 JD   lib/*
 
 JD For jboss-head this will get mapped to /thirdparty/apache-log4j.
This
 JD is a recent change to prevent `cvs update` from checking out all
files
 JD under 'apache', when only a subset is required.
 
 JD To add a new thirdparty library do something like this:
 
 JD  1) download the archive of the library
 
 JD  2) extract the archive into a temporary directory
 
 JD  3) remove all non-essential files (docs, examples, whatever)
 JD basically we only want basic README, COPYRIGHT  lib/* files.
 
 JD  4) Make sure that all library files live in lib (move them if
the
 JD archive does not have them in this order
 
 JD  5) If the library has a README and/or COPYRIGHT docs, make sure
they
 JD are in the root.
 
 JD  6) Make sure you are in the top-level of the archive (where lib
is a
 JD direct
 JD child) and:
 
 JD  cvs -d CVSROOT import thirdparty/vendor/package vender
 JD package_version
 
 JD So for Apache/Jakarta Commons v1.1 you would:
 
 JD  cvs -d CVSROOT import thirdparty/apache/commons apache
commons_1_1
 
 JD The check in comments are basically describing the new import, so
list
 JD the full name  version of the imported bits.
 
 JD Then, you need to edit CVSROOT/modules, in the bottom there is a
 JD thirdparty library section, copy the format of other entries for
the
 new
 JD entry.  Then add the module include to which ever projects you
need to
 JD access it from.
 
 JD Then, finally, edit tools/etc/buildfragments/libraries.ent and add
 JD definitions of the root, lib and classpath's for this library.
Note
 JD that you should use exact paths (no filesets) so that the build
system
 JD does not freak out when this library is not present.
 
 JD That is it... rather simple once you get the hang of it.
 
 JD Again, if you like I can handle this for you if you tell me what
you
 JD need done exactly.
 
 JD --jason
 
 
 --
 Best regards,
  Alex Loubyansky
 
 
 
 
 ---
 This sf.net email is sponsored by: Influence the future
 of Java(TM) technology. Join the Java Community
 Process(SM) (JCP(SM)) program now.
 http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-624653 ] UnifiedLoaderRepository2 memory leak

[noreply]

Bugs item #624653, was opened at 2002-10-17 06:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=624653group_id=22866

Category: None
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Marco Ladermann (mpl)
Assigned to: Scott M Stark (starksm)
Summary: UnifiedLoaderRepository2 memory leak

Initial Comment:
The method  removeClassLoader(ClassLoader cl) of the
UnifiedLoaderRepository2 does not release all references
to the CL to remove.  The classloader is left in the   
loaderToPackagesMap.   
   
The line:   
String[] pkgNames = (String[])  
loaderToPackagesMap.get(cl);  
  
should be replaced by  
String[] pkgNames = (String[])  
loaderToPackagesMap.remove(cl);  
  
  
Regards  
Marco  

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 16:42

Message:
Logged In: YES 
user_id=175228

Fixed for 3.0.4 and 3.2beta2

--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-624494 ] NullPointerEx adding container to app

[noreply]

Bugs item #624494, was opened at 2002-10-17 00:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=624494group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alexei Yudichev (sflexus)
Assigned to: Scott M Stark (starksm)
Summary: NullPointerEx adding container to app

Initial Comment:
I began to quite often face following exceptions while deploying an 
application (not a particular application but any one). It does not 
happen under any special condition or at least I couldn't find it for 
now... I use jboss 3.0.3 release.

2002-10-17 10:04:28,992 
DEBUG [org.jboss.ejb.EJBDeployer] Deploying: 
file:/usr/local/java/jboss-
3.0.3/server/thunder/deploy/80_EazyBuild.jar
2002-10-17 
10:04:28,993 INFO  [org.jboss.ejb.EjbModule] 
Creating
2002-10-17 10:04:29,007 DEBUG 
[org.jboss.ejb.EjbModule] Application.start(), begin
2002-10-
17 10:04:29,008 INFO  [org.jboss.ejb.EjbModule] Deploying 
Category
2002-10-17 10:04:29,021 ERROR 
[org.jboss.ejb.EjbModule] error adding container to 
app.
java.lang.NullPointerException
at 
org.jboss.ejb.EjbModule.initializeContainer(EjbModule.java:709)
at 
org.jboss.ejb.EjbModule.createEntityContainer(EjbModule.java:629)
at 
org.jboss.ejb.EjbModule.createContainer(EjbModule.java:547)
at 
org.jboss.ejb.EjbModule.createService(EjbModule.java:363)
at 
org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:136)
at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at 
java.lang.reflect.Method.invoke(Method.java:324)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at 
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
at 
$Proxy5.create(Unknown Source)
at 
org.jboss.system.ServiceController.create(ServiceController.java:315)
at 
org.jboss.system.ServiceController.create(ServiceController.java:243)
at 
sun.reflect.GeneratedMethodAccessor4.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at 
java.lang.reflect.Method.invoke(Method.java:324)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at 
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at 
$Proxy8.create(Unknown Source)
at 
org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:376)
at 
org.jboss.deployment.MainDeployer.create(MainDeployer.java:755)
at 
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:615)
at 
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580)
at 
sun.reflect.GeneratedMethodAccessor12.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at 
java.lang.reflect.Method.invoke(Method.java:324)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at 
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at 
$Proxy4.deploy(Unknown Source)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:427)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:553)
at 
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:212)
at 
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:225)
at 
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:202)

Looked 
at the source, something with webServer.addClassLoader(wcl) 
returns null.. I looked at source a bit and found that it's only possible 
when system property java.rmi.server.codebase is not set...

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 16:59

Message:
Logged In: YES 
user_id=175228

I don't see how this can happen given that the 
WebServiceMBean used to obtain the class loader always 
sets the java.rmi.server.codebase. I have added a check for a 
null URL in any event.

--

Comment By: Alexei Yudichev (sflexus)
Date: 2002-10-21 23:44

Message:
Logged In: YES 
user_id=345880

After I 

Re: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols inSELECT clause

[Hunter Hillegas]

Will this be something that is configurable per datasource type or mandated
in JBossCMP as the default? Will there be any way to tell JBoss *not* to add
these order bys in the event we don't want them?

Hunter

 From: [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 Date: Mon, 28 Oct 2002 11:57:13 -0800
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols in SELECT
 clause
 
 Bugs item #591835, was opened at 2002-08-06 22:46
 You can respond by visiting:
 https://sourceforge.net/tracker/?func=detailatid=376685aid=591835group_id=2
 2866
 
 Category: JBossCMP
 Group: v3.2
 Status: Open
 Resolution: Accepted
 Priority: 5
 Submitted By: Stephen Coy (scoy)
 Assigned to: Dain Sundstrom (dsundstrom)
 Summary: Include ORDER BY cols in SELECT clause
 
 Initial Comment:
 Some databases, Oracle in particular, require that columns named
 in an ORDER BY clause be included in the SELECT clause when
 SELECT DISTINCT is used.
 
 Here is some text from current Oracle documentation:
 
 Restrictions on the order_by_clause:
 
 *If you have specified the DISTINCT operator in this statement,
 then this clause cannot refer to columns unless they appear in the
 select list.
 
 *An order_by_clause can contain no more than 255 expressions.
 
 
 This can be worked around using on-find loading with load groups,
 but it sure would be useful if JBoss managed it for us.
 
 
 
 --
 
 Comment By: Emerson Cargnin (echofloripa)
 Date: 2002-10-28 17:57
 
 Message:
 Logged In: YES 
 user_id=378942
 
 the workaround is useless if I use a dynamic-ql, correct me
 if I'm wrong
 
 --
 
 Comment By: Emerson Cargnin (echofloripa)
 Date: 2002-10-15 16:23
 
 Message:
 Logged In: YES 
 user_id=378942
 
 For oracle users, this is really a showstopper bug. I'll try
 to undertand to (maybe) try to solve that : ) obs: i think
 it'll take too long to me to take this : )
 
 --
 
 Comment By: Dain Sundstrom (dsundstrom)
 Date: 2002-08-23 22:00
 
 Message:
 Logged In: YES 
 user_id=251431
 
 This is really a bug.
 
 --
 
 You can respond by visiting:
 https://sourceforge.net/tracker/?func=detailatid=376685aid=591835group_id=2
 2866
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-624449 ] XML Parser class path priority

[noreply]

Bugs item #624449, was opened at 2002-10-16 22:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=624449group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Archimedes Trajano (trajano)
Assigned to: Scott M Stark (starksm)
Summary: XML Parser class path priority

Initial Comment:
If the WEB-INF\lib directory contains an XML parser.  
Shouldn't it be the one selected by JAXP instead of 
Crimson which is installed in the JBoss\lib directory.

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 17:12

Message:
Logged In: YES 
user_id=175228

This is the servlet 2.3 class loading model which can be 
enabled by setting the Java2ClassLoadingCompliance 
attribute of any web container service to false. When set to 
false, classes are fist loaded from the war and then the 
parent class loader.

--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-621485 ] Jetty requires realm-name for FORM auth

[noreply]

Bugs item #621485, was opened at 2002-10-10 10:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=621485group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Jetty requires realm-name for FORM auth

Initial Comment:
Jetty is failing with a 500 internal error when a war with 
FORM based auth does not include a realm-name 
element. See the attached realm.war for an example. 
The realm-name is only meaningful for BASIC auth.

This problem exists in the current jboss-3.0.4RC1 
branch as of Thu Oct 10 17:51:16 GMT 2002

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 17:18

Message:
Logged In: YES 
user_id=175228

Fixed for the 3.0.4 release

--

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-623223 ] possible deadlock in log4j related code

[noreply]

Bugs item #623223, was opened at 2002-10-14 13:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=623223group_id=22866

Category: JBossServer
Group: v2.4 (stable)
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Jerome Lacoste (lacostej)
Assigned to: Scott M Stark (starksm)
Summary: possible deadlock in log4j related code

Initial Comment:
OS: Windows NT 4
JDK 1.4.1 
JBoss 2.4.7 binary distribution with Jetty 4.0.4

There is a possible deadlock in log4j related code. We
started experiencing this after adding a new MBean
service to our application. It is 100% reproducible.

The deadlock is due to the fact that the log4j
CategoryStreame uses a hack to log some lost messages.
This hack tries to renter log4j logging by calling
log() on the wrapped category. Upon certain conditions,
this will cause a deadlock.

Details:

Hitting Ctrl-Break on the hung program gives me the
following output:
 [...]
 Java stack information for the threads listed above:
 ===
 Thread-23:
at
org.apache.log4j.Category.callAppenders(Category.java:253)
- waiting to lock 0328F228 (a
 org.apache.log4j.spi.RootCategory)
at
org.apache.log4j.Category.forcedLog(Category.java:445)
at org.apache.log4j.Category.log(Category.java:864)
at
 org.jboss.logging.log4j.CategoryStream.write(CategoryStream.java:91)
- locked 0329D410 (a
 org.jboss.logging.log4j.CategoryStream)  at
 org.jboss.logging.log4j.CategoryStream.println(CategoryStream.java:49)
at
 org.hsqldb.Embedded_ServerConnection.run(Embedded_ServerConnection.java:161)
at java.lang.Thread.run(Thread.java:536)
 Thread-2:
at java.io.PrintStream.flush(PrintStream.java:133)
- waiting to lock 0329D410 (a
 org.jboss.logging.log4j.CategoryStream)
at
 sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at
sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:150)
- locked 0349E880 (a java.io.OutputStreamWriter)
at
java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
at
 org.apache.log4j.helpers.QuietWriter.flush(QuietWriter.java:49)
at
 org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:309)
at
 org.apache.log4j.WriterAppender.append(WriterAppender.java:157)
at
 org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
- locked 0349DB48 (a
org.apache.log4j.ConsoleAppender)
at

org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57)
at
org.apache.log4j.Category.callAppenders(Category.java:255)
- locked 0328F228 (a
org.apache.log4j.spi.RootCategory)
at
org.apache.log4j.Category.forcedLog(Category.java:445)
 [...]
 Found 1 deadlock.

 After having a look at the stack trace, it looks like
the lock is coming from this piece of code, within
org.jboss.logging.util.CategoryStream
 
   // HACK, something is logging exceptions line by
line (including
// blanks), but I can't seem to find it, so for
now just ignore
// empty lines... they aren't very useful.
if (len != 0) {
String msg = new String(b, off, len);
category.log(priority, msg);
}
inWrite = false;

Hacks ain't good :)
Removing the call to category.log() removes the
deadlock in our current tests. But this does not solve
the problem.
I guess there are 2 solutions:
- find which logs were concerned by the hack, and
correct the problem, removing the hack
- try to make log4j reentrant.

The problem may be present in other versions of JBoss
(including the latest) as the current version of
CategoryStream still contains the HACK.

Patch coming.


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-28 17:26

Message:
Logged In: YES 
user_id=175228

This removes the redirection of the console streams. The real 
issue is that applications should not override the server 
logging system using BasicConfigurator. Create a seperate 
logging repository if using log4j 1.2, or use the server log4j 
configuration.

--

Comment By: Jerome Lacoste (lacostej)
Date: 2002-10-15 02:03

Message:
Logged In: YES 
user_id=81510

If anyone interested, I attach the batch file used to patch
JBoss

--

Comment By: Jerome Lacoste (lacostej)
Date: 2002-10-15 01:58

Message:
Logged In: YES 
user_id=81510

We first managed to remove the deadlock by patching the
CategoryStream.java file in package org.jboss.logging.log4j 
Patch attached. This may be the correct way to fix the problem.

We think we also found out went the deadlock started to appear. 
We introduced by mistaked the following code in a static
initializer of one of our classes:
  

[JBoss-dev] [ jboss-Bugs-619171 ] Logging Deadlock

[noreply]

Bugs item #619171, was opened at 2002-10-06 00:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=619171group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Timur Zambalayev (timurz)
Assigned to: Scott M Stark (starksm)
Summary: Logging Deadlock 

Initial Comment:
What happens. Under certain circumstances JBoss can 
get into a deadlock.

How to repro (tried JBoss 3.0.3 on Win2k, also 
experienced it with JBoss 3.0.0 on Solaris 7).
1) Install JBoss 3.0.3.
2) Run ant clean deploy (see the attached zip).
3) Start JBoss.
4) Run ant fooClient.
5) JBoss deadlocked (see below).

Workaround.
1) Don't configure log4j (e.g. BasicConfigurator.configure
()) inside the EJB server.
2) After that don't use System.out.println().

=
Found one Java-level deadlock:
=
RMI TCP Connection(3)-192.168.2.10:
  waiting to lock monitor 0x8fe86c (object 0x2f15f28, a 
org.apache.log4j.spi.RootCategory),
  which is held by RMI TCP Connection(2)-192.168.2.10
RMI TCP Connection(2)-192.168.2.10:
  waiting to lock monitor 0x8fe74c (object 0x30e0b08, a 
org.jboss.logging.util.CategoryStream),
  which is held by RMI TCP Connection(3)-192.168.2.10

Java stack information for the threads listed above:
=
==
RMI TCP Connection(3)-192.168.2.10:
at org.apache.log4j.Category.callAppenders
(Category.java:188)
- waiting to lock 02F15F28 (a 
org.apache.log4j.spi.RootCategory)
at org.apache.log4j.Category.forcedLog
(Category.java:375)
at org.apache.log4j.Category.log
(Category.java:850)
at org.jboss.logging.util.CategoryStream.write
(CategoryStream.java:133)
- locked 030E0B08 (a 
org.jboss.logging.util.CategoryStream)
at 
org.jboss.logging.util.CategoryStream.println
(CategoryStream.java:81)
at FooBean.writeToSystemOut
(FooBean.java:34)
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.StatelessSessionContainer$ContainerInterc
eptor.invoke(StatelessSessionContainer.java:660)
at 
org.jboss.resource.connectionmanager.CachedConnectio
nInterceptor.invoke
(CachedConnectionInterceptor.java:186)
at 
org.jboss.ejb.plugins.StatelessSessionInstanceIntercept
or.invoke(StatelessSessionInstanceInterceptor.java:77)
at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:107)
at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:178)
at 
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:60)
at 
org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:130)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:203)
at 
org.jboss.ejb.StatelessSessionContainer.invoke
(StatelessSessionContainer.java:313)
at org.jboss.ejb.Container.invoke
(Container.java:712)
at 
org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at 
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke
(JRMPInvoker.java:381)
at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at sun.rmi.server.UnicastServerRef.dispatch
(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run
(Transport.java:148)
at java.security.AccessController.doPrivileged
(Native Method)
at sun.rmi.transport.Transport.serviceCall
(Transport.java:144)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages
(TCPTransport.java:460)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.r
un(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:536)
RMI TCP Connection(2)-192.168.2.10:
at java.io.PrintStream.flush
(PrintStream.java:135)
- waiting to lock 030E0B08 (a 
org.jboss.logging.util.CategoryStream)
at 
sun.nio.cs.StreamEncoder$CharsetSE.implFlush
(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush
(StreamEncoder.java:150)
- locked 02A91868 (a 
java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.flush
(OutputStreamWriter.java:213)
at org.apache.log4j.helpers.QuietWriter.flush
(QuietWriter.java:49)
at 
org.apache.log4j.WriterAppender.subAppend
(WriterAppender.java:311)
at org.apache.log4j.WriterAppender.append

[JBoss-dev] [ jboss-Bugs-608412 ] VerifyError when loading class from War

[noreply]

Bugs item #608412, was opened at 2002-09-12 07:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=608412group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Steve Wolfangel (swolfangel)
Assigned to: Nobody/Anonymous (nobody)
Summary: VerifyError when loading class from War

Initial Comment:
JBoss Release: JBoss-3.0.2 CVSTag=JBoss_3_0_2
Home Dir: D:\jb\server30\jboss
Home URL: file:/D:/jb/server30/jboss/
Library URL: file:/D:/jb/server30/jboss/lib/
Patch URL: nul
Root Deployemnt Filename: jboss-service.xml
Starting General Purpose Architecture (GPA)...
Java version: 1.3.1_01,Sun Microsystems Inc.
Java VM: Java HotSpot(TM) Client VM 1.3.1_01,Sun
Microsystems Inc.
OS-System: Windows NT 4.0,x86l

09:41:59,181 INFO  [Server] Root Deployemnt 
Filename: jboss-service.xml
09:41:59,197 INFO  [Server] Starting General 
Purpose Architecture (GPA)...
09:41:59,885 INFO  [ServerInfo] Java version: 
1.3.1_01,Sun Microsystems Inc.
09:41:59,885 INFO  [ServerInfo] Java VM: Java 
HotSpot(TM) Client VM 1.3.1_01,Sun
Microsystems Inc.
09:41:59,900 INFO  [ServerInfo] OS-System: 
Windows NT 4.0,x86

I have encountered the following error when 
running on Jboss 3.0.  This error is related to the 
functionality of a web application based on the 
struts framework.  The error occurs when the struts 
framework attempts to load a class that is in the 
classpath of the web application using the 
Class.forName(String) method.  The following is the 
stack trace for the error.

09:37:53,431 WARN  [jbossweb] WARNING: 
modelerweb: Error creating Action instance for 
path '/GetLoginInfo', class 
name 'com.metamatrix.modelerwe
b.struts.action.login.GetLoginInfoAction'
java.lang.VerifyError: (class: 
com/metamatrix/modelerweb/struts/action/login/
GetLoginInfoAction, method: perform signature: 
(Lorg/apache/struts/
action/ActionMapping;Lorg/apache/struts/action/A
ctionForm;Ljavax/servlet/http/HttpServletRequest;L
javax/servlet/http/HttpServletRespons -}
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:120)
at 
com.metamatrix.webtoolbox.struts.servlet.ActionSe
rvlet.processActionCreate(ActionServlet.java:56)
at 
org.apache.struts.action.ActionServlet.process
(ActionServlet.java:1576)
at org.apache.struts.action.ActionServlet.doGet
(ActionServlet.java:491)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at 
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:344)
at 
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:313)
at 
org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:554)
at 
org.mortbay.jetty.servlet.WebApplicationHandler.ha
ndle(WebApplicationHandler.java:199)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1572)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1522)
at org.mortbay.http.HttpServer.service
(HttpServer.java:795)
at org.jboss.jetty.Jetty.service(Jetty.java:531)
at org.mortbay.http.HttpConnection.service
(HttpConnection.java:784)
at 
org.mortbay.http.HttpConnection.handleNext
(HttpConnection.java:941)
at org.mortbay.http.HttpConnection.handle
(HttpConnection.java:799)
at 
org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:186)
at org.mortbay.util.ThreadedServer.handle
(ThreadedServer.java:322)
at org.mortbay.util.ThreadPool$JobRunner.run
(ThreadPool.java:716)
at java.lang.Thread.run(Thread.java:484)

09:37:53,525 INFO  [jbossweb] modelerweb: Error 
creating Action instance for path '/GetLoginInfo', 
class name 'com.metamatrix.modelerweb.struts.
action.login.GetLoginInfoAction': 
java.lang.VerifyError: (class: 
com/metamatrix/modelerweb/struts/action/login/
GetLoginInfoAction, method: perfo
rm signature: 
(Lorg/apache/struts/action/ActionMapping;Lorg/ap
ache/struts/action/ActionForm;Ljavax/servlet/http
/HttpServletRequest;Ljavax/servle
t/http/HttpServletRespons -}

Note the strange characters at the end of the error 
message.  Almost like the class is not able to be 
read in for some reason.  I have recompiled this 
class and all classes in the project several times 
and have experienced this error every time i re-
deploy them in the Jboss environment.

I was not having this problem with an early version 
of jboss (jboss-3.0.1RC1 I believe) It occured as 
soon as I upgraded. 



--

Comment By: Steve Wolfangel (swolfangel)
Date: 2002-10-02 08:10

Message:
Logged In: YES 
user_id=541224

I think this may have been a packaging problem,  I am 
not seeing this error anymore, I also tested with 3.03 
and everything is fine. 

Re: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols inSELECT clause

[Hunter Hillegas]

I saw that it was Oracle specific, but I didn't see it mentioned that it
only kicked in when using the JBoss-QL order-by.

Also, I still think it would be useful to have it only kick in for databases
that require it... The behavior required by Oracle isn't part of the SQL
spec is it?

Hunter

 From: Emerson Cargnin - SICREDI Serviços [EMAIL PROTECTED]
 Organization: SICREDI
 Reply-To: [EMAIL PROTECTED]
 Date: Mon, 28 Oct 2002 17:57:24 -0200
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols in SELECT
 clause
 
 if you read carefully the above bug  you will see that it's a oracle
 issue, the solution here will not generate any orderby, but when it's
 used (jboss-ql order by) it uses the fields in orderby clause in the
 select [fiels] where ...
 
 Hunter Hillegas wrote:
 Will this be something that is configurable per datasource type or mandated
 in JBossCMP as the default? Will there be any way to tell JBoss *not* to add
 these order bys in the event we don't want them?
 
 Hunter
 
 
 From: [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 Date: Mon, 28 Oct 2002 11:57:13 -0800
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] [ jboss-Bugs-591835 ] Include ORDER BY cols in SELECT
 clause
 
 Bugs item #591835, was opened at 2002-08-06 22:46
 You can respond by visiting:
 https://sourceforge.net/tracker/?func=detailatid=376685aid=591835group_id
 =2
 2866
 
 Category: JBossCMP
 Group: v3.2
 Status: Open
 Resolution: Accepted
 Priority: 5
 Submitted By: Stephen Coy (scoy)
 Assigned to: Dain Sundstrom (dsundstrom)
 Summary: Include ORDER BY cols in SELECT clause
 
 Initial Comment:
 Some databases, Oracle in particular, require that columns named
 in an ORDER BY clause be included in the SELECT clause when
 SELECT DISTINCT is used.
 
 Here is some text from current Oracle documentation:
 
 Restrictions on the order_by_clause:
 
 *If you have specified the DISTINCT operator in this statement,
 then this clause cannot refer to columns unless they appear in the
 select list.
 
 *An order_by_clause can contain no more than 255 expressions.
 
 
 This can be worked around using on-find loading with load groups,
 but it sure would be useful if JBoss managed it for us.
 
 
 
 --
 
 Comment By: Emerson Cargnin (echofloripa)
 Date: 2002-10-28 17:57
 
 Message:
 Logged In: YES 
 user_id=378942
 
 the workaround is useless if I use a dynamic-ql, correct me
 if I'm wrong
 
 --
 
 Comment By: Emerson Cargnin (echofloripa)
 Date: 2002-10-15 16:23
 
 Message:
 Logged In: YES 
 user_id=378942
 
 For oracle users, this is really a showstopper bug. I'll try
 to undertand to (maybe) try to solve that : ) obs: i think
 it'll take too long to me to take this : )
 
 --
 
 Comment By: Dain Sundstrom (dsundstrom)
 Date: 2002-08-23 22:00
 
 Message:
 Logged In: YES 
 user_id=251431
 
 This is really a bug.
 
 --
 
 You can respond by visiting:
 https://sourceforge.net/tracker/?func=detailatid=376685aid=591835group_id
 =2
 2866
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 -- 
 
 | Emerson Cargnin  |
 | Analista de Sistemas Sr. |
 | Tel : (051) 3358-4959|
 | SICREDI Serviços |
 | Porto Alegre - Brasil|
 |xx|
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development