[JBoss-dev] [ jboss-Bugs-669650 ] ClassLoader Problem

[SourceForge.net]

Bugs item #669650, was opened at 2003-01-17 15:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669650&group_id=22866

Category: JBossMX
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Srivatsan (srivatsanp)
Assigned to: Nobody/Anonymous (nobody)
Summary: ClassLoader Problem

Initial Comment:
We have two applications,say Test.ear and Test1.ear 
both have some resource files packaged with them in 
the structure of

Test.ear
-dtd/test.dtd
Test1.ear
-dtd/test1.dtd

so when i tried to access this dtd/test.dtd from a class 
in Test1.ear i am not able to get the dtd. I am using 
this.getClass().getClassLoader().getResource
("dtd/test.dtd") method from a MBean Service (sar) 
which is present in Test1.ear. It returned null. 

On further analysis, we came to know that you are 
searching classes and resources based on package 
names. This might have introduced the issue of not able 
to access the dtd/test.dtd.since both the ear's have dtd 
dirs.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669650&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?

[Kevin Roast]

Hi,

I am interested to know if the following is a known Jboss+AXIS bug:

We are testing a system using Jboss3.0.4 using the standard embedded
version of AXIS. We are using SOAP calls for our web services which AXIS
is parsing using the system XML parser. By default this is Xerces which
is fine. However, if I change the parser factory to use Oracle XDK 9
parser then I receive an error from the AXIS SAX parsing thus:


java.lang.StringIndexOutOfBoundsException: String index out of range:
323
at java.lang.String.(String.java:245)
at
org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121)
at
org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j
ava:137)
at
org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali
zationContextImpl.java:771)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
213)
at
org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:578)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParams(RPCElement.java:231)
at org.apache.axis.client.Call.invoke(Call.java:1605)


I have inspected the SOAP being parsed and SAX parsed it myself using
both Xerces and Oracle XDK and it parses fine. This leads me to believe
that AXIS is doing something naughty in the SAX "characters()" event
method i.e. maybe not respecting the start/len parameters? (I'm guessing
here from the error)

Anyone have any thoughts on this, or I am in completely the wrong ball
park?


Also - can anyone confirm which version of AXIS is built into Jboss? As
I posted this bug to the AXIS-Bug list and they said this particular
method no longer exists in the current source line. If possible, I am
happy to upgrade the version of AXIS in Jboss - can this be done?

Thanks for your time,

Kevin


---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?

[Jung , Dr. Christoph]

The axis version in the 3.0 branch is a beta.

>From 3.2 on, we have axis release 1 (it is no more located in the system lib
directory, but an integral part of the
jboss.net sar)

In head, we have axis 1.1beta integrated.

Since you seem not to use jboss.net, why don´t you simply update the jar in
your 3.0 distro? 

If you want the nice deployment/security features of jboss.net, however, I
recommend obtaining 3.2RCwhatever.

CGJ


-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 10:55
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


Hi,

I am interested to know if the following is a known Jboss+AXIS bug:

We are testing a system using Jboss3.0.4 using the standard embedded version
of AXIS. We are using SOAP calls for our web services which AXIS is parsing
using the system XML parser. By default this is Xerces which is fine.
However, if I change the parser factory to use Oracle XDK 9 parser then I
receive an error from the AXIS SAX parsing thus:


java.lang.StringIndexOutOfBoundsException: String index out of range: 323
at java.lang.String.(String.java:245)
at
org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121)
at
org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j
ava:137)
at
org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali
zationContextImpl.java:771)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
213)
at
org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:578)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParams(RPCElement.java:231)
at org.apache.axis.client.Call.invoke(Call.java:1605)


I have inspected the SOAP being parsed and SAX parsed it myself using both
Xerces and Oracle XDK and it parses fine. This leads me to believe that AXIS
is doing something naughty in the SAX "characters()" event method i.e. maybe
not respecting the start/len parameters? (I'm guessing here from the error)

Anyone have any thoughts on this, or I am in completely the wrong ball park?


Also - can anyone confirm which version of AXIS is built into Jboss? As I
posted this bug to the AXIS-Bug list and they said this particular method no
longer exists in the current source line. If possible, I am happy to upgrade
the version of AXIS in Jboss - can this be done?

Thanks for your time,

Kevin


---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by
implementing SSL on your Apache Web Server. Click here to get our FREE
Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###

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


---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Feature Requests-669701 ] JBoss IDE

[SourceForge.net]

Feature Requests item #669701, was opened at 2003-01-17 12:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376688&aid=669701&group_id=22866

Category: Other
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sanjib Karmakar (sanjibmail)
Assigned to: Nobody/Anonymous (nobody)
Summary: JBoss IDE

Initial Comment:
Dear friends,

I am a new account holder. Last few months I am 
working on JBoss 3.0 . 
I do not know whether you have faced the same 
problem that i have faced, JBoss does not have ant 
IDE. It is really very much  complecated create a 
simple bean.
Without having any IDE I think JBoss is not yet 
completed.
Any way I have personally created an IDE for 
Winodws development, using that bean creation 
will be much easier, though it is not yet completed,
still I would like to make it available for every user 
of JBoss,Jakarta ANT and Xdoclet.
Please tell me whome should I talk to of JBoss 
organization.

I am available at [EMAIL PROTECTED] or 
[EMAIL PROTECTED]

Regards

Sanjib Karmakar


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376688&aid=669701&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-668291 ] Jasper in release 3.0.5 is

[SourceForge.net]

Bugs item #668291, was opened at 2003-01-15 13:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=668291&group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Brian Bannister (beoch)
Assigned to: Jules Gosnell (jules_gosnell)
Summary: Jasper in release 3.0.5 is 

Initial Comment:
Windows 2000 
JDK 1.4.1_01
JBoss 3.0.5

I'm getting JSP compile errors that do not occur in 
JBoss 3.0.4. Jasper complains that it can't find a class 
that is definately in the deployed war. Using the same 
ear on JBoss 3.0.4 I get no problems.

The traces from JBoss-3.0.5 and JBoss-3.0.4 are 
attached, as well as the war manifest showing the class 
that Jasper can't find.

The exception thrown is:


Time: 13:42:55  Priority: WARN  Thread: PoolThread-
4  NDC: null Category: org.jboss.jbossweb Location: 
org.jboss.logging.Logger.warn(Logger.java:167) 
Message:
WARNING: Exception for 
http://192.223.0.59:8080/itochu/newsticker/view/45/dyna
micMedia/x-news-ticker.jsp
org.apache.jasper.JasperException: Unable to compile 
class for JSPNote: sun.tools.javac.Main has been 
deprecated.


An error occurred at line: 2 in the jsp 
file: /45/dynamicMedia/x-news-ticker.jsp

Generated servlet error:
C:\DOCUME~1\brianb\LOCALS~1
\Temp\Jetty_0_0_0_0_8080__itochu_newsticker\45
\dynamicMedia\x_0002dnews_0002dticker$jsp.java:65: 
Class 
com.activesky.itochu.newsticker.view.NewsTickerView 
not found.

com.activesky.itochu.newsticker.view.NewsTickerView 
viewParameter = null;
^


An error occurred at line: 2 in the jsp 
file: /45/dynamicMedia/x-news-ticker.jsp

Generated servlet error:
C:\DOCUME~1\brianb\LOCALS~1
\Temp\Jetty_0_0_0_0_8080__itochu_newsticker\45
\dynamicMedia\x_0002dnews_0002dticker$jsp.java:68: 
Class 
com.activesky.itochu.newsticker.view.NewsTickerView 
not found.
  viewParameter= 
(com.activesky.itochu.newsticker.view.NewsTickerView)
  ^


An error occurred at line: 2 in the jsp 
file: /45/dynamicMedia/x-news-ticker.jsp

Generated servlet error:
C:\DOCUME~1\brianb\LOCALS~1
\Temp\Jetty_0_0_0_0_8080__itochu_newsticker\45
\dynamicMedia\x_0002dnews_0002dticker$jsp.java:73: 
Class 
com.activesky.itochu.newsticker.view.NewsTickerView 
not found.
  viewParameter = 
(com.activesky.itochu.newsticker.view.NewsTickerView) 
java.beans.Beans.instantiate(this.getClass
().getClassLoader
(), "com.activesky.itochu.newsticker.view.NewsTickerVie
w");
   ^
3 errors, 1 warning

at 
org.apache.jasper.compiler.Compiler.compile
(Compiler.java:289)
at 
org.apache.jasper.servlet.JspServlet.loadJSP
(JspServlet.java:548)
at 
org.apache.jasper.servlet.JspServlet$JspServletWrapper.l
oadIfNecessary(JspServlet.java:176)
at 
org.apache.jasper.servlet.JspServlet$JspServletWrapper.
service(JspServlet.java:188)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:381)
at org.apache.jasper.servlet.JspServlet.service
(JspServlet.java:473)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at 
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at 
org.mortbay.jetty.servlet.WebApplicationHandler.dispatc
h(WebApplicationHandler.java:280)
at 
org.mortbay.jetty.servlet.Dispatcher.dispatch
(Dispatcher.java:194)
at org.mortbay.jetty.servlet.Dispatcher.forward
(Dispatcher.java:129)
at 
com.activesky.servlet.FrontController.doGet
(FrontController.java:46)
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:360)
at 
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.d
oFilter(WebApplicationHandler.java:328)
at 
com.activesky.aserver.mbroker.MediaBrokerFilter.doFilte
r(MediaBrokerFilter.java:138)
at 
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.d
oFilter(WebApplicationHandler.java:320)
at 
org.mortbay.jetty.servlet.WebApplicationHandler.dispatc
h(WebApplicationHandler.java:272)
at 
org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:553)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1656)
at 
org.mortbay.jetty.servlet.WebApplicationContext.handle
(WebApplicationContext.java:549)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1606)
at org.mortbay.http.HttpServer.service
(HttpServer.java:862)
at org.jboss.jetty.Jetty.service(Jetty.java:497)
at org.mortbay.http.HttpConnection.service
(HttpConnection.java:752)
at 
org.mortbay.http.HttpConnection.handleNext
(HttpConnection.java:916)
at org.mortbay.http.HttpConnection.hand

RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?

[Kevin Roast]

Hi,

Thanks for your reply. Unfortuntely simply upgrading the JAR does not work :( My 
investigation leads me to believe that parts of the Jboss3.0 AXIS integration (in 
jboss-net.sar?) would need to be re-compiled against the newew AXIS jar to work. For 
instance, I get this exception when starting Jboss:

13:34:48,166 ERROR [URLDeploymentScanner]
Failed to deploy: 
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@45bb4fb6{ 
url=file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/, deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not create deployment: 
file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/; - nested throwable: 
(java.lang.IllegalAccessError: try to access field 
org.apache.axis.configuration.FileProvider.myInputStream from class 
org.jboss.net.axis.XMLResourceProvider)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827)


I'll take a look at 3.2RC1 and see if it fixes the problem...

Kev

-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] 
Sent: 17 January 2003 10:34
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


The axis version in the 3.0 branch is a beta.

>From 3.2 on, we have axis release 1 (it is no more located in the system lib 
>directory, but an integral part of the jboss.net sar)

In head, we have axis 1.1beta integrated.

Since you seem not to use jboss.net, why don´t you simply update the jar in your 3.0 
distro? 

If you want the nice deployment/security features of jboss.net, however, I recommend 
obtaining 3.2RCwhatever.

CGJ


-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 10:55
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


Hi,

I am interested to know if the following is a known Jboss+AXIS bug:

We are testing a system using Jboss3.0.4 using the standard embedded version of AXIS. 
We are using SOAP calls for our web services which AXIS is parsing using the system 
XML parser. By default this is Xerces which is fine. However, if I change the parser 
factory to use Oracle XDK 9 parser then I receive an error from the AXIS SAX parsing 
thus:


java.lang.StringIndexOutOfBoundsException: String index out of range: 323
at java.lang.String.(String.java:245)
at
org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121)
at org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j
ava:137)
at org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali
zationContextImpl.java:771)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
213)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:578)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParams(RPCElement.java:231)
at org.apache.axis.client.Call.invoke(Call.java:1605)


I have inspected the SOAP being parsed and SAX parsed it myself using both Xerces and 
Oracle XDK and it parses fine. This leads me to believe that AXIS is doing something 
naughty in the SAX "characters()" event method i.e. maybe not respecting the start/len 
parameters? (I'm guessing here from the error)

Anyone have any thoughts on this, or I am in completely the wrong ball park?


Also - can anyone confirm which version of AXIS is built into Jboss? As I posted this 
bug to the AXIS-Bug list and they said this particular method no longer exists in the 
current source line. If possible, I am happy to upgrade the version of AXIS in Jboss - 
can this be done?

Thanks for your time,

Kevin



---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-669731 ] res-auth case problem

[SourceForge.net]

Bugs item #669731, was opened at 2003-01-17 14:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669731&group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Laurent Etiemble (letiemble)
Assigned to: Nobody/Anonymous (nobody)
Summary: res-auth case problem

Initial Comment:
A web application compliant with the 2.2 servlet specs and which contains :
   ...
   
  ...
  ...
  CONTAINER
   
   ...
will not deploy successfully.

According to the Servlet Specs 2.2 (Section 13.2) the  tag in a web 
descriptor can only contain "CONTAINER" or "SERVLET".
According to the Servlet Specs 2.3 (Section 13.3) the  tag in a web 
descriptor can only contain "Container" or "Application".

The org.jboss.metadata.ResourceRefMetaData class only accepts "Container" or 
"Application" values, that's why the deployment of a 2.2 compliant web application 
containing  tags will failed.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669731&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-669733 ] URL Resource-ref not possible in a WebApp

[SourceForge.net]

Bugs item #669733, was opened at 2003-01-17 14:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669733&group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Laurent Etiemble (letiemble)
Assigned to: Nobody/Anonymous (nobody)
Summary: URL Resource-ref not possible in a WebApp

Initial Comment:
URL Resource-ref cannot be declared successfully in a WebApplication.
I have the following in my web descriptor :

   ...
   
  url/urlData
  java.net.URL
  Container
   
   ...


And the following in my jboss-web descriptor :

   ...
   
  url/urlData
  http://orange-mibwas01:18080/Customers/CustomersIndex
   
   ...


When I deploy the webapp it leads to a DeploymentException.

If I change my jboss-web by removing the DTD reference and the content to :

   ...
   
  url/urlData
  http://localhost:8080/Data
   
   ...

It deploys fine.

The exception is raised in the org.jboss.metadata.ResourceRefMetaData class. When 
declaring an URL resource-ref, the searched tag is  and not .
To enable URL Resource-ref, modifiy the definition of a resource-ref in jboss-web DTD 
to accept jndi-name OR res-url as child of resource-ref.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669733&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?

[Jung , Dr. Christoph]

If you do not use jboss-net, simply delete the sar.

CGJ

-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 14:44
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?


Hi,

Thanks for your reply. Unfortuntely simply upgrading the JAR does not work
:( My investigation leads me to believe that parts of the Jboss3.0 AXIS
integration (in jboss-net.sar?) would need to be re-compiled against the
newew AXIS jar to work. For instance, I get this exception when starting
Jboss:

13:34:48,166 ERROR [URLDeploymentScanner]
Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@45bb4fb6{
url=file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not create deployment:
file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/; - nested throwable:
(java.lang.IllegalAccessError: try to access field
org.apache.axis.configuration.FileProvider.myInputStream from class
org.jboss.net.axis.XMLResourceProvider)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827)


I'll take a look at 3.2RC1 and see if it fixes the problem...

Kev

-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] 
Sent: 17 January 2003 10:34
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?


The axis version in the 3.0 branch is a beta.

>From 3.2 on, we have axis release 1 (it is no more located in the system lib
directory, but an integral part of the jboss.net sar)

In head, we have axis 1.1beta integrated.

Since you seem not to use jboss.net, why don´t you simply update the jar in
your 3.0 distro? 

If you want the nice deployment/security features of jboss.net, however, I
recommend obtaining 3.2RCwhatever.

CGJ


-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 10:55
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


Hi,

I am interested to know if the following is a known Jboss+AXIS bug:

We are testing a system using Jboss3.0.4 using the standard embedded version
of AXIS. We are using SOAP calls for our web services which AXIS is parsing
using the system XML parser. By default this is Xerces which is fine.
However, if I change the parser factory to use Oracle XDK 9 parser then I
receive an error from the AXIS SAX parsing thus:


java.lang.StringIndexOutOfBoundsException: String index out of range: 323
at java.lang.String.(String.java:245)
at
org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121)
at
org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j
ava:137)
at
org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali
zationContextImpl.java:771)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
213)
at
org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:578)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParams(RPCElement.java:231)
at org.apache.axis.client.Call.invoke(Call.java:1605)


I have inspected the SOAP being parsed and SAX parsed it myself using both
Xerces and Oracle XDK and it parses fine. This leads me to believe that AXIS
is doing something naughty in the SAX "characters()" event method i.e. maybe
not respecting the start/len parameters? (I'm guessing here from the error)

Anyone have any thoughts on this, or I am in completely the wrong ball park?


Also - can anyone confirm which version of AXIS is built into Jboss? As I
posted this bug to the AXIS-Bug list and they said this particular method no
longer exists in the current source line. If possible, I am happy to upgrade
the version of AXIS in Jboss - can this be done?

Thanks for your time,

Kevin



---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by
implementing SSL on your Apache Web Server. Click here to get our FREE
Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###

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


---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redire

Re: [JBoss-dev] Main is not building

[David Jencks]

WIth current xdoclet, you have to be VERY CAREFUL TO IMPORT ALL CLASSES  
ONE BY ONE AND NEVER EVER USE A import ...*;  Doing this in one class  
can easily mess up xdoclets class resolving and result in MANY OTHER  
generated classes not fully qualifying their class names.  I suspect  
this has happened here, but don't have the latest source with me to  
check.

david jencks
On Thursday, January 16, 2003, at 04:47 AM, Scott M Stark wrote:

The server module in jboss-head is not currently building:

[javac]  
C:\usr\Main\jboss- 
head\server\output\gen\classes\org\jboss\invocation\trunk\client\Connec 
tionManagerMBean.java:9:
cannot resolve symbol
[javac] symbol  : class ServiceMBean
[javac] location: interface  
org.jboss.invocation.trunk.client.ConnectionManagerMBean
[javac] public interface ConnectionManagerMBean extends  
ServiceMBean {
[javac] ^
[javac]  
C:\usr\Main\jboss- 
head\server\output\gen\classes\org\jboss\invocation\trunk\client\TrunkI 
nvokerProxyMBean.java:9:
cannot resolve symbol
[javac] symbol  : class ServiceMBean
[javac] location: interface  
org.jboss.invocation.trunk.client.TrunkInvokerPr
oxyMBean
[javac] public interface TrunkInvokerProxyMBean extends  
ServiceMBean {
[javac] ^
[javac]  
C:\usr\Main\jboss- 
head\server\output\gen\classes\org\jboss\proxy\ProxyXAResourceMBean.jav 
a:9: cannot resolve
symbol
[javac] symbol  : class ServiceMBean
[javac] location: interface org.jboss.proxy.ProxyXAResourceMBean
[javac] public interface ProxyXAResourceMBean extends ServiceMBean  
{
[javac]   ^
[javac]  
C:\usr\Main\jboss-head\server\src\main\org\jboss\ejb\EnterpriseConte


Scott Stark
Chief Technology Officer
JBoss Group, LLC




---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by  
implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?

[Kevin Roast]

Sorry, I'm a little confused here. How does Jboss integrate with AXIS? If I delete the 
SAR will AXIS work? Currently the AXIS service URL doesn't work if I upgrade the 
version of AXIS in Jboss 3.0.

Kev


-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] 
Sent: 17 January 2003 14:03
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


If you do not use jboss-net, simply delete the sar.

CGJ

-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 14:44
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


Hi,

Thanks for your reply. Unfortuntely simply upgrading the JAR does not work :( My 
investigation leads me to believe that parts of the Jboss3.0 AXIS integration (in 
jboss-net.sar?) would need to be re-compiled against the newew AXIS jar to work. For 
instance, I get this exception when starting
Jboss:

13:34:48,166 ERROR [URLDeploymentScanner]
Failed to deploy: 
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@45bb4fb6{
url=file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not create deployment: 
file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/; - nested throwable:
(java.lang.IllegalAccessError: try to access field 
org.apache.axis.configuration.FileProvider.myInputStream from class
org.jboss.net.axis.XMLResourceProvider)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827)


I'll take a look at 3.2RC1 and see if it fixes the problem...

Kev

-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] 
Sent: 17 January 2003 10:34
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


The axis version in the 3.0 branch is a beta.

>From 3.2 on, we have axis release 1 (it is no more located in the system lib 
>directory, but an integral part of the jboss.net sar)

In head, we have axis 1.1beta integrated.

Since you seem not to use jboss.net, why don´t you simply update the jar in your 3.0 
distro? 

If you want the nice deployment/security features of jboss.net, however, I recommend 
obtaining 3.2RCwhatever.

CGJ


-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 10:55
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


Hi,

I am interested to know if the following is a known Jboss+AXIS bug:

We are testing a system using Jboss3.0.4 using the standard embedded version of AXIS. 
We are using SOAP calls for our web services which AXIS is parsing using the system 
XML parser. By default this is Xerces which is fine. However, if I change the parser 
factory to use Oracle XDK 9 parser then I receive an error from the AXIS SAX parsing 
thus:


java.lang.StringIndexOutOfBoundsException: String index out of range: 323
at java.lang.String.(String.java:245)
at
org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121)
at org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j
ava:137)
at org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali
zationContextImpl.java:771)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
213)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:578)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParams(RPCElement.java:231)
at org.apache.axis.client.Call.invoke(Call.java:1605)


I have inspected the SOAP being parsed and SAX parsed it myself using both Xerces and 
Oracle XDK and it parses fine. This leads me to believe that AXIS is doing something 
naughty in the SAX "characters()" event method i.e. maybe not respecting the start/len 
parameters? (I'm guessing here from the error)

Anyone have any thoughts on this, or I am in completely the wrong ball park?


Also - can anyone confirm which version of AXIS is built into Jboss? As I posted this 
bug to the AXIS-Bug list and they said this particular method no longer exists in the 
current source line. If possible, I am happy to upgrade the version of AXIS in Jboss - 
can this be done?

Thanks for your time,

Kevin



---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing SSL on 
your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Main is not building

[Matt Munz]

> WIth current xdoclet, you have to be VERY CAREFUL TO IMPORT ALL CLASSES  
> ONE BY ONE AND NEVER EVER USE A import ...*;  Doing this in one class  
> can easily mess up xdoclets class resolving and result in MANY OTHER  
> generated classes not fully qualifying their class names.  I suspect  
> this has happened here, but don't have the latest source with me to  
> check.

I'm not an xdoclet user (yet), but may I suggest that the xdoclet parser be modified 
to throw an exception (fail) the instant it encounters the first "import...*;"?
 
I have found that this use of errors to keep the user in line can be quite beneficial. 
 
 
  - Matt 

-Original Message- 
From: David Jencks [mailto:[EMAIL PROTECTED]] 
Sent: Fri 1/17/2003 9:10 AM 
To: [EMAIL PROTECTED] 
Cc: 
Subject: Re: [JBoss-dev] Main is not building



WIth current xdoclet, you have to be VERY CAREFUL TO IMPORT ALL CLASSES 
ONE BY ONE AND NEVER EVER USE A import ...*;  Doing this in one class 
can easily mess up xdoclets class resolving and result in MANY OTHER 
generated classes not fully qualifying their class names.  I suspect 
this has happened here, but don't have the latest source with me to 
check.

david jencks
On Thursday, January 16, 2003, at 04:47 AM, Scott M Stark wrote:

> The server module in jboss-head is not currently building:
>
> [javac] 
> C:\usr\Main\jboss-
> head\server\output\gen\classes\org\jboss\invocation\trunk\client\Connec
> tionManagerMBean.java:9:
> cannot resolve symbol
> [javac] symbol  : class ServiceMBean
> [javac] location: interface 
> org.jboss.invocation.trunk.client.ConnectionManagerMBean
> [javac] public interface ConnectionManagerMBean extends 
> ServiceMBean {
> [javac] ^
> [javac] 
> C:\usr\Main\jboss-
> head\server\output\gen\classes\org\jboss\invocation\trunk\client\TrunkI
> nvokerProxyMBean.java:9:
> cannot resolve symbol
> [javac] symbol  : class ServiceMBean
> [javac] location: interface 
> org.jboss.invocation.trunk.client.TrunkInvokerPr
> oxyMBean
> [javac] public interface TrunkInvokerProxyMBean extends 
> ServiceMBean {
> [javac] ^
> [javac] 
> C:\usr\Main\jboss-
> head\server\output\gen\classes\org\jboss\proxy\ProxyXAResourceMBean.jav
> a:9: cannot resolve
> symbol
> [javac] symbol  : class ServiceMBean
> [javac] location: interface org.jboss.proxy.ProxyXAResourceMBean
> [javac] public interface ProxyXAResourceMBean extends ServiceMBean 
> {
> [javac]   ^
> [javac] 
> C:\usr\Main\jboss-head\server\src\main\org\jboss\ejb\EnterpriseConte
>
> 
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> 
>
>
>
> ---
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by 
> implementing
> SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
> Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>



---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



<>

AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?

[Jung , Dr. Christoph]

You can install axis in jboss as you would do in any other application
server: simply deploy it 
(and the web service logic+axis deployment descriptors) as a big
web-application.

Jboss-net is glue code that integrates axis a bit more sophisticated, namely
as a 
web service archive (wsr) deployer. A wsr is a jar that contains your web
service logic 
as well as the corresponding axis deployment descriptor.

Now I am confused: How do you deploy your web services after startup? Of
course, I recommend using jboss.net
Hence upgrading to 3.2 ...
 

CGJ


-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 15:52
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?


Sorry, I'm a little confused here. How does Jboss integrate with AXIS? If I
delete the SAR will AXIS work? Currently the AXIS service URL doesn't work
if I upgrade the version of AXIS in Jboss 3.0.

Kev


-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] 
Sent: 17 January 2003 14:03
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?


If you do not use jboss-net, simply delete the sar.

CGJ

-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 14:44
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?


Hi,

Thanks for your reply. Unfortuntely simply upgrading the JAR does not work
:( My investigation leads me to believe that parts of the Jboss3.0 AXIS
integration (in jboss-net.sar?) would need to be re-compiled against the
newew AXIS jar to work. For instance, I get this exception when starting
Jboss:

13:34:48,166 ERROR [URLDeploymentScanner]
Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@45bb4fb6{
url=file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not create deployment:
file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/; - nested throwable:
(java.lang.IllegalAccessError: try to access field
org.apache.axis.configuration.FileProvider.myInputStream from class
org.jboss.net.axis.XMLResourceProvider)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827)


I'll take a look at 3.2RC1 and see if it fixes the problem...

Kev

-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] 
Sent: 17 January 2003 10:34
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?


The axis version in the 3.0 branch is a beta.

>From 3.2 on, we have axis release 1 (it is no more located in the system lib
directory, but an integral part of the jboss.net sar)

In head, we have axis 1.1beta integrated.

Since you seem not to use jboss.net, why don´t you simply update the jar in
your 3.0 distro? 

If you want the nice deployment/security features of jboss.net, however, I
recommend obtaining 3.2RCwhatever.

CGJ


-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 10:55
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


Hi,

I am interested to know if the following is a known Jboss+AXIS bug:

We are testing a system using Jboss3.0.4 using the standard embedded version
of AXIS. We are using SOAP calls for our web services which AXIS is parsing
using the system XML parser. By default this is Xerces which is fine.
However, if I change the parser factory to use Oracle XDK 9 parser then I
receive an error from the AXIS SAX parsing thus:


java.lang.StringIndexOutOfBoundsException: String index out of range: 323
at java.lang.String.(String.java:245)
at
org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121)
at
org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j
ava:137)
at
org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali
zationContextImpl.java:771)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
213)
at
org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:578)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParams(RPCElement.java:231)
at org.apache.axis.client.Call.invoke(Call.java:1605)


I have inspected the SOAP being parsed and SAX parsed it myself using both
Xerces and Oracle XDK and it parses fine. This leads me to believe that AXIS
is doing something naughty in the SAX "characters()" event method i.e. maybe
not respecting the start/len parameters? (I'm guessing here from the error)

Anyone have any thoughts on this, or I am in completely the wrong ball park?


Also - can anyone confirm which version of AXIS is built into Jboss? As I

RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?

[Kevin Roast]

Hi,

OK I'll try that. I wasn't sure that I would be able to drop in AXIS as a web 
application if Jboss already had it's own specific integration - but from what you are 
saying it should work.

We drop our EAR files into the deploy dir like everyone else ;) I was confused for the 
above reason.

Thanks,

Kev


-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] 
Sent: 17 January 2003 15:15
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


You can install axis in jboss as you would do in any other application
server: simply deploy it 
(and the web service logic+axis deployment descriptors) as a big web-application.

Jboss-net is glue code that integrates axis a bit more sophisticated, namely as a 
web service archive (wsr) deployer. A wsr is a jar that contains your web service 
logic 
as well as the corresponding axis deployment descriptor.

Now I am confused: How do you deploy your web services after startup? Of course, I 
recommend using jboss.net Hence upgrading to 3.2 ...
 

CGJ


-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 15:52
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


Sorry, I'm a little confused here. How does Jboss integrate with AXIS? If I delete the 
SAR will AXIS work? Currently the AXIS service URL doesn't work if I upgrade the 
version of AXIS in Jboss 3.0.

Kev


-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] 
Sent: 17 January 2003 14:03
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


If you do not use jboss-net, simply delete the sar.

CGJ

-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 14:44
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


Hi,

Thanks for your reply. Unfortuntely simply upgrading the JAR does not work :( My 
investigation leads me to believe that parts of the Jboss3.0 AXIS integration (in 
jboss-net.sar?) would need to be re-compiled against the newew AXIS jar to work. For 
instance, I get this exception when starting
Jboss:

13:34:48,166 ERROR [URLDeploymentScanner]
Failed to deploy: 
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@45bb4fb6{
url=file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not create deployment: 
file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/; - nested throwable:
(java.lang.IllegalAccessError: try to access field 
org.apache.axis.configuration.FileProvider.myInputStream from class
org.jboss.net.axis.XMLResourceProvider)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827)


I'll take a look at 3.2RC1 and see if it fixes the problem...

Kev

-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] 
Sent: 17 January 2003 10:34
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


The axis version in the 3.0 branch is a beta.

>From 3.2 on, we have axis release 1 (it is no more located in the system lib 
>directory, but an integral part of the jboss.net sar)

In head, we have axis 1.1beta integrated.

Since you seem not to use jboss.net, why don´t you simply update the jar in your 3.0 
distro? 

If you want the nice deployment/security features of jboss.net, however, I recommend 
obtaining 3.2RCwhatever.

CGJ


-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 17. Januar 2003 10:55
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?


Hi,

I am interested to know if the following is a known Jboss+AXIS bug:

We are testing a system using Jboss3.0.4 using the standard embedded version of AXIS. 
We are using SOAP calls for our web services which AXIS is parsing using the system 
XML parser. By default this is Xerces which is fine. However, if I change the parser 
factory to use Oracle XDK 9 parser then I receive an error from the AXIS SAX parsing 
thus:


java.lang.StringIndexOutOfBoundsException: String index out of range: 323
at java.lang.String.(String.java:245)
at
org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121)
at org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j
ava:137)
at org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali
zationContextImpl.java:771)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
213)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:578)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParam

[JBoss-dev] Finders, Selectors and ... deleters?

[Stefan Arentz]

I was thinking about something  while looking at my application's 
database behaviour... in many cases it is very inefficient to use a 
finder method together with remove() for large collections. It would be 
so much more efficient to have something like

  public int deleteByCode(int code);

 
   deleteByCode
   
   int
   
   
 delete from Transactions t where t.code = ?1
   
 

This all of course integrated with the cache so that it invalidates 
objects that are already loaded, etc.

I'm just toying around with ideas here.

Stefan, wishes he had fulltime to work on things like this :-/




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Finders, Selectors and ... deleters?

[Jeremy Boynes]

> I was thinking about something  while looking at my application's
> database behaviour... in many cases it is very inefficient to use a
> finder method together with remove() for large collections. It would be
> so much more efficient to have something like
>
>public int deleteByCode(int code);
>
>   
> deleteByCode
> 
> int
> 
> 
>   delete from Transactions t where t.code = ?1
> 
>   
>
> This all of course integrated with the cache so that it invalidates
> objects that are already loaded, etc.
>

This is the same semantic (i.e. remove a load of stuff :-) that we need to
improve to make  efficient. I would be fairly easy to extend
that to user-defined operations.

I'm against adding delete (or insert and update) semantics to JBoss-QL
though - that changes the nature of the language from read-only to
read-write.

Instead you could define a DeleteMethod as:

  
deleteByCode

int

where code = ?1
  

or, using values from the another entity via a subquery

  
deleteByCode

int


  where code in
(select x.code from another x where x.flag = ?1)

  

This leaves the JBoss-QL part read-only (it just qualifies the instances to
be deleted). We know we're deleting Transactions as the method would be on
the home interface for the Transaction EJB.

It would be easy enough to extend this to bulk update as well - ok, easy if
you limited the update to single-valued fields.

Bulk create would be harder (need to pass in a lot of data), and probably
unnecessary given we plan to have batch insert anyway.



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re[2]: [JBoss-dev] Finders, Selectors and ... deleters?

[Alex Loubyansky]

Jeremy,

as I remember, once we already considered delete and update operations
in JBossQL. This is great because we don't depend on the specific
database. I thought this was planned for 4.0.

alex

Friday, January 17, 2003, 7:08:43 PM, you wrote:

>> I was thinking about something  while looking at my application's
>> database behaviour... in many cases it is very inefficient to use a
>> finder method together with remove() for large collections. It would be
>> so much more efficient to have something like
>>
>>public int deleteByCode(int code);
>>
>>   
>> deleteByCode
>> 
>> int
>> 
>> 
>>   delete from Transactions t where t.code = ?1
>> 
>>   
>>
>> This all of course integrated with the cache so that it invalidates
>> objects that are already loaded, etc.
>>

JB> This is the same semantic (i.e. remove a load of stuff :-) that we need to
JB> improve to make  efficient. I would be fairly easy to extend
JB> that to user-defined operations.

JB> I'm against adding delete (or insert and update) semantics to JBoss-QL
JB> though - that changes the nature of the language from read-only to
JB> read-write.

JB> Instead you could define a DeleteMethod as:

JB>   
JB> deleteByCode
JB> 
JB> int
JB> 
JB> where code = ?1
JB>   

JB> or, using values from the another entity via a subquery

JB>   
JB> deleteByCode
JB> 
JB> int
JB> 
JB> 
JB>   where code in
JB> (select x.code from another x where x.flag = ?1)
JB> 
JB>   

JB> This leaves the JBoss-QL part read-only (it just qualifies the instances to
JB> be deleted). We know we're deleting Transactions as the method would be on
JB> the home interface for the Transaction EJB.

JB> It would be easy enough to extend this to bulk update as well - ok, easy if
JB> you limited the update to single-valued fields.

JB> Bulk create would be harder (need to pass in a lot of data), and probably
JB> unnecessary given we plan to have batch insert anyway.




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Finders, Selectors and ... deleters?

[Dain Sundstrom]

On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote:


This leaves the JBoss-QL part read-only (it just qualifies the 
instances to
be deleted). We know we're deleting Transactions as the method would 
be on
the home interface for the Transaction EJB.

I think we should support a full CRUD language.  Specifically, I mean 
that the user should not be restricted to just specifying the WHERE 
clause, but they should be required to specify a DELETE clause also.  
Then we just put in a restriction that a remove method on the home 
interface is only allowed to remove entities of the current type.  This 
is the same restriction finders have.

The reason I think we should have a full CRUD language is it allows an 
ejbSelect style method (although we may call it something else) to 
delete any set of objects with a single operation.  This will be 
particularly useful to delete a subset of related objects.

-dain



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Finders, Selectors and ... deleters?

[Bill Burke]

Please archive this on the Persistence forum.  Thanks guys.

Bill

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
> Sundstrom
> Sent: Friday, January 17, 2003 1:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters?
>
>
> On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote:
>
> > This leaves the JBoss-QL part read-only (it just qualifies the
> > instances to
> > be deleted). We know we're deleting Transactions as the method would
> > be on
> > the home interface for the Transaction EJB.
>
> I think we should support a full CRUD language.  Specifically, I mean
> that the user should not be restricted to just specifying the WHERE
> clause, but they should be required to specify a DELETE clause also.
> Then we just put in a restriction that a remove method on the home
> interface is only allowed to remove entities of the current type.  This
> is the same restriction finders have.
>
> The reason I think we should have a full CRUD language is it allows an
> ejbSelect style method (although we may call it something else) to
> delete any set of objects with a single operation.  This will be
> particularly useful to delete a subset of related objects.
>
> -dain
>
>
>
> ---
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
> allow you to extend the highest allowed 128 bit encryption to all your
> clients even if they use browsers that are limited to 40 bit encryption.
> Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Finders, Selectors and ... deleters?

[Jeremy Boynes]

I opened a topic with the title "Should we just use SQL-99 for JBoss-QL?"

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bill
> Burke
> Sent: Friday, January 17, 2003 10:24 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] Finders, Selectors and ... deleters?
>
>
> Please archive this on the Persistence forum.  Thanks guys.
>
> Bill
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
> > Sundstrom
> > Sent: Friday, January 17, 2003 1:14 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters?
> >
> >
> > On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote:
> >
> > > This leaves the JBoss-QL part read-only (it just qualifies the
> > > instances to
> > > be deleted). We know we're deleting Transactions as the method would
> > > be on
> > > the home interface for the Transaction EJB.
> >
> > I think we should support a full CRUD language.  Specifically, I mean
> > that the user should not be restricted to just specifying the WHERE
> > clause, but they should be required to specify a DELETE clause also.
> > Then we just put in a restriction that a remove method on the home
> > interface is only allowed to remove entities of the current type.  This
> > is the same restriction finders have.
> >
> > The reason I think we should have a full CRUD language is it allows an
> > ejbSelect style method (although we may call it something else) to
> > delete any set of objects with a single operation.  This will be
> > particularly useful to delete a subset of related objects.
> >
> > -dain
> >
> >
> >
> > ---
> > This SF.NET email is sponsored by: Thawte.com - A 128-bit
> supercerts will
> > allow you to extend the highest allowed 128 bit encryption to all your
> > clients even if they use browsers that are limited to 40 bit encryption.
> > Get a guide
> here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ---
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
> allow you to extend the highest allowed 128 bit encryption to all your
> clients even if they use browsers that are limited to 40 bit encryption.
> Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Finders, Selectors and ... deleters?

[Dain Sundstrom]

It is already in the JBoss 4.0 task list.

http://sourceforge.net/pm/ 
task.php?func=detailtask&project_task_id=68960&group_id=22866&group_proj 
ect_id=15043

-dain

On Friday, January 17, 2003, at 12:23 PM, Bill Burke wrote:

Please archive this on the Persistence forum.  Thanks guys.

Bill


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of  
Dain
Sundstrom
Sent: Friday, January 17, 2003 1:14 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters?


On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote:

This leaves the JBoss-QL part read-only (it just qualifies the
instances to
be deleted). We know we're deleting Transactions as the method would
be on
the home interface for the Transaction EJB.


I think we should support a full CRUD language.  Specifically, I mean
that the user should not be restricted to just specifying the WHERE
clause, but they should be required to specify a DELETE clause also.
Then we just put in a restriction that a remove method on the home
interface is only allowed to remove entities of the current type.   
This
is the same restriction finders have.

The reason I think we should have a full CRUD language is it allows an
ejbSelect style method (although we may call it something else) to
delete any set of objects with a single operation.  This will be
particularly useful to delete a subset of related objects.

-dain



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts  
will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit  
encryption.
Get a guide  
here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts  
will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit  
encryption.
Get a guide  
here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-669112 ] Server.log not created when using xerces

[SourceForge.net]

Bugs item #669112, was opened at 2003-01-16 15:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669112&group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Everitt (andieveritt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Server.log not created when using xerces

Initial Comment:
If JBoss is installed into a path with a space in the
name (e.g. C:\Program Files\JBoss) and you are using
Xerces as the JAXP implementation the server.log file
is not created. All logging is written to boot.log.

I see the following exception on the screen (but not in
boot.log):
16:04:35,656 INFO  [Log4jService$URLWatchTimerTask]
Configuring from URL: resource:log4j.xml
log4j:ERROR Could not parse input source
[org.xml.sax.InputSource@95cfbe].
java.net.MalformedURLException: no protocol: log4j.dtd
at java.net.URL.(Unknown Source)
at java.net.URL.(Unknown Source)
at java.net.URL.(Unknown Source)
at
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:807)
at
org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:767)
at
org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:275)
at
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:841)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581)
at
org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at
org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:253)
at
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:672)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:602)
at
org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.java:704)
at
org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.java:486)
at
org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.java:425)
at
org.jboss.logging.Log4jService.startService(Log4jService.java:281)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:164)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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 $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:397)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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 $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(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(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
com.xms.install.jboss.JBossJService.bootJBoss(JBossJService.java:139)
at
com.xms.install.jboss.JBossJService.start(JBossJService.java:64)

RE: [JBoss-dev] Finders, Selectors and ... deleters?

[Bill Burke]

Thanks men.  Sorry to be a nag.. :)  Hope you don't mind.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
> Sundstrom
> Sent: Friday, January 17, 2003 1:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters?
>
>
> It is already in the JBoss 4.0 task list.
>
> http://sourceforge.net/pm/
> task.php?func=detailtask&project_task_id=68960&group_id=22866&group_proj
> ect_id=15043
>
> -dain
>
> On Friday, January 17, 2003, at 12:23 PM, Bill Burke wrote:
>
> > Please archive this on the Persistence forum.  Thanks guys.
> >
> > Bill
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED]]On Behalf Of
> >> Dain
> >> Sundstrom
> >> Sent: Friday, January 17, 2003 1:14 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters?
> >>
> >>
> >> On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote:
> >>
> >>> This leaves the JBoss-QL part read-only (it just qualifies the
> >>> instances to
> >>> be deleted). We know we're deleting Transactions as the method would
> >>> be on
> >>> the home interface for the Transaction EJB.
> >>
> >> I think we should support a full CRUD language.  Specifically, I mean
> >> that the user should not be restricted to just specifying the WHERE
> >> clause, but they should be required to specify a DELETE clause also.
> >> Then we just put in a restriction that a remove method on the home
> >> interface is only allowed to remove entities of the current type.
> >> This
> >> is the same restriction finders have.
> >>
> >> The reason I think we should have a full CRUD language is it allows an
> >> ejbSelect style method (although we may call it something else) to
> >> delete any set of objects with a single operation.  This will be
> >> particularly useful to delete a subset of related objects.
> >>
> >> -dain
> >>
> >>
> >>
> >> ---
> >> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts
> >> will
> >> allow you to extend the highest allowed 128 bit encryption to all your
> >> clients even if they use browsers that are limited to 40 bit
> >> encryption.
> >> Get a guide
> >> here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> >> ___
> >> Jboss-development mailing list
> >> [EMAIL PROTECTED]
> >> https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> >
> > ---
> > This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts
> > will
> > allow you to extend the highest allowed 128 bit encryption to all your
> > clients even if they use browsers that are limited to 40 bit
> > encryption.
> > Get a guide
> > here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ---
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
> allow you to extend the highest allowed 128 bit encryption to all your
> clients even if they use browsers that are limited to 40 bit encryption.
> Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Feature Requests-669907 ] Custom server configuration utility

[SourceForge.net]

Feature Requests item #669907, was opened at 2003-01-17 14:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376688&aid=669907&group_id=22866

Category: JBossServer
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Munz (mattmunz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Custom server configuration utility

Initial Comment:
The minimal configuration doesn't have quite enough in it 
for some tasks, and the default config has a lot of 
features that aren't often needed.  Currently, if one wants 
to create a pared-down configuration, one needs to 
delete given files under /deploy and modify and remove 
files under /conf, manually.

It would be convienient to have a tool to facilitate this 
process, kind of like a package manager.  Given that 
dependencies are often declared in *-service.xml, it 
seems that it should be possible to write a tool that 
inspects the "default" or "all" configurations and then 
allows the user to pick and choose the server modules 
to add.  Dependencies would be pulled in as needed.

Creating a custom configuration is useful for reducing 
the start-up time (and probably the footprint, too).  A tool 
like this would make that process easier (It isn't all that 
hard right now, BTW).

  - Matt Munz  





--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376688&aid=669907&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-669161 ] Jetty for 3.0.5 release giving null Session IDs

[SourceForge.net]

Bugs item #669161, was opened at 2003-01-16 11:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669161&group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: None
Priority: 5
Submitted By: J. Rhett Aultman (cuplan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Jetty for 3.0.5 release giving null Session IDs

Initial Comment:
We have recently started using JBoss 3.0.5 and have 
noticed that the version of Jetty bundled with this 
release is giving out null session ids as a default 
behavior.  Please advise.

--

>Comment By: J. Rhett Aultman (cuplan)
Date: 2003-01-17 14:37

Message:
Logged In: YES 
user_id=132788

It should be noted that the suggested version of Jetty 
continued to give us session problems.  In that particular 
case, Jetty was improperly assigning session IDs that should 
have been invalidated.  Just a heads-up when selecting a 
version of Jetty to replace the default one with.

--

Comment By: J. Rhett Aultman (cuplan)
Date: 2003-01-16 13:06

Message:
Logged In: YES 
user_id=132788

Many thanks for the fast and thorough response!

--

Comment By: Greg Wilkins (gregwilkins)
Date: 2003-01-16 12:37

Message:
Logged In: YES 
user_id=44062

This bug was introduced with some session optimizations.
It is already fixed in CVS head of Jetty, JBoss 3.0 and
JBoss 3.2
A replacement jbossweb.sar will be available shortly.
Alternatly you can grab the jetty 4.2.5 jar and drop that
into your
current jbossweb.sar.

Details of how to do that are in the jetty/jboss FAQ:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/contrib/jetty/FAQ?rev=HEAD&content-type=text/vnd.viewcvs-markup

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669161&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-669733 ] URL Resource-ref not possible in a WebApp

[SourceForge.net]

Bugs item #669733, was opened at 2003-01-17 05:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669733&group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Laurent Etiemble (letiemble)
>Assigned to: Scott M Stark (starksm)
Summary: URL Resource-ref not possible in a WebApp

Initial Comment:
URL Resource-ref cannot be declared successfully in a WebApplication.
I have the following in my web descriptor :

   ...
   
  url/urlData
  java.net.URL
  Container
   
   ...


And the following in my jboss-web descriptor :

   ...
   
  url/urlData
  http://orange-mibwas01:18080/Customers/CustomersIndex
   
   ...


When I deploy the webapp it leads to a DeploymentException.

If I change my jboss-web by removing the DTD reference and the content to :

   ...
   
  url/urlData
  http://localhost:8080/Data
   
   ...

It deploys fine.

The exception is raised in the org.jboss.metadata.ResourceRefMetaData class. When 
declaring an URL resource-ref, the searched tag is  and not .
To enable URL Resource-ref, modifiy the definition of a resource-ref in jboss-web DTD 
to accept jndi-name OR res-url as child of resource-ref.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669733&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-669731 ] res-auth case problem

[SourceForge.net]

Bugs item #669731, was opened at 2003-01-17 05:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669731&group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Laurent Etiemble (letiemble)
>Assigned to: Scott M Stark (starksm)
Summary: res-auth case problem

Initial Comment:
A web application compliant with the 2.2 servlet specs and which contains :
   ...
   
  ...
  ...
  CONTAINER
   
   ...
will not deploy successfully.

According to the Servlet Specs 2.2 (Section 13.2) the  tag in a web 
descriptor can only contain "CONTAINER" or "SERVLET".
According to the Servlet Specs 2.3 (Section 13.3) the  tag in a web 
descriptor can only contain "Container" or "Application".

The org.jboss.metadata.ResourceRefMetaData class only accepts "Container" or 
"Application" values, that's why the deployment of a 2.2 compliant web application 
containing  tags will failed.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669731&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-669650 ] ClassLoader Problem

[SourceForge.net]

Bugs item #669650, was opened at 2003-01-17 01:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669650&group_id=22866

Category: JBossMX
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Srivatsan (srivatsanp)
>Assigned to: Scott M Stark (starksm)
Summary: ClassLoader Problem

Initial Comment:
We have two applications,say Test.ear and Test1.ear 
both have some resource files packaged with them in 
the structure of

Test.ear
-dtd/test.dtd
Test1.ear
-dtd/test1.dtd

so when i tried to access this dtd/test.dtd from a class 
in Test1.ear i am not able to get the dtd. I am using 
this.getClass().getClassLoader().getResource
("dtd/test.dtd") method from a MBean Service (sar) 
which is present in Test1.ear. It returned null. 

On further analysis, we came to know that you are 
searching classes and resources based on package 
names. This might have introduced the issue of not able 
to access the dtd/test.dtd.since both the ear's have dtd 
dirs.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669650&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 17-January-2003

[scott . stark]

JBoss daily test results

SUMMARY

Number of tests run:   1010



Successful tests:  1007

Errors:2

Failures:  1





[time of test: 2003-01-17.12-05 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.3]

See http://users.jboss.org/~starksm/Branch_3_0/2003-01-17.12-05
for details of this test. 

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.

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





DETAILS OF ERRORS



Suite:   LocalWrapperCleanupUnitTestCase
Test:
testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase)
Type:error
Exception:   java.rmi.ServerException
Message: RemoteException occurred in server thread; nested exception is:   
java.rmi.ServerException: EJBException:; nested exception is:   
javax.ejb.EJBException: Row committed, autocommit still on!
-



Suite:   MissingClassUnitTestCase
Test:
testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase)
Type:error
Exception:   org.jboss.deployment.DeploymentException
Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: 
(javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not 
registered.)
-



Suite:   BeanStressTestCase
Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase)
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: expected a client deadlock for AB BA
-




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Oracle specific jca adapter

[Sonnek, Ryan]

i'm working on a project currently that is requiring that for each
connection to the database, a set of database packages are called before any
insert/update/select/delete commands are run.  i'd like to do this by
writing an extension to the existing JCA modules to execute these packages
before returning the java.sql.Connection object to the caller.

i've gone through the pay docs and examples but i must admit that i'm a bit
lost on where to start.  any suggestions on what classes i need to extend
and what xml files are needed would be greatly appreciated.

oracle is really pushing this "context setting" as their recommended method
of enterprise connections, and i'd be more than happy to submit anything i
get working to the jboss base code as a patch.  i just to be pointed in the
right direction.  thank you for all of your input!

Ryan J. Sonnek
Brown Printing Company
J2EE Application Developer
507.835.0803




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Oracle specific jca adapter

[David Jencks]

When does Oracle want you to execute this stuff? Per statement? per 
"getConnection"? per tx

Anyway, look in connector/src/main/org/jboss/resource/adapter/jdbc/
This contains the base classes and the local and xa specific subclasses 
are in the local and xa folders.  There's an Oracle specific 
ManagedConnectionFactory for xa to work around some other oracle 
"features.

If you really need to do something whenever a connection handle is 
given to a user app, look in one of the ManagedConnection classes at 
getConnection.

If you need to do something whenever a new physical connection is 
established to Oracle do it in the ManagedConnection constructor.

You can intercept "new statement" and use-of-statement operations in 
the connection and statement wrappers.  If you need to do them at the 
start of a transaction maybe you could wrap the XAResource??

thanks
david jencks

On Friday, January 17, 2003, at 04:43 PM, Sonnek, Ryan wrote:

i'm working on a project currently that is requiring that for each
connection to the database, a set of database packages are called 
before any
insert/update/select/delete commands are run.  i'd like to do this by
writing an extension to the existing JCA modules to execute these 
packages
before returning the java.sql.Connection object to the caller.

i've gone through the pay docs and examples but i must admit that i'm 
a bit
lost on where to start.  any suggestions on what classes i need to 
extend
and what xml files are needed would be greatly appreciated.

oracle is really pushing this "context setting" as their recommended 
method
of enterprise connections, and i'd be more than happy to submit 
anything i
get working to the jboss base code as a patch.  i just to be pointed 
in the
right direction.  thank you for all of your input!

Ryan J. Sonnek
Brown Printing Company
J2EE Application Developer
507.835.0803




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts 
will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit 
encryption.
Get a guide 
here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-669731 ] res-auth case problem

[SourceForge.net]

Bugs item #669731, was opened at 2003-01-17 05:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669731&group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Laurent Etiemble (letiemble)
Assigned to: Scott M Stark (starksm)
Summary: res-auth case problem

Initial Comment:
A web application compliant with the 2.2 servlet specs and which contains :
   ...
   
  ...
  ...
  CONTAINER
   
   ...
will not deploy successfully.

According to the Servlet Specs 2.2 (Section 13.2) the  tag in a web 
descriptor can only contain "CONTAINER" or "SERVLET".
According to the Servlet Specs 2.3 (Section 13.3) the  tag in a web 
descriptor can only contain "Container" or "Application".

The org.jboss.metadata.ResourceRefMetaData class only accepts "Container" or 
"Application" values, that's why the deployment of a 2.2 compliant web application 
containing  tags will failed.


--

>Comment By: Scott M Stark (starksm)
Date: 2003-01-17 15:04

Message:
Logged In: YES 
user_id=175228

Fixed in 3.0+

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669731&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Hi Remember me..!!?

[Isabelle]

=3Chtml=3E
=3Chead=3E
=3Ctitle=3EDo you remember me=3F=3C=2Ftitle=3E
=3Cmeta http-equiv=3D=22Content-Type=22 content=3D=22text=2Fhtml=3B 
charset=3Dwindows-1252=22=3E
=3C=2Fhead=3E

=3Cbody bgcolor=3D=22#FF=22 text=3D=22#00=22=3E
=3Cfont size=3D=225=22=3E=3Ca 
href=3D=22http=3A=2F=2Fwww=2Eliveisabelle=2Ecom=22=3Ehttp=3A=2F=2Fwww=2Emyfreelivecam=2Ecom=2Fisabelle=3C=2Fa=3E=3C=2Ffont=3E
 
=3C=2Fbody=3E
=3C=2Fhtml=3E




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-669733 ] URL Resource-ref not possible in a WebApp

[SourceForge.net]

Bugs item #669733, was opened at 2003-01-17 05:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669733&group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Laurent Etiemble (letiemble)
Assigned to: Scott M Stark (starksm)
Summary: URL Resource-ref not possible in a WebApp

Initial Comment:
URL Resource-ref cannot be declared successfully in a WebApplication.
I have the following in my web descriptor :

   ...
   
  url/urlData
  java.net.URL
  Container
   
   ...


And the following in my jboss-web descriptor :

   ...
   
  url/urlData
  http://orange-mibwas01:18080/Customers/CustomersIndex
   
   ...


When I deploy the webapp it leads to a DeploymentException.

If I change my jboss-web by removing the DTD reference and the content to :

   ...
   
  url/urlData
  http://localhost:8080/Data
   
   ...

It deploys fine.

The exception is raised in the org.jboss.metadata.ResourceRefMetaData class. When 
declaring an URL resource-ref, the searched tag is  and not .
To enable URL Resource-ref, modifiy the definition of a resource-ref in jboss-web DTD 
to accept jndi-name OR res-url as child of resource-ref.


--

>Comment By: Scott M Stark (starksm)
Date: 2003-01-17 15:24

Message:
Logged In: YES 
user_id=175228

Fixed in 3.0.6+

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669733&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Oracle specific jca adapter

[Sonnek, Ryan]

oracle suggests that the context be set for each user executing a query.  my
initial thought was that each time getConnection() was called, the current
principal of the caller would be used for these oracle packages.  but, now
that you mention it, wouldn't it have to be done for each transaction?  

it's whole intent is that instead of using individual connections to the
database, it uses a  generic connection pool, but it extracts the JAAS
principal and sets it in the oracle context for use with triggers.  it makes
scence in a way since you get the benifits of acurate audit information
without the overhead of individual connections to the database.

my question now is should this be done on the individual statement level, or
the transaction level?  i vaguely understand the process of when
getConnection() is called for BMP classes, but i don't know when it's caled
for CMP classes.  i need to ensure that each statement run by a particular
user has the context information set.

Ryan

-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 5:00 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Oracle specific jca adapter


When does Oracle want you to execute this stuff? Per statement? per 
"getConnection"? per tx

Anyway, look in connector/src/main/org/jboss/resource/adapter/jdbc/
This contains the base classes and the local and xa specific subclasses 
are in the local and xa folders.  There's an Oracle specific 
ManagedConnectionFactory for xa to work around some other oracle 
"features.

If you really need to do something whenever a connection handle is 
given to a user app, look in one of the ManagedConnection classes at 
getConnection.

If you need to do something whenever a new physical connection is 
established to Oracle do it in the ManagedConnection constructor.

You can intercept "new statement" and use-of-statement operations in 
the connection and statement wrappers.  If you need to do them at the 
start of a transaction maybe you could wrap the XAResource??

thanks
david jencks

On Friday, January 17, 2003, at 04:43 PM, Sonnek, Ryan wrote:

> i'm working on a project currently that is requiring that for each
> connection to the database, a set of database packages are called 
> before any
> insert/update/select/delete commands are run.  i'd like to do this by
> writing an extension to the existing JCA modules to execute these 
> packages
> before returning the java.sql.Connection object to the caller.
>
> i've gone through the pay docs and examples but i must admit that i'm 
> a bit
> lost on where to start.  any suggestions on what classes i need to 
> extend
> and what xml files are needed would be greatly appreciated.
>
> oracle is really pushing this "context setting" as their recommended 
> method
> of enterprise connections, and i'd be more than happy to submit 
> anything i
> get working to the jboss base code as a patch.  i just to be pointed 
> in the
> right direction.  thank you for all of your input!
>
> Ryan J. Sonnek
> Brown Printing Company
> J2EE Application Developer
> 507.835.0803
> 
>
>
>
> ---
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts 
> will
> allow you to extend the highest allowed 128 bit encryption to all your
> clients even if they use browsers that are limited to 40 bit 
> encryption.
> Get a guide 
> here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Compiling head

[Jason Essington]

Just curious if anyone has managed to get JBoss head to compile on OS X 
using Apples 1.4.1 jdk? I am getting errors with some of the jdbc3 
stuff (I think).

Is head compiling at all just now?

-jason



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Oracle specific jca adapter

[David Jencks]

I would imagine this would need to be called whenever the user changes. 
 This can be detected when getConnection is called on 
ManagedConnection.  I'd check to see if the user has actually changed.

If you implement this you should change the pooling parameter 
"Criteria" to "ByNothing"  for this adapter because this basically 
means Oracle is supporting reauthentication.

To actually use this feature you will need to do application managed 
security (bad idea IMO) (i.e. calling datasource.getConnection(user, 
pw)) or use a login module that supplies more than one Subject such as 
the CallerIdentityLoginModule.


Good luck!  I'll be mostly offline till monday or tuesday when I can 
probably answer more questions.

david jencks

On Friday, January 17, 2003, at 06:22 PM, Sonnek, Ryan wrote:

oracle suggests that the context be set for each user executing a 
query.  my
initial thought was that each time getConnection() was called, the 
current
principal of the caller would be used for these oracle packages.  but, 
now
that you mention it, wouldn't it have to be done for each transaction?

it's whole intent is that instead of using individual connections to 
the
database, it uses a  generic connection pool, but it extracts the JAAS
principal and sets it in the oracle context for use with triggers.  it 
makes
scence in a way since you get the benifits of acurate audit information
without the overhead of individual connections to the database.

my question now is should this be done on the individual statement 
level, or
the transaction level?  i vaguely understand the process of when
getConnection() is called for BMP classes, but i don't know when it's 
caled
for CMP classes.  i need to ensure that each statement run by a 
particular
user has the context information set.

Ryan

-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 5:00 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Oracle specific jca adapter


When does Oracle want you to execute this stuff? Per statement? per
"getConnection"? per tx

Anyway, look in connector/src/main/org/jboss/resource/adapter/jdbc/
This contains the base classes and the local and xa specific subclasses
are in the local and xa folders.  There's an Oracle specific
ManagedConnectionFactory for xa to work around some other oracle
"features.

If you really need to do something whenever a connection handle is
given to a user app, look in one of the ManagedConnection classes at
getConnection.

If you need to do something whenever a new physical connection is
established to Oracle do it in the ManagedConnection constructor.

You can intercept "new statement" and use-of-statement operations in
the connection and statement wrappers.  If you need to do them at the
start of a transaction maybe you could wrap the XAResource??

thanks
david jencks

On Friday, January 17, 2003, at 04:43 PM, Sonnek, Ryan wrote:

i'm working on a project currently that is requiring that for each
connection to the database, a set of database packages are called
before any
insert/update/select/delete commands are run.  i'd like to do this by
writing an extension to the existing JCA modules to execute these
packages
before returning the java.sql.Connection object to the caller.

i've gone through the pay docs and examples but i must admit that i'm
a bit
lost on where to start.  any suggestions on what classes i need to
extend
and what xml files are needed would be greatly appreciated.

oracle is really pushing this "context setting" as their recommended
method
of enterprise connections, and i'd be more than happy to submit
anything i
get working to the jboss base code as a patch.  i just to be pointed
in the
right direction.  thank you for all of your input!

Ryan J. Sonnek
Brown Printing Company
J2EE Application Developer
507.835.0803




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts
will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit
encryption.
Get a guide
here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development





---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts 
will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit 
encryption.
Get a guide 
here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


---
This SF.NET email is spon

[JBoss-dev] [ jboss-Bugs-670078 ] Through JMX page, MDB create/destroy don't work as expected

[SourceForge.net]

Bugs item #670078, was opened at 2003-01-17 16:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=670078&group_id=22866

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Through JMX page, MDB create/destroy don't work as expected

Initial Comment:

JBoss.3.2 RC1, with jboss.jar from Beta3

Under category jboss.j2ee:

Click on a MDB, click stop.  JBoss still sends one more
message to my MDB.  (I think that instance is cached.) 

Click on destroy, all cached MDB are destroyed, as
expected.  Click on create, you get an exception back:

MBeanException: Exception in service lifecyle
operation: create
Cause: java.lang.NullPointerException
at org.jboss.ejb.Container.invoke(Container.java:749)


Click on start:


MBeanException: Exception in service lifecyle
operation: start
Cause: javax.naming.NoInitialContextException: Cannot
instantiate class:
org.jnp.interfaces.NamingContextFactory [Root exception
is java.lang.ClassNotFoundException:
org/jnp/interfaces/NamingContextFactory]
at org.jboss.ejb.Container.invoke(Container.java:749)

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=670078&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Compiling head

[Scott M Stark]

Builds fine for me on a win2ksp1 box using sun jdk1.4.1_01

build 461>java -version
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
build 462>build.sh
build.sh: Executing: /usr/Main/jboss-head/tools/bin/ant -logger org.apache.tools
.ant.NoBannerLogger
Buildfile: build.xml
...
BUILD SUCCESSFUL
Total time: 3 minutes 31 seconds


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: "Jason Essington" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 17, 2003 3:38 PM
Subject: [JBoss-dev] Compiling head


> Just curious if anyone has managed to get JBoss head to compile on OS X 
> using Apples 1.4.1 jdk? I am getting errors with some of the jdbc3 
> stuff (I think).
> 
> Is head compiling at all just now?
> 
> -jason



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-670078 ] Through JMX page, MDB create/destroy don't work as expected

[SourceForge.net]

Bugs item #670078, was opened at 2003-01-17 16:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=670078&group_id=22866

>Category: JBossMQ
>Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Through JMX page, MDB create/destroy don't work as expected

Initial Comment:

JBoss.3.2 RC1, with jboss.jar from Beta3

Under category jboss.j2ee:

Click on a MDB, click stop.  JBoss still sends one more
message to my MDB.  (I think that instance is cached.) 

Click on destroy, all cached MDB are destroyed, as
expected.  Click on create, you get an exception back:

MBeanException: Exception in service lifecyle
operation: create
Cause: java.lang.NullPointerException
at org.jboss.ejb.Container.invoke(Container.java:749)


Click on start:


MBeanException: Exception in service lifecyle
operation: start
Cause: javax.naming.NoInitialContextException: Cannot
instantiate class:
org.jnp.interfaces.NamingContextFactory [Root exception
is java.lang.ClassNotFoundException:
org/jnp/interfaces/NamingContextFactory]
at org.jboss.ejb.Container.invoke(Container.java:749)

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=670078&group_id=22866


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Jboss 4 doesn't build

[Stefan Reich]

I am wondering how other people are able to build the latest source  
tree from scratch. I am building on MacOS 10.2.

Stefan

[watterson:/Users/Shared/jboss-all] sreich% sh -x ./build/build.sh
++ basename ./build/build.sh
+ PROGNAME=build.sh
++ dirname ./build/build.sh
+ DIRNAME=./build
+ main
+ '[' x = x ']'
++ cd ./build/../tools
++ pwd
+ TOOLS_ROOT=/Users/Shared/jboss-all/tools
++ cd ./build
++ pwd
+ MODULE_ROOT=/Users/Shared/jboss-all/build
+ export TOOLS_ROOT MODULE_ROOT DEBUG TRACE
+ target=/Users/Shared/jboss-all/tools/bin/build.sh
+ '[' '!' -f /Users/Shared/jboss-all/tools/bin/build.sh ']'
+ '[' x '!=' x ']'
+ '[' x = x ']'
+ exec /bin/sh /Users/Shared/jboss-all/tools/bin/build.sh
build.sh: Executing: /Users/Shared/jboss-all/tools/bin/ant -logger  
org.apache.tools.ant.NoBannerLogger
Buildfile: build.xml

_buildmagic:init:
Trying to override old definition of task property

configure-modules:
Overriding previous definition of reference to jboss.naming.classpath

configure-project:
 [echo] groups:  default
 [echo] modules:  
common,jmx,system,aop,cache,j2ee,naming,management,transaction,server,bl 
ocks,console,security,messaging,connector,varia,cluster,jetty,jboss.net, 
iiop

_buildmagic:modules:most:

 ==
 ==
 ==  Executing 'most' in module 'common'...
 ==
 ==

configure-modules:
Overriding previous definition of reference to jboss.naming.classpath

BUILD FAILED
file:/Users/Shared/jboss-all/common/build.xml:118: Could not create  
task or type of type: jmxdoclet.

Ant could not find the task or a class this task relies upon.

This is common and has a number of causes; the usual
solutions are to read the manual pages then download and
install needed JAR files, or fix the build file:
 - You have misspelt 'jmxdoclet'.
   Fix: check your spelling.
 - The task needs an external JAR file to execute
   and this is not found at the right place in the classpath.
   Fix: check the documentation for dependencies.
   Fix: declare the task.
 - The task is an Ant optional task and optional.jar is absent
   Fix: look for optional.jar in ANT_HOME/lib, download if needed
 - The task was not built into optional.jar as dependent
   libraries were not found at build time.
   Fix: look in the JAR to verify, then rebuild with the needed
   libraries, or download a release version from apache.org
 - The build file was written for a later version of Ant
   Fix: upgrade to at least the latest release version of Ant
 - The task is not an Ant core or optional task
   and needs to be declared using .

Remember that for JAR files to be visible to Ant tasks implemented
in ANT_HOME/lib, the files must be in the same directory or on the
classpath

Please neither file bug reports on this problem, nor email the
Ant mailing lists, until all of these causes have been explored,
as this is not an Ant bug.

Total time: 7 seconds



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Jboss 4 doesn't build

[Scott M Stark]

You can't check out the jboss-all module alias to build the head branch. This
module is for the 3.0 branch only. The following are the co commands for
the various branches:

co -r Branch_3_0 jboss-all == co -r Branch_3_0 jboss-3.0
co -r Branch_3_2 jboss-3.2
co -r HEAD jboss-head == co -r jboss-head


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: "Stefan Reich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 17, 2003 6:26 PM
Subject: [JBoss-dev] Jboss 4 doesn't build


> I am wondering how other people are able to build the latest source  
> tree from scratch. I am building on MacOS 10.2.
> 
> Stefan
> 
> [watterson:/Users/Shared/jboss-all] sreich% sh -x ./build/build.sh
> ++ basename ./build/build.sh
> + PROGNAME=build.sh
> ++ dirname ./build/build.sh
> + DIRNAME=./build
> + main
> + '[' x = x ']'
> ++ cd ./build/../tools
> ++ pwd
> + TOOLS_ROOT=/Users/Shared/jboss-all/tools
> ++ cd ./build
> ++ pwd
> + MODULE_ROOT=/Users/Shared/jboss-all/build
> + export TOOLS_ROOT MODULE_ROOT DEBUG TRACE
> + target=/Users/Shared/jboss-all/tools/bin/build.sh
> + '[' '!' -f /Users/Shared/jboss-all/tools/bin/build.sh ']'
> + '[' x '!=' x ']'
> + '[' x = x ']'
> + exec /bin/sh /Users/Shared/jboss-all/tools/bin/build.sh
> build.sh: Executing: /Users/Shared/jboss-all/tools/bin/ant -logger  



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] SF task lists

[Bill Burke]

If you haven't already heard, I have created task lists on SourceForge for
every JBoss project.  All developers with CVS access can view and be
assigned tasks.  Only Lead Developers have the power to create and assign
tasks so if you need to log a new task, communicate with the Lead Developer
with the project.  If you are having problems coordinating with the Lead
Developer for the project, contact me directly and I'll help you out.

Thanks everybody.  I hope the task lists help smooth out our development
process and help new recruits figure out what needs to be done in JBoss.


Bill Burke
Chief Architect
JBoss Group, LLC




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] jboss-head really fucked

[Bill Burke]

Somebody really screwed up jboss-head.  Can the butt-head who did fix it?
This is ridiculous

MBeans waiting for other MBeans:
[org.jboss.system.ServiceContext@17342155 {
  objectName: jboss.ejb:service=EJBDeployer
  state: CONFIGURED
  dependencies: [jboss.tm:service=TransactionManagerService,
jboss:service=WebService]
}, org.jboss.system.ServiceContext@3e0fd571 {
  objectName: jboss:service=invoker,type=jrmp
  state: CONFIGURED
  dependencies: [jboss.tm:service=TransactionManagerService]
}, org.jboss.system.ServiceContext@383f0c1 {
  objectName: jboss:service=invoker,type=pooled
  state: CONFIGURED
  dependencies: [jboss.tm:service=TransactionManagerService]
}, org.jboss.system.ServiceContext@840583a5 {
  objectName: jboss:service=invoker,type=local
  state: CONFIGURED
  dependencies: [jboss.tm:service=TransactionManagerService]
}, org.jboss.system.ServiceContext@1d93f68e {
  objectName: jboss:service=WorkManager,type=TrunkInvoker
  state: CONFIGURED
  dependencies: [jboss.tm:service=TransactionManagerService]
  dependants: [jboss:service=invoker,type=trunk]
}, org.jboss.system.ServiceContext@8477e1ee {
  objectName: jboss:service=invoker,type=trunk
  state: CONFIGURED
  dependencies: [jboss.tm:service=TransactionManagerService,
jboss:service=WorkManager,type=TrunkInvoker]
  dependants: [jboss.mq:service=InvocationLayer,type=Trunk]
}, org.jboss.system.ServiceContext@b6ffee76 {
  objectName: jboss.tm:service=ClientUserTransaction
  state: CONFIGURED
  dependencies: [jboss.tm:service=TransactionManagerService,
jboss.jca:service=CachedConnectionManager]
}, org.jboss.system.ServiceContext@458d04ba {
  objectName: jboss.jca:service=BaseWorkManager
  state: CONFIGURED
  dependencies: [jboss.tm:service=TransactionManagerService]
  dependants: [jboss.jca:service=BaseBootstrapContext]
}, org.jboss.system.ServiceContext@1b5fa8c3 {
  objectName: jboss.jca:service=BaseBootstrapContext
  state: CONFIGURED
  dependencies: [jboss.jca:service=BaseWorkManager]
}, org.jboss.system.ServiceContext@f7fa85cc {
  objectName: jboss.jca:service=LocalTxCM,name=DefaultDS
  state: CONFIGURED
  dependencies: [jboss.tm:service=TransactionManagerService,
jboss.jca:service=CachedConnectionManager, jboss.jca:servic
e=ManagedConnectionPool,name=DefaultDS,
jboss.jca:service=ManagedConnectionFactory,name=DefaultDS,
jboss:service=Hyperso
nic]
  dependants: [jboss.mq:service=PersistenceManager]
}, org.jboss.system.ServiceContext@ddeabeb0 {
  objectName:
jboss.deployment:name=file%3a/C%3a/jboss/jboss-head/build/output/jboss-4.0.0
alpha/server/default/deploy/jm
s-ds.xml,service=DeploymentInfo
  state: CONFIGURED
  dependencies: [jboss.deployment:name=JMS Adapter,service=DeploymentInfo,
jboss.tm:service=XidFactory]
}, org.jboss.system.ServiceContext@5aec6f45 {
  objectName: jboss.mq.destination:service=Topic,name=testTopic
  state: CONFIGURED
  dependencies: [jboss.mq:service=SecurityManager,
jboss.mq:service=DestinationManager]
}, org.jboss.system.ServiceContext@8236d6f0 {
  objectName: jboss.mq.destination:service=Topic,name=securedTopic
  state: CONFIGURED
  dependencies: [jboss.mq:service=SecurityManager,
jboss.mq:service=DestinationManager]
}, org.jboss.system.ServiceContext@6ece5dd4 {
  objectName: jboss.mq.destination:service=Topic,name=testDurableTopic
  state: CONFIGURED
  dependencies: [jboss.mq:service=SecurityManager,
jboss.mq:service=DestinationManager]
}, org.jboss.system.ServiceContext@5c719389 {
  objectName: jboss.mq.destination:service=Queue,name=testQueue
  state: CONFIGURED
  dependencies: [jboss.mq:service=SecurityManager,
jboss.mq:service=DestinationManager]
}, org.jboss.system.ServiceContext@a18d4300 {
  objectName: jboss.mq.destination:service=Queue,name=testObjectMessage
  state: CONFIGURED
  dependencies: [jboss.mq:service=DestinationManager]
}, org.jboss.system.ServiceContext@efdb3dab {
  objectName: jboss.mq.destination:service=Queue,name=A
  state: CONFIGURED
  dependencies: [jboss.mq:service=DestinationManager]
}, org.jboss.system.ServiceContext@49b6a7ec {
  objectName: jboss.mq.destination:service=Queue,name=B
  state: CONFIGURED
  dependencies: [jboss.mq:service=DestinationManager]
}, org.jboss.system.ServiceContext@a392122d {
  objectName: jboss.mq.destination:service=Queue,name=C
  state: CONFIGURED
  dependencies: [jboss.mq:service=DestinationManager]
}, org.jboss.system.ServiceContext@fd6d7c6e {
  objectName: jboss.mq.destination:service=Queue,name=D
  state: CONFIGURED
  dependencies: [jboss.mq:service=DestinationManager]
}, org.jboss.system.ServiceContext@51b98823 {
  objectName: jboss.mq.destination:service=Queue,name=ex
  state: CONFIGURED



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
__