Re: [JBoss-dev] [ jboss-Bugs-552157 ] Stateful session activation fails

[Chris Harris]

ok it's bug 558362
* * *

View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=14829

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] UDS DeployedURL.watchedUrl

[Jason Dillon]

Can someone please explain to me what DeployedURL.watchedUrl is for?

--jason

-
This mail sent through IMP: http://horde.org/imp/

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Re: JBossMX Timer Problem

[Adrian Brock]

Hi Andreas,

Apologies. I should have put a test for this in the testsuite,
I broke this a couple of weeks ago.
Thanks for your test, although it does have a small mistake which
I'll fix as well.

I'll commit this evening when I can get CVS access.

Regards,
Adrian


From: Andreas Schaefer [EMAIL PROTECTED]
To: Juha Lindfors [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: JBossMX Timer Problem
Date: Mon, 20 May 2002 17:47:07 -0700

Hi Geeks

Found a problem with two notification registered at
the Timer MBean. It seems that even the period is
set correctly (from Timer MBean) the periods are
not calculated correctly.

Please have a look at the new test testTwoNotificationProducers
in the timer.BasicTestCase which register two notifications (how
ever created this names should be punished for that) with different
periods. The test then checks if the order of the notifications and
the time between the notifications are correct.

This problem is causing my Scheduler to fail with two
Schedulers.

Have fun

x
Andreas Schaefer
Senior Consultant
JBoss Group, LLC
x




_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developersenvironment

[Juha-P Lindfors]

On Mon, 20 May 2002, Dain Sundstrom wrote:

 [I moved this to the dev list]

 I think the real power of JMX is you can have disparate components that
 can all talk to a central object without becoming tightly coupled.

 Here is my idea:

 We have an optional port server MBean.  Before a service opens a port it
 checks for the existence of the port server, and if (and only if) it
 exists, it asks the port server for a port passing the service name and
 port name (both are just any string).  If the port service doesn't
 exist, it follows the default code.

 This would require that the MBean wrappers for any serveice that opens a
 port to follow know about the possibility of a port service, but I don't
 think that is a big deal. Most MBeans already know about many services.

another possibility would be to persist these attributes containing port
numbers to a single location, e.g. config/ports.properties where all ports
would be in a single file.

This would not require the MBean developers to change their coding in any
way (Jules point about simple contracts) but would just require us to
config the initial server setup for the MBeans in question to use the same
location for these attributes. New user MBeans could also be configured to
use the same storage. Same approach would work for other system resources
as well (whatever they might be) without having to impose yet another
contractual requirement for MBean developers.

However, this requires that we convert to using persistent mbeans, which
is a more long term project. Short term your solution is the easier fix.

my .02

-- Juha



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment

[Mike Finn]

Very basic question, but I have to ask it: how should the service bindings
service be exposed? I assume as MBean? MBean with static port manager
bound in JNDI (might have the chicken/egg problem here, since JNDI would be
a dependency and JNDI would need to find what port on which to run...)?

#mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Juha-P Lindfors
Sent: Tuesday, May 21, 2002 6:36 AM
To: JBoss-dev
Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
environment


On Mon, 20 May 2002, Dain Sundstrom wrote:

 [I moved this to the dev list]

 I think the real power of JMX is you can have disparate components that
 can all talk to a central object without becoming tightly coupled.

 Here is my idea:

 We have an optional port server MBean.  Before a service opens a port it
 checks for the existence of the port server, and if (and only if) it
 exists, it asks the port server for a port passing the service name and
 port name (both are just any string).  If the port service doesn't
 exist, it follows the default code.

 This would require that the MBean wrappers for any serveice that opens a
 port to follow know about the possibility of a port service, but I don't
 think that is a big deal. Most MBeans already know about many services.

another possibility would be to persist these attributes containing port
numbers to a single location, e.g. config/ports.properties where all ports
would be in a single file.

This would not require the MBean developers to change their coding in any
way (Jules point about simple contracts) but would just require us to
config the initial server setup for the MBeans in question to use the same
location for these attributes. New user MBeans could also be configured to
use the same storage. Same approach would work for other system resources
as well (whatever they might be) without having to impose yet another
contractual requirement for MBean developers.

However, this requires that we convert to using persistent mbeans, which
is a more long term project. Short term your solution is the easier fix.

my .02

-- Juha



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-557209 ] IntiialContext() fails to remote server

[noreply]

Bugs item #557209, was opened at 2002-05-17 14:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=557209group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Christian Riege (lqd)
Assigned to: Scott M Stark (starksm)
Summary: IntiialContext() fails to remote server

Initial Comment:
scott,

this seems to be something w/ respect to your changes
in org.jnp.naming. the current Branch_3_0 gives me an
exception when connecting to a JNDI server that is
running on a remote machine (above are the Properties
that I'm trying to use):

Using: {jnp.port=12345,
java.naming.provider.url=195.145.13.46:1099,
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory,
jnp.rmiPort=0, jnp.localPort=9876,
java.naming.factory.url.pkgs=org.jnp.interfaces,
jnp.localAddress=195.145.13.33}
javax.naming.CommunicationException.  Root exception is
java.rmi.ConnectException: Connection refused to host:
127.0.0.1; nested exception is: 
java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:350)
at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:137)
at
java.net.PlainSocketImpl.connect(PlainSocketImpl.java:124)
at java.net.Socket.init(Socket.java:268)
at java.net.Socket.init(Socket.java:95)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:20)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:115)
at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:494)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:169)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:78)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:445)
at
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:429)
at
javax.naming.InitialContext.lookup(InitialContext.java:345)


it could be that there are just some of my Properties
messed up; however this used to work up until yesterday.

regards,
  christian

--

Comment By: Christian Riege (lqd)
Date: 2002-05-21 15:21

Message:
Logged In: YES 
user_id=176671

adrian and scott,

thanks for the pointers; turned out my /etc/hosts had the
hostname of the machine pointing to 127.0.0.1. Once I
changed that to the IP of my eth0 interface things started
working again.

just a quick thought w/o having looked at the JBoss source:
would it be possible to ensure that we don't return a stub
pointing to 127.0.0.1 if we know that the call came in via
an interface other than 127.0.0.1?!

--

Comment By: Adrian Brock (ejort)
Date: 2002-05-17 17:27

Message:
Logged In: YES 
user_id=9459

Try this link. This indicates an error in your ip config.

http://main.jboss.org/forums/thread.jsp?forum=67thread=8092

Regards,
Adrian

--

Comment By: Scott M Stark (starksm)
Date: 2002-05-17 17:15

Message:
Logged In: YES 
user_id=175228

This is working for me. I initially saw the same problem 
and I added a log statement to show the RMI stub exported 
on the server and I had the server address setup 
incorrectly. After fixing that this test program works fine:

jboss-all 1146cat tstNS.java
import java.util.Properties;
import javax.naming.*;

class tstNS
{
   public static void main(String[] args) throws Exception
   {
  Properties env = new Properties();
  env.setProperty
(java.naming.factory.initial,org.jnp.interfaces.NamingCo
ntextFactory);
  env.setProperty
(java.naming.factory.pkgs,org.jnp.interfaces);
  env.setProperty
(java.naming.provider.url,172.17.66.53:1099);
  env.setProperty(jnp.port, 12345);
  env.setProperty(jnp.rmiPort, 0);
  env.setProperty(jnp.localPort, 9876);
  env.setProperty(jnp.localAddress,172.17.66.54);
  InitialContext ctx = new InitialContext(env);
  System.out.println(Created InitialContext);
  Object ut = ctx.lookup(UserTransaction);
  System.out.println(Found UserTransaction, ut=+ut);
   }
}
jboss-all 1147cat tstNS.sh
#!/bin/sh

CLIENT=build/output/jboss-3.0.0RC3/client
CP=$CLIENT/jnp-client.jar;$CLIENT/jnet.jar;.
OPTS=-Dsun.rmi.transport.tcp.logLevel=99
java -cp $CP $OPTS tstNS

jboss-all 1144tstNS.sh
Created InitialContext
Fri May 17 08:22:28 PDT 2002:tcp:main:TCPEndpoint.clinit: 
localHostKnown = true, localHost = 172.17.66.54
Fri May 17 08:22:28 PDT 2002:tcp:main:TCPTransport.init: 
Version = 2, ep = 

Re: [jetty-discuss] Re: [JBoss-dev] Jetty NPE on undeployment ofjbosstest-web

[Greg Wilkins]

I have added in CVS head support for the graceful shutdown of a context.

If stats are on for a context (so that active sessions are being traced)
and stop(true) is called instead of stop(), then the context
immediately starts rejecting new requests but the stop call waits until
all requests have completed before sending notifications to the context
and returning.

This is not yet the default behaivour, but you will be able test it out
and see how it goes.   You could make it the default for the jboss integeration.

JMX MBeans have been updated accordingly.


Jules Gosnell wrote:
 Scott,
 
 This appears to be caused by a race between Jetty responding to the 
 request to the JSP and the testsuite undeploying it.
 
 Looking at my request and server logs I can see that a request was made 
 for include_ejb.jsp during the second before the call to undeploy 
 jbosstest-web.ear.
 
 It looks like, by the time Jetty has got the JSP compiled and tries to 
 run it, it has been undeployed.
 
 Jetty could handle this more gracefully - agreed (and we are thinking 
 about it).
 
 Is it possible that the testsuite is making it's requests asynchronously 
 and undeploying it's ear before all requests have finished ?
 
 
 Jules
 
 
 Scott M Stark wrote:
 
When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run against
the 3.0 branch the undeployment of the war is causing the NPE shown here:

17:38:01,062 INFO  [MainDeployer] Undeployed
file:/D:/usr/local/src/cvsroot/JBos
s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear
17:38:02,656 ERROR [STDERR] java.lang.NullPointerException
17:38:02,656 ERROR [STDERR] at
org.mortbay.jetty.servlet.ServletHandler$Cont
ext.getResource(ServletHandler.java:910)
17:38:02,671 ERROR [STDERR] at
org.apache.jasper.JspEngineContext.getResourc
e(JspEngineContext.java:366)
17:38:02,671 ERROR [STDERR] at
org.apache.jasper.compiler.JspCompiler.isOutD
ated(JspCompiler.java:179)
17:38:02,687 ERROR [STDERR] at
org.apache.jasper.compiler.Compiler.compile(C
ompiler.java:121)
17:38:02,687 ERROR [STDERR] at
org.apache.jasper.servlet.JspServlet.loadJSP(
JspServlet.java:557)
17:38:02,687 ERROR [STDERR] at
org.apache.jasper.servlet.JspServlet$JspServl
etWrapper.loadIfNecessary(JspServlet.java:177)
17:38:02,703 ERROR [STDERR] at
org.apache.jasper.servlet.JspServlet$JspServl
etWrapper.service(JspServlet.java:189)
17:38:02,703 ERROR [STDERR] at
org.apache.jasper.servlet.JspServlet.serviceJ
spFile(JspServlet.java:382)
17:38:02,703 ERROR [STDERR] at
org.apache.jasper.servlet.JspServlet.service(
JspServlet.java:474)
17:38:02,703 ERROR [STDERR] at
javax.servlet.http.HttpServlet.service(HttpSe
rvlet.java:853)
17:38:02,703 ERROR [STDERR] at
org.mortbay.jetty.servlet.ServletHolder.handl
e(ServletHolder.java:326)
17:38:02,718 ERROR [STDERR] at
org.mortbay.jetty.servlet.Dispatcher.dispatch
(Dispatcher.java:259)
17:38:02,718 ERROR [STDERR] at
org.mortbay.jetty.servlet.Dispatcher.include(
Dispatcher.java:171)
17:38:02,718 ERROR [STDERR] at
org.apache.jasper.runtime.JspRuntimeLibrary.i
nclude(JspRuntimeLibrary.java:820)
17:38:02,718 ERROR [STDERR] at
org.apache.jsp.include_0005fejb$jsp._jspServi
ce(include_0005fejb$jsp.java:61)
17:38:02,718 ERROR [STDERR] at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
17:38:02,718 ERROR [STDERR] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
17:38:02,734 ERROR [STDERR] at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:202)
17:38:02,734 ERROR [STDERR] at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
17:38:02,734 ERROR [STDERR] at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
17:38:02,734 ERROR [STDERR] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
17:38:02,734 ERROR [STDERR] at
org.mortbay.jetty.servlet.ServletHolder.handleServletHolder.java:326)
17:38:02,750 ERROR [STDERR] at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:595)
17:38:02,750 ERROR [STDERR] at
org.mortbay.http.HttpContext.handle(HttpContext.java:1357)
17:38:02,750 ERROR [STDERR] at
org.mortbay.http.HttpContext.handle(HttpContext.java:1309)
17:38:02,750 ERROR [STDERR] at
org.mortbay.http.HttpServer.service(HttpServer.java:744)
17:38:02,750 ERROR [STDERR] at
org.jboss.jetty.Jetty.service(Jetty.java:525)
17:38:02,750 ERROR [STDERR] at
org.mortbay.http.HttpConnection.service(HttpConnection.java:743)
17:38:02,765 ERROR [STDERR] at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916)
17:38:02,765 ERROR [STDERR] at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:758)
17:38:02,765 ERROR [STDERR] at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145)
17:38:02,765 ERROR [STDERR] at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287)
17:38:02,765 ERROR [STDERR] at

Re: [JBoss-dev] UDS DeployedURL.watchedUrl

[Larry Sandereson]

This sounds like something I added for exploded deployments.  (the url to
watch for redeployment is the app-specific xml: ejb-jar.xml for ejbs,
application.xml for ears, ...)  It is an MBean operation in MainDeployer
that returns the corresponding DeploymentInfo's watch field.

-Larry

 Can someone please explain to me what DeployedURL.watchedUrl is for?

 --jason

 -
 This mail sent through IMP: http://horde.org/imp/

 ___

 Don't miss the 2002 Sprint PCS Application Developer's Conference
 August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-548983 ] Wrong mapping for SAPDB type boolean

[noreply]

Bugs item #548983, was opened at 2002-04-26 02:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=548983group_id=22866

Category: JBossCMP
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ingo Brüll (ibruell)
Assigned to: Scott M Stark (starksm)
Summary: Wrong mapping for SAPDB type boolean

Initial Comment:
In standardjaws.xml and standardjbosscmp-jdbc.xml is a wrong 
mapping for boolean. It should be:

mapping
   java-
typejava.lang.Boolean/java-type
   jdbc-typeBIT/jdbc-
type
   sql-typeBOOLEAN/sql-type
/mapping

That 
affect all versions


--

Comment By: Scott M Stark (starksm)
Date: 2002-05-21 07:54

Message:
Logged In: YES 
user_id=175228

Changed in 3.0 and main

--

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

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-557209 ] IntiialContext() fails to remote server

[noreply]

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

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Christian Riege (lqd)
Assigned to: Scott M Stark (starksm)
Summary: IntiialContext() fails to remote server

Initial Comment:
scott,

this seems to be something w/ respect to your changes
in org.jnp.naming. the current Branch_3_0 gives me an
exception when connecting to a JNDI server that is
running on a remote machine (above are the Properties
that I'm trying to use):

Using: {jnp.port=12345,
java.naming.provider.url=195.145.13.46:1099,
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory,
jnp.rmiPort=0, jnp.localPort=9876,
java.naming.factory.url.pkgs=org.jnp.interfaces,
jnp.localAddress=195.145.13.33}
javax.naming.CommunicationException.  Root exception is
java.rmi.ConnectException: Connection refused to host:
127.0.0.1; nested exception is: 
java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:350)
at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:137)
at
java.net.PlainSocketImpl.connect(PlainSocketImpl.java:124)
at java.net.Socket.init(Socket.java:268)
at java.net.Socket.init(Socket.java:95)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:20)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:115)
at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:494)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:169)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:78)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:445)
at
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:429)
at
javax.naming.InitialContext.lookup(InitialContext.java:345)


it could be that there are just some of my Properties
messed up; however this used to work up until yesterday.

regards,
  christian

--

Comment By: Scott M Stark (starksm)
Date: 2002-05-21 08:00

Message:
Logged In: YES 
user_id=175228

I don't see that there is any access to the stub endpoint 
information other than parsing its toString form which I'm 
not going to do. Go beat up on your linux vendor for 
defaulting the hostname to the localhost interface. RedHat 
is notorious for this.

--

Comment By: Christian Riege (lqd)
Date: 2002-05-21 06:21

Message:
Logged In: YES 
user_id=176671

adrian and scott,

thanks for the pointers; turned out my /etc/hosts had the
hostname of the machine pointing to 127.0.0.1. Once I
changed that to the IP of my eth0 interface things started
working again.

just a quick thought w/o having looked at the JBoss source:
would it be possible to ensure that we don't return a stub
pointing to 127.0.0.1 if we know that the call came in via
an interface other than 127.0.0.1?!

--

Comment By: Adrian Brock (ejort)
Date: 2002-05-17 08:27

Message:
Logged In: YES 
user_id=9459

Try this link. This indicates an error in your ip config.

http://main.jboss.org/forums/thread.jsp?forum=67thread=8092

Regards,
Adrian

--

Comment By: Scott M Stark (starksm)
Date: 2002-05-17 08:15

Message:
Logged In: YES 
user_id=175228

This is working for me. I initially saw the same problem 
and I added a log statement to show the RMI stub exported 
on the server and I had the server address setup 
incorrectly. After fixing that this test program works fine:

jboss-all 1146cat tstNS.java
import java.util.Properties;
import javax.naming.*;

class tstNS
{
   public static void main(String[] args) throws Exception
   {
  Properties env = new Properties();
  env.setProperty
(java.naming.factory.initial,org.jnp.interfaces.NamingCo
ntextFactory);
  env.setProperty
(java.naming.factory.pkgs,org.jnp.interfaces);
  env.setProperty
(java.naming.provider.url,172.17.66.53:1099);
  env.setProperty(jnp.port, 12345);
  env.setProperty(jnp.rmiPort, 0);
  env.setProperty(jnp.localPort, 9876);
  env.setProperty(jnp.localAddress,172.17.66.54);
  InitialContext ctx = new InitialContext(env);
  System.out.println(Created InitialContext);
  Object ut = ctx.lookup(UserTransaction);
  System.out.println(Found UserTransaction, ut=+ut);

[JBoss-dev] [ jboss-Bugs-558052 ] ENC is not set in ServletContextListener

[noreply]

Bugs item #558052, was opened at 2002-05-19 19:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=558052group_id=22866

Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Bogdan Ghidireac (ghidi)
Assigned to: Nobody/Anonymous (nobody)
Summary: ENC is not set in ServletContextListener

Initial Comment:
I want to use ServletContextListener to create an EJB 
used to initialize my application. 
When I am trying to lookup my bean, I get a 
javax.naming.NameNotFoundException: env not bound

I am using JBoss3.0.0RC2-Jetty.

With JBoss3.0.0RC2-tomcat it is working fine.

Regards,
Bogdan

--

Comment By: Jan Bartel (janb)
Date: 2002-05-21 15:18

Message:
Logged In: YES 
user_id=45251

I have fixed this in Jetty HEAD. It will be incorporated
into JBoss HEAD in the next day or so.

--

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

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment

[Bill Burke]

Guys,

I've been thinking about this.  Wouldn't it be better/easier to create a UI
configuration tool than do this port mapper stuff?  What I mean is a JBoss
configuration tool that for each component asks you what port you want your
JNDI server to run on, Web server, etc... as well as other config
information.  This tool could be smart enough to determine if something is
already running under a certain port and tell you so you have to decide the
new port to run under.  This stuff would not only be usefull for a multiple
developer environment, but would be extremely useful in an Installer and
management GUI, and IMHO, would be more reep more significant benefits for
the JBoss project.

IMHO, what you're proposing would just create ugliness and complication in
the code base.  But maybe I'm wrong here.  I don't know.  Do whatever you
want.

Bill

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Mike
 Finn
 Sent: Tuesday, May 21, 2002 8:02 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
 environment



 Very basic question, but I have to ask it: how should the service bindings
 service be exposed? I assume as MBean? MBean with static port manager
 bound in JNDI (might have the chicken/egg problem here, since
 JNDI would be
 a dependency and JNDI would need to find what port on which to run...)?

 #mike

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of
 Juha-P Lindfors
 Sent: Tuesday, May 21, 2002 6:36 AM
 To: JBoss-dev
 Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
 environment


 On Mon, 20 May 2002, Dain Sundstrom wrote:

  [I moved this to the dev list]
 
  I think the real power of JMX is you can have disparate components that
  can all talk to a central object without becoming tightly coupled.
 
  Here is my idea:
 
  We have an optional port server MBean.  Before a service opens a port it
  checks for the existence of the port server, and if (and only if) it
  exists, it asks the port server for a port passing the service name and
  port name (both are just any string).  If the port service doesn't
  exist, it follows the default code.
 
  This would require that the MBean wrappers for any serveice that opens a
  port to follow know about the possibility of a port service, but I don't
  think that is a big deal. Most MBeans already know about many services.

 another possibility would be to persist these attributes containing port
 numbers to a single location, e.g. config/ports.properties where all ports
 would be in a single file.

 This would not require the MBean developers to change their coding in any
 way (Jules point about simple contracts) but would just require us to
 config the initial server setup for the MBeans in question to use the same
 location for these attributes. New user MBeans could also be configured to
 use the same storage. Same approach would work for other system resources
 as well (whatever they might be) without having to impose yet another
 contractual requirement for MBean developers.

 However, this requires that we convert to using persistent mbeans, which
 is a more long term project. Short term your solution is the easier fix.

 my .02

 -- Juha



 ___

 Don't miss the 2002 Sprint PCS Application Developer's Conference
 August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


 ___

 Don't miss the 2002 Sprint PCS Application Developer's Conference
 August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Feature Requests-558735 ] Pattern Object Name Creation w. Hashtabl

[noreply]

Feature Requests item #558735, was opened at 2002-05-21 08:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376688aid=558735group_id=22866

Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Open
Priority: 7
Submitted By: Andreas Schaefer (schaefera)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pattern Object Name Creation w. Hashtabl

Initial Comment:
The Pattern Object Name (to search for MBeans) should 
be created by a Hashtable for the properties the same 
way as with a String.
Therefore a pattern ObjectName should work the same 
way for:
   new ObjectName( jboss:name=Hello,* );
and
   Hashtable properties = new Hashtable();
   properties.put( name, Hello );
   properties.put( *, * );
   new ObjectName( jboss, properties );

Currently it does not do this.

Suggestion: allow a key in the properties Hashtable to 
be of *, allow it, take it out and set 
isPropertyPattern() to true.

Reason: the ObjectNameConverter allows people also to 
convert a property value with a comma ,. But this 
only works with a Hashtable otherwise parsing fails.

Andy

--

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

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment

[Scott M Stark]

Ok, and you will have that ready by?

Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 21, 2002 8:32 AM
Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
environment


 Guys,

 I've been thinking about this.  Wouldn't it be better/easier to create a
UI
 configuration tool than do this port mapper stuff?  What I mean is a JBoss
 configuration tool that for each component asks you what port you want
your
 JNDI server to run on, Web server, etc... as well as other config
 information.  This tool could be smart enough to determine if something is
 already running under a certain port and tell you so you have to decide
the
 new port to run under.  This stuff would not only be usefull for a
multiple
 developer environment, but would be extremely useful in an Installer and
 management GUI, and IMHO, would be more reep more significant benefits for
 the JBoss project.

 IMHO, what you're proposing would just create ugliness and complication in
 the code base.  But maybe I'm wrong here.  I don't know.  Do whatever you
 want.

 Bill

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of Mike
  Finn
  Sent: Tuesday, May 21, 2002 8:02 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
  environment
 
 
 
  Very basic question, but I have to ask it: how should the service
bindings
  service be exposed? I assume as MBean? MBean with static port manager
  bound in JNDI (might have the chicken/egg problem here, since
  JNDI would be
  a dependency and JNDI would need to find what port on which to run...)?
 
  #mike
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of
  Juha-P Lindfors
  Sent: Tuesday, May 21, 2002 6:36 AM
  To: JBoss-dev
  Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
  environment
 
 
  On Mon, 20 May 2002, Dain Sundstrom wrote:
 
   [I moved this to the dev list]
  
   I think the real power of JMX is you can have disparate components
that
   can all talk to a central object without becoming tightly coupled.
  
   Here is my idea:
  
   We have an optional port server MBean.  Before a service opens a port
it
   checks for the existence of the port server, and if (and only if) it
   exists, it asks the port server for a port passing the service name
and
   port name (both are just any string).  If the port service doesn't
   exist, it follows the default code.
  
   This would require that the MBean wrappers for any serveice that opens
a
   port to follow know about the possibility of a port service, but I
don't
   think that is a big deal. Most MBeans already know about many
services.
 
  another possibility would be to persist these attributes containing port
  numbers to a single location, e.g. config/ports.properties where all
ports
  would be in a single file.
 
  This would not require the MBean developers to change their coding in
any
  way (Jules point about simple contracts) but would just require us to
  config the initial server setup for the MBeans in question to use the
same
  location for these attributes. New user MBeans could also be configured
to
  use the same storage. Same approach would work for other system
resources
  as well (whatever they might be) without having to impose yet another
  contractual requirement for MBean developers.
 
  However, this requires that we convert to using persistent mbeans, which
  is a more long term project. Short term your solution is the easier fix.
 
  my .02
 
  -- Juha
 
 
 
  ___
 
  Don't miss the 2002 Sprint PCS Application Developer's Conference
  August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
  ___
 
  Don't miss the 2002 Sprint PCS Application Developer's Conference
  August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development


 ___

 Don't miss the 2002 Sprint PCS Application Developer's Conference
 August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



___

Don't miss the 2002 Sprint PCS Application Developer's 

RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment

[Bill Burke]

All I'm saying is that this is just another configuration file in an already
complicated system.  Energies might be spent in a better direction.  I'll
shut up now...

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
 M Stark
 Sent: Tuesday, May 21, 2002 11:56 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
 environment


 Ok, and you will have that ready by?
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 - Original Message -
 From: Bill Burke [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Tuesday, May 21, 2002 8:32 AM
 Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
 environment


  Guys,
 
  I've been thinking about this.  Wouldn't it be better/easier to create a
 UI
  configuration tool than do this port mapper stuff?  What I mean
 is a JBoss
  configuration tool that for each component asks you what port you want
 your
  JNDI server to run on, Web server, etc... as well as other config
  information.  This tool could be smart enough to determine if
 something is
  already running under a certain port and tell you so you have to decide
 the
  new port to run under.  This stuff would not only be usefull for a
 multiple
  developer environment, but would be extremely useful in an Installer and
  management GUI, and IMHO, would be more reep more significant
 benefits for
  the JBoss project.
 
  IMHO, what you're proposing would just create ugliness and
 complication in
  the code base.  But maybe I'm wrong here.  I don't know.  Do
 whatever you
  want.
 
  Bill
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On
 Behalf Of Mike
   Finn
   Sent: Tuesday, May 21, 2002 8:02 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
   environment
  
  
  
   Very basic question, but I have to ask it: how should the service
 bindings
   service be exposed? I assume as MBean? MBean with static
 port manager
   bound in JNDI (might have the chicken/egg problem here, since
   JNDI would be
   a dependency and JNDI would need to find what port on which
 to run...)?
  
   #mike
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On Behalf Of
   Juha-P Lindfors
   Sent: Tuesday, May 21, 2002 6:36 AM
   To: JBoss-dev
   Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
   environment
  
  
   On Mon, 20 May 2002, Dain Sundstrom wrote:
  
[I moved this to the dev list]
   
I think the real power of JMX is you can have disparate components
 that
can all talk to a central object without becoming tightly coupled.
   
Here is my idea:
   
We have an optional port server MBean.  Before a service
 opens a port
 it
checks for the existence of the port server, and if (and only if) it
exists, it asks the port server for a port passing the service name
 and
port name (both are just any string).  If the port service doesn't
exist, it follows the default code.
   
This would require that the MBean wrappers for any serveice
 that opens
 a
port to follow know about the possibility of a port service, but I
 don't
think that is a big deal. Most MBeans already know about many
 services.
  
   another possibility would be to persist these attributes
 containing port
   numbers to a single location, e.g. config/ports.properties where all
 ports
   would be in a single file.
  
   This would not require the MBean developers to change their coding in
 any
   way (Jules point about simple contracts) but would just require us to
   config the initial server setup for the MBeans in question to use the
 same
   location for these attributes. New user MBeans could also be
 configured
 to
   use the same storage. Same approach would work for other system
 resources
   as well (whatever they might be) without having to impose yet another
   contractual requirement for MBean developers.
  
   However, this requires that we convert to using persistent
 mbeans, which
   is a more long term project. Short term your solution is the
 easier fix.
  
   my .02
  
   -- Juha
  
  
  
   ___
  
   Don't miss the 2002 Sprint PCS Application Developer's Conference
   August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
  
   ___
   Jboss-development mailing list
   [EMAIL PROTECTED]
   https://lists.sourceforge.net/lists/listinfo/jboss-development
  
  
   ___
  
   Don't miss the 2002 Sprint PCS Application Developer's Conference
   August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
  
   ___
   Jboss-development mailing list
   [EMAIL 

Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment

[Dain Sundstrom]

Not exactly, Bill.  By default the mapping should just return the 
default mapping requested by the system.  If and only if the user wants 
to run multiple copies of JBoss on a single machine, do they add a 
configuration mapping to the mapper.

I should be no more complex then what we currently have with the ability 
to centrally mange ports. This is the best of both worlds if you ask me.

Anyway, GUIs need to run on top of JMX (configuration files), because 
not all hardware has a graphical display.

-dain

Bill Burke wrote:

 All I'm saying is that this is just another configuration file in an already
 complicated system.  Energies might be spent in a better direction.  I'll
 shut up now...
 
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
M Stark
Sent: Tuesday, May 21, 2002 11:56 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
environment


Ok, and you will have that ready by?

Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 21, 2002 8:32 AM
Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
environment



Guys,

I've been thinking about this.  Wouldn't it be better/easier to create a

UI

configuration tool than do this port mapper stuff?  What I mean

is a JBoss

configuration tool that for each component asks you what port you want

your

JNDI server to run on, Web server, etc... as well as other config
information.  This tool could be smart enough to determine if

something is

already running under a certain port and tell you so you have to decide

the

new port to run under.  This stuff would not only be usefull for a

multiple

developer environment, but would be extremely useful in an Installer and
management GUI, and IMHO, would be more reep more significant

benefits for

the JBoss project.

IMHO, what you're proposing would just create ugliness and

complication in

the code base.  But maybe I'm wrong here.  I don't know.  Do

whatever you

want.

Bill


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On

Behalf Of Mike

Finn
Sent: Tuesday, May 21, 2002 8:02 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
environment



Very basic question, but I have to ask it: how should the service

bindings

service be exposed? I assume as MBean? MBean with static

port manager

bound in JNDI (might have the chicken/egg problem here, since
JNDI would be
a dependency and JNDI would need to find what port on which

to run...)?

#mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Juha-P Lindfors
Sent: Tuesday, May 21, 2002 6:36 AM
To: JBoss-dev
Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers
environment


On Mon, 20 May 2002, Dain Sundstrom wrote:


[I moved this to the dev list]

I think the real power of JMX is you can have disparate components

that

can all talk to a central object without becoming tightly coupled.

Here is my idea:

We have an optional port server MBean.  Before a service

opens a port
it

checks for the existence of the port server, and if (and only if) it
exists, it asks the port server for a port passing the service name

and

port name (both are just any string).  If the port service doesn't
exist, it follows the default code.

This would require that the MBean wrappers for any serveice

that opens
a

port to follow know about the possibility of a port service, but I

don't

think that is a big deal. Most MBeans already know about many

services.

another possibility would be to persist these attributes

containing port

numbers to a single location, e.g. config/ports.properties where all

ports

would be in a single file.

This would not require the MBean developers to change their coding in

any

way (Jules point about simple contracts) but would just require us to
config the initial server setup for the MBeans in question to use the

same

location for these attributes. New user MBeans could also be

configured
to

use the same storage. Same approach would work for other system

resources

as well (whatever they might be) without having to impose yet another
contractual requirement for MBean developers.

However, this requires that we convert to using persistent

mbeans, which

is a more long term project. Short term your solution is the

easier fix.

my .02

-- Juha



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-558762 ] source-all target is not buildable

[noreply]

Bugs item #558762, was opened at 2002-05-21 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=558762group_id=22866

Category: Build System
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to: Jason Dillon (user57)
Summary: source-all target is not buildable

Initial Comment:
If I create the source-all target and take the resulting 
jboss-3.0.0RC3-external-src.tgz
jboss-3.0.0RC3-free-src.tgz
files, and unarchive them and try to do a build
it fails as follows:

[starksm@banshee build]$ ./build.sh
build.sh: Could not locate Ant; check $ANT or 
$ANT_HOME.
[starksm@banshee build]$ 

We need a single source archive that is buildable 
for releases.


--

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

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Re: [JBoss-user] Does JBoss3 have Problems Deploying Similar ejb-jars in Different EARs

[Scott M Stark]

Read the RC3 release notes on how to isolate ears.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Hunter Hillegas [EMAIL PROTECTED]
To: JBoss Dev [EMAIL PROTECTED]; David Jencks
[EMAIL PROTECTED]
Sent: Tuesday, May 21, 2002 10:09 AM
Subject: [JBoss-dev] Re: [JBoss-user] Does JBoss3 have Problems Deploying
Similar ejb-jars in Different EARs


 So if I have two different versions of my application, I have to use a
 totally different packaging mechanism to get them both to deploy?

 Right now, this is what I have:

 EAR1
 EAR2

 Both contain *similar* ejb-jars. The ejb-jars contain classes with the
same
 names and similar packaging, but different contents. Both EARs use
different
 ejb-names, different JNDI names, and different web app contexts.

 They are still conflicting, as JBoss only sees the first copy of the class
 file that is deployed.

 So, just to be crystal clear, my choices are:

 1. repackage ejb-jar, use different names for the classes, etc...
 2. run multiple copies of JBoss

 I don't like the first option since the ejb-jars are almost the same, and
 one is just a CVS branch off the trunk. This would make diffing between
the
 two branches really hard.

 From the recent discussion on the dev list, running multiple copies seems
to
 still be a little problematic? Anyway, this is something I'm going to have
 to do often since customers request modifications to our standard
code-base
 all the time. Each mod version will require another instance of JBoss?

 Was it Dain that suggested that there be a config switch for people who
 don't need visibility between deployed EARs? I can see how that feature is
 powerful and useful for some, I think making that optional would be a
great
 thing, since for people like me (and ISPs that could easily run into the
 same problem), this is a tough problem to solve.

 Hunter

  From: David Jencks [EMAIL PROTECTED]
  Reply-To: [EMAIL PROTECTED]
  Date: Thu, 16 May 2002 19:42:38 -0400
  To: [EMAIL PROTECTED]
  Subject: Re: [JBoss-user] Does JBoss3 have Problems Deploying Similar
ejb-jars
  in Different EARs
 
  On 2002.05.16 19:05:43 -0400 Hunter Hillegas wrote:
  Whoah... Really?
 
  yup
 
  So I can't have two ejb-jars with classes that are named the same, in
  different ears?
 
  H...
 
  We have a content management system with EJBs that we need to deploy in
  several different customer instance EARs. Are you saying we can't do
that
  without changing the classnames or packaging?
 
  For some reason I thought that each deployed EAR had its own namespace
  and
  you could do this...
 
  Did I misunderstand you?
 
  nope.
 
  You can have lots of copies of the same ejb class deployed under
different
  ejb name and jndi names.  Just be sure to only deploy one copy of the
  class.  You might want to deploy the classes before any of the dd's, and
  separate all the dd's from any classes.
 
  You can't have 2 versions of the same class.  They will interfere, as
you
  discovered.
 
  Basically we decided that we would initially support visibility between
  deployment packages with hot-redeploy, since this is a feature
previously
  unavailable anywhere as far as I know.  Once this is thoroughly stable
and
  well tested we will consider whether it is really advisable to have
several
  of these sets of UnifiedClassLoaders at once in one vm.  For now, you
  should run several jboss servers in different vms.
 
  david jencks
 
 
  Hunter
 
  From: David Jencks [EMAIL PROTECTED]
  Reply-To: [EMAIL PROTECTED]
  Date: Thu, 16 May 2002 18:59:18 -0400
  To: [EMAIL PROTECTED]
  Subject: Re: [JBoss-user] Does JBoss3 have Problems Deploying Similar
  ejb-jars
  in Different EARs
 
  JBoss 3 doesnt' support having 2 classes with the same name, no matter
  how
  you package them.  It does support classes in one ear seeing the
  classes in
  the other ear(s).
 
  david jencks
 
  On 2002.05.16 18:03:07 -0400 Hunter Hillegas wrote:
  I'm trying to get this damn EAR to deploy and I started wondering if
  JBoss3
  has trouble deploying an EAR if another EAR has a similar ejb-jar...
 
  Basically I have two versions of an ejb-jar. One has a bean with one
  extra
  CMP variable.
 
  The first archive deploys just fine. The second one deploys okay if
  the
  first is not deployed. If the first one is deployed and I try to
  deploy
  the
  second then I get a message that the bean class doesn't contain an
  accessor
  for the extra variable that exists in the second ejb-jar...
 
  Any ideas?
 
  Hunter
 
 
  ___
 
  Have big pipes? SourceForge.net is looking for download mirrors. We
  supply
  the hardware. You get the recognition. Email Us:
  [EMAIL PROTECTED]
  ___
  JBoss-user mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-user
 
 
 
  

Re: [JBoss-dev] Re: [JBoss-user] JBoss 3.0 ClassLoader Architecture

[Scott M Stark]

- Original Message -
From: David Ward [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: JBoss Dev [EMAIL PROTECTED]
Sent: Tuesday, May 21, 2002 6:33 AM
Subject: [JBoss-dev] Re: [JBoss-user] JBoss 3.0 ClassLoader Architecture



 1) In your document, you state (concerning the WAR Loader):
 The WAR Loader is a servlet container specific ClassLoader that
 delegates to the Web ENCLoader as its parent class loader. The default
 behavior is to load from its parent class loader and then the war
 WEB-INF/{classes,lib} directories. If the servlet 2.3 class loading
 model is enabled it will first load from the war WEB-INF/{classes,lib}
 and then the parent class loader.
 Is the servlet 2.3 class loading model enabled or not by default in
 jboss3rc3-tomcat4?  What about with Jetty 4?  Where is this configured?

Not enabled by default in either Jetty or Tomcat. See the
Java2ClassLoadingCompliance
attribute:
!-- If true, Jetty first delegates loading a class to the
pp's --
!-- parent class loader (a la Java 2). If false, Jetty follows
--
!--  Servlet 2.3 specification, and tries the webapp's own
r  --
!-- first (for non-system
 --
attribute name=Java2ClassLoadingCompliancetrue/attribute

 2) Under Disadvantages, you state:
 Deployments that depend on different versions of the a given class need
 to be isolated in seperate JBoss servers. This will be addressed in the
 RC3 release with an ability to isolate classes using ears.
 Since rc3 is out, does the ear isolation method work?

See the RC3 change notes.

 3) Is there any way you can share a bit of info on how jboss 2.4.3+
 classloading works?  Maybe not to the detail you did for 3.0, but for
 those of us stuck with 2.4 at work until 3.0 goes final, it would be
 nice to know.

Basic Java2 parent delegation model similar to weblogic. Both web
containers support Java2ClassLoadingCompliance in 2.4.6



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Automated JBoss(JBoss_3_0_0_RC3) Testsuite Results: 21-May-2002

[noreply]

Number of tests run:   593



Successful tests:  593
Errors:0
Failures:  0



[time of test: 21 May 2002 10:35 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.4]

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

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

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





HURRAY - everything worked!



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



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Re: JBossMX Timer Problem

[Adrian Brock]

Hi Andreas,

This should be fixed now.

Regards,
Adrian

 Hi Andreas,
 
 Apologies. I should have put a test for this in the
 testsuite,
 I broke this a couple of weeks ago.
 Thanks for your test, although it does have a small
 mistake which
 I'll fix as well.
 
 I'll commit this evening when I can get CVS access.
 
 Regards,
 Adrian
 
 
 From: Andreas Schaefer [EMAIL PROTECTED]
 To: Juha Lindfors [EMAIL PROTECTED],
 [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED]
 Subject: JBossMX Timer Problem
 Date: Mon, 20 May 2002 17:47:07 -0700
 
 Hi Geeks
 
 Found a problem with two notification registered at
 the Timer MBean. It seems that even the period is
 set correctly (from Timer MBean) the periods are
 not calculated correctly.
 
 Please have a look at the new test
 testTwoNotificationProducers
 in the timer.BasicTestCase which register two
 notifications (how
 ever created this names should be punished for that)
 with different
 periods. The test then checks if the order of the
 notifications and
 the time between the notifications are correct.
 
 This problem is causing my Scheduler to fail with
 two
 Schedulers.
 
 Have fun
 
 x
 Andreas Schaefer
 Senior Consultant
 JBoss Group, LLC
 x
 
 
 
 
 __
 __
 MSN Photos is the easiest way to share and print your
 photos: 
 http://photos.msn.com/support/worldwide.aspx
 
 
 __
 
 
 Don't miss the 2002 Sprint PCS Application
 Developer's Conference
 August 25-28 in Las Vegas --
 http://devcon.sprintpcs.com/adp/index.cfm
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-dev
 lopment


* * *

View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=16076

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] ObjectNameConverter changes !!!

[Andreas Schaefer]

The ObjectNameConverter does not also convert
forbidden characters in the key (why not), on the
conversion back it does add a ,* on the string
representation and a * key on the property list
hashtable when it is a pattern Object Name for
queries.
It also contains a warning that you SHOULD NEVER
use convert( String ) when a key or value contains a
comma because then the parsing will FAIL !!!

Please let me know if this is a problem for you
and have fun

x
Andreas Schaefer
Senior Consultant
JBoss Group, LLC
x



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] [ jboss-Bugs-558434 ] Verifier does not allow ejbFindMETHOD

[Ignacio Coloma]

Sorry, should have said it: RC2

[EMAIL PROTECTED] wrote:

Bugs item #558434, was opened at 2002-05-20 16:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=558434group_id=22866

Category: JBossServer

Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Ignacio Coloma (alu1344)

Assigned to: Jay Walters (jwalters)

Summary: Verifier does not allow ejbFindMETHOD

Initial Comment:
Right now the verifier claims that ejbFindMETHOD
methods in CMP entity beans are against 10.6.2, but
this point of the spec only says that the user may not
provide the finder implementation, which is not the
case. ejbFindMETHOD behaviour is specified on 10.7.3

--

Comment By: Jay Walters (jwalters)

Date: 2002-05-20 16:55

Message:
Logged In: YES 
user_id=183794

I will take a look at it.  What version of V3.0 are you 
using?  Latest CVS, RC2, RC1?

--

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

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development






___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] NoSuchMethodError in MainDeployer

[Dain Sundstrom]

I can't seem to get the server to start anymore.  I did a fresh checkout 
and rebuild.  When I start the server I get the following exception:

13:50:58,280 ERROR [Server] start failed
org.jboss.deployment.DeploymentException: Could not create deployment: 
file:/hom
e/dain/work/jboss/jboss-head/build/output/jboss-3.1.0alpha/server/default/conf/j
boss-service.xml; - nested throwable: (java.lang.NoSuchMethodError)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:698)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472)
 at java.lang.reflect.Method.invoke(Native Method)
 at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
 at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216)
 at org.jboss.Main.boot(Main.java:148)
 at org.jboss.Main$1.run(Main.java:381)
 at java.lang.Thread.run(Thread.java:484)
java.lang.NoSuchMethodError
 at 
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.getLast
Modified(URLDeploymentScanner.java:304)
 at 
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.deploye
d(URLDeploymentScanner.java:274)
 at 
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:375)
 at 
org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDe
ploymentScanner.java:555)
 at 
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:434)
 at 
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:237)
 at 
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
98)
 at java.lang.reflect.Method.invoke(Native Method)
 at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
 at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at 
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:867)
 at $Proxy0.start(Unknown Source)
 at 
org.jboss.system.ServiceController.start(ServiceController.java:339)
 at java.lang.reflect.Method.invoke(Native Method)
 at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
 at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
 at $Proxy3.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:341)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:686)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472)
 at java.lang.reflect.Method.invoke(Native Method)
 at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
 at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216)
 at org.jboss.Main.boot(Main.java:148)
 at org.jboss.Main$1.run(Main.java:381)
 at java.lang.Thread.run(Thread.java:484)

-dain


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] NoSuchMethodError in MainDeployer

[Francisco Reverbel]

Did you buid JBoss with JDK 1.4 and attempted to start the server with 
IBM's 1.3 or 1.3.1 VM for Linux, by any chance? I had trouble in this
case.

It appears that a 1.4-generated server barfs with IBM's 1.3.x VMs for 
Linux. Do not ask me why...  ;-(

Best,

Francisco

On Tue, 21 May 2002, Dain Sundstrom wrote:

 I can't seem to get the server to start anymore.  I did a fresh checkout 
 and rebuild.  When I start the server I get the following exception:
 
 13:50:58,280 ERROR [Server] start failed
 org.jboss.deployment.DeploymentException: Could not create deployment: 
 file:/hom
 e/dain/work/jboss/jboss-head/build/output/jboss-3.1.0alpha/server/default/conf/j
 boss-service.xml; - nested throwable: (java.lang.NoSuchMethodError)
  at org.jboss.deployment.MainDeployer.start(MainDeployer.java:698)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472)
  at java.lang.reflect.Method.invoke(Native Method)
  at 
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
 nDispatcher.java:284)
  at 
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318)
  at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216)
  at org.jboss.Main.boot(Main.java:148)
  at org.jboss.Main$1.run(Main.java:381)
  at java.lang.Thread.run(Thread.java:484)
 java.lang.NoSuchMethodError
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.getLast
 Modified(URLDeploymentScanner.java:304)
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.deploye
 d(URLDeploymentScanner.java:274)
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
 tScanner.java:375)
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDe
 ploymentScanner.java:555)
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
 canner.java:434)
  at 
 org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
 bstractDeploymentScanner.java:237)
  at 
 org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
 98)
  at java.lang.reflect.Method.invoke(Native Method)
  at 
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
 nDispatcher.java:284)
  at 
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at 
 org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
 ler.java:867)
  at $Proxy0.start(Unknown Source)
  at 
 org.jboss.system.ServiceController.start(ServiceController.java:339)
  at java.lang.reflect.Method.invoke(Native Method)
  at 
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
 nDispatcher.java:284)
  at 
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
  at $Proxy3.start(Unknown Source)
  at org.jboss.deployment.SARDeployer.start(SARDeployer.java:341)
  at org.jboss.deployment.MainDeployer.start(MainDeployer.java:686)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472)
  at java.lang.reflect.Method.invoke(Native Method)
  at 
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
 nDispatcher.java:284)
  at 
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318)
  at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216)
  at org.jboss.Main.boot(Main.java:148)
  at org.jboss.Main$1.run(Main.java:381)
  at java.lang.Thread.run(Thread.java:484)
 
 -dain
 
 
 ___
 
 Don't miss the 2002 Sprint PCS Application Developer's Conference
 August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] deploy error in scanner thread (cvs head)

[Jason Dillon]

Chances are this is due to a problem accessing the Logger log field... when 
did Sun decide not to support nested classes... this is getting ugly.

--jason


On Tuesday 21 May 2002 08:43 am, Justin Casp wrote:
 Hi List,
 I've just recently begun to see this error occur sporadically when starting
 JBoss after being freshly built from the cvs head.  I was able to find a
 build on another machine that's a few days old, and it boots fine. 
 However, when I deploy a user ear on this older build (very simple example
 from Wrox book) the same error occurs.  With the latest cvs code, this
 error happens when deploying internal Jboss packages (not sure of the
 terminology).  Since it occurs in the scanner thread, I can't
 undeploy/redeploy the test ear.  Any ideas on what may be causing this? 
 I've tried doing a 'build.sh clean' then 'build.sh' but it still happens.
 Let me know if I can help in tracking this down.  I was doing this test ear
 in order to report another bug, so now I have nested problems.
 Justin


 11:20:13,577 ERROR [MainDeployer] could not start deployment:
 file:/home/casp/projects/jboss/jboss-all/build/output/jboss-3.1.0alpha/serv
er/default/deploy/localobjects.jar java.lang.NullPointerException
 at
 org.jboss.util.NestedThrowable$Util.getBoolean(NestedThrowable.java:108)
 at org.jboss.util.NestedThrowable.clinit(NestedThrowable.java:39)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:120)
 at
 org.jboss.util.NestedThrowable$Util.class$(NestedThrowable.java:27) at
 org.jboss.util.NestedThrowable$Util.clinit(NestedThrowable.java:100)
 at org.jboss.util.NestedException.init(NestedException.java:50)
 at
 org.jboss.deployment.DeploymentException.init(DeploymentException.java:44
) at
 org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStartComman
d.java:190) at
 org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartCommand.ja
va:84) at
 org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java
:384) at
 org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.jav
a:198) at
 org.jboss.ejb.EntityContainer.startService(EntityContainer.java:360)
 at
 org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198)
 at org.jboss.ejb.Container.invoke(Container.java:782)
 at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1024)
 at
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at
 org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja
va:867) at $Proxy0.start(Unknown Source)
 at
 org.jboss.system.ServiceController.start(ServiceController.java:339)
 at java.lang.reflect.Method.invoke(Native Method)
 at
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa
tcher.java:284) at
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
 at $Proxy19.start(Unknown Source)
 at org.jboss.ejb.EjbModule.startService(EjbModule.java:442)
 at
 org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198)
 at java.lang.reflect.Method.invoke(Native Method)
 at
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa
tcher.java:284) at
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at
 org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja
va:867) at $Proxy0.start(Unknown Source)
 at
 org.jboss.system.ServiceController.start(ServiceController.java:339)
 at java.lang.reflect.Method.invoke(Native Method)
 at
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa
tcher.java:284) at
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
 at $Proxy5.start(Unknown Source)
 at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:391)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:693)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:528)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:490)
 at java.lang.reflect.Method.invoke(Native Method)
 at
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa
tcher.java:284) at
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
 at $Proxy4.deploy(Unknown Source)
 at
 org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScann
er.java:405) at
 org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeployme
ntScanner.java:586) at
 org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner
.java:465) at
 

Re: [JBoss-dev] [ jboss-Feature Requests-558735 ] Pattern Object Name Creation w. Hashtabl

[Adrian Brock]

This is done.

Regards,
Adrian

 Feature Requests item #558735, was opened at
 2002-05-21 08:44
 You can respond by visiting: 
 http://sourceforge.net/tracker/?func=detailatid=37668
 aid=558735group_id=22866
 
 Category: JBossMX
 Group: v3.0 Rabbit Hole
 Status: Open
 Priority: 7
 Submitted By: Andreas Schaefer (schaefera)
 Assigned to: Nobody/Anonymous (nobody)
 Summary: Pattern Object Name Creation w. Hashtabl
 
 Initial Comment:
 The Pattern Object Name (to search for MBeans) should
 
 be created by a Hashtable for the properties the same
 
 way as with a String.
 Therefore a pattern ObjectName should work the same 
 way for:
new ObjectName( jboss:name=Hello,* );
 and
Hashtable properties = new Hashtable();
properties.put( name, Hello );
properties.put( *, * );
new ObjectName( jboss, properties );
 
 Currently it does not do this.
 
 Suggestion: allow a key in the properties Hashtable
 to 
 be of *, allow it, take it out and set 
 isPropertyPattern() to true.
 
 Reason: the ObjectNameConverter allows people also to
 
 convert a property value with a comma ,. But this 
 only works with a Hashtable otherwise parsing fails.
 
 Andy
 
 --
 ---
 
 You can respond by visiting: 
 http://sourceforge.net/tracker/?func=detailatid=37668
 aid=558735group_id=22866
 
 __
 
 
 Don't miss the 2002 Sprint PCS Application
 Developer's Conference
 August 25-28 in Las Vegas --
 http://devcon.sprintpcs.com/adp/index.cfm
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-dev
 lopment


* * *

View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=16098

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] NoSuchMethodError in MainDeployer

[Dain Sundstrom]

I only have jdk1.3.1_01 on this box.

Francisco Reverbel wrote:

 Did you buid JBoss with JDK 1.4 and attempted to start the server with 
 IBM's 1.3 or 1.3.1 VM for Linux, by any chance? I had trouble in this
 case.
 
 It appears that a 1.4-generated server barfs with IBM's 1.3.x VMs for 
 Linux. Do not ask me why...  ;-(
 
 Best,
 
 Francisco
 
 On Tue, 21 May 2002, Dain Sundstrom wrote:
 
 
I can't seem to get the server to start anymore.  I did a fresh checkout 
and rebuild.  When I start the server I get the following exception:

13:50:58,280 ERROR [Server] start failed
org.jboss.deployment.DeploymentException: Could not create deployment: 
file:/hom
e/dain/work/jboss/jboss-head/build/output/jboss-3.1.0alpha/server/default/conf/j
boss-service.xml; - nested throwable: (java.lang.NoSuchMethodError)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:698)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472)
 at java.lang.reflect.Method.invoke(Native Method)
 at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
 at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216)
 at org.jboss.Main.boot(Main.java:148)
 at org.jboss.Main$1.run(Main.java:381)
 at java.lang.Thread.run(Thread.java:484)
java.lang.NoSuchMethodError
 at 
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.getLast
Modified(URLDeploymentScanner.java:304)
 at 
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.deploye
d(URLDeploymentScanner.java:274)
 at 
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:375)
 at 
org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDe
ploymentScanner.java:555)
 at 
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:434)
 at 
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:237)
 at 
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
98)
 at java.lang.reflect.Method.invoke(Native Method)
 at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
 at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at 
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:867)
 at $Proxy0.start(Unknown Source)
 at 
org.jboss.system.ServiceController.start(ServiceController.java:339)
 at java.lang.reflect.Method.invoke(Native Method)
 at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
 at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
 at $Proxy3.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:341)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:686)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472)
 at java.lang.reflect.Method.invoke(Native Method)
 at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
 at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216)
 at org.jboss.Main.boot(Main.java:148)
 at org.jboss.Main$1.run(Main.java:381)
 at java.lang.Thread.run(Thread.java:484)

-dain


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


 
 
 ___
 
 Don't miss the 2002 Sprint PCS Application Developer's Conference
 August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 

Re: [JBoss-dev] NoSuchMethodError in MainDeployer

[Andreas Schaefer]

Hi

 Did you buid JBoss with JDK 1.4 and attempted to start the server with
 IBM's 1.3 or 1.3.1 VM for Linux, by any chance? I had trouble in this
 case.

 It appears that a 1.4-generated server barfs with IBM's 1.3.x VMs for
 Linux. Do not ask me why...  ;-(

I have the same problem with an irratic behaviour (it happens on different
files to be deploy on different runs) on W2K with JDK 1.3 (build clean
most).

Andy



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] NoSuchMethodError in MainDeployer

[Hunter Hillegas]

I'm seeing the same thing, building and running with 1.3.1/MacOSX.

 From: Francisco Reverbel [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 Date: Tue, 21 May 2002 17:22:02 -0300 (EST)
 To: JBoss-dev [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] NoSuchMethodError in MainDeployer
 
 Did you buid JBoss with JDK 1.4 and attempted to start the server with
 IBM's 1.3 or 1.3.1 VM for Linux, by any chance? I had trouble in this
 case.
 
 It appears that a 1.4-generated server barfs with IBM's 1.3.x VMs for
 Linux. Do not ask me why...  ;-(
 
 Best,
 
 Francisco
 
 On Tue, 21 May 2002, Dain Sundstrom wrote:
 
 I can't seem to get the server to start anymore.  I did a fresh checkout
 and rebuild.  When I start the server I get the following exception:
 
 13:50:58,280 ERROR [Server] start failed
 org.jboss.deployment.DeploymentException: Could not create deployment:
 file:/hom
 e/dain/work/jboss/jboss-head/build/output/jboss-3.1.0alpha/server/default/con
 f/j
 boss-service.xml; - nested throwable: (java.lang.NoSuchMethodError)
  at org.jboss.deployment.MainDeployer.start(MainDeployer.java:698)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472)
  at java.lang.reflect.Method.invoke(Native Method)
  at 
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
 nDispatcher.java:284)
  at 
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318)
  at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216)
  at org.jboss.Main.boot(Main.java:148)
  at org.jboss.Main$1.run(Main.java:381)
  at java.lang.Thread.run(Thread.java:484)
 java.lang.NoSuchMethodError
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.getLast
 Modified(URLDeploymentScanner.java:304)
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.deploye
 d(URLDeploymentScanner.java:274)
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
 tScanner.java:375)
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDe
 ploymentScanner.java:555)
  at 
 org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
 canner.java:434)
  at 
 org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
 bstractDeploymentScanner.java:237)
  at 
 org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
 98)
  at java.lang.reflect.Method.invoke(Native Method)
  at 
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
 nDispatcher.java:284)
  at 
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at 
 org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
 ler.java:867)
  at $Proxy0.start(Unknown Source)
  at 
 org.jboss.system.ServiceController.start(ServiceController.java:339)
  at java.lang.reflect.Method.invoke(Native Method)
  at 
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
 nDispatcher.java:284)
  at 
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
  at $Proxy3.start(Unknown Source)
  at org.jboss.deployment.SARDeployer.start(SARDeployer.java:341)
  at org.jboss.deployment.MainDeployer.start(MainDeployer.java:686)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489)
  at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472)
  at java.lang.reflect.Method.invoke(Native Method)
  at 
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
 nDispatcher.java:284)
  at 
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318)
  at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216)
  at org.jboss.Main.boot(Main.java:148)
  at org.jboss.Main$1.run(Main.java:381)
  at java.lang.Thread.run(Thread.java:484)
 
 -dain
 
 
 ___
 
 Don't miss the 2002 Sprint PCS Application Developer's Conference
 August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 ___
 
 Don't miss the 2002 Sprint PCS Application Developer's 

[JBoss-dev] [ jboss-Feature Requests-558869 ] Delay insert until after ejbPostCreate

[noreply]

Feature Requests item #558869, was opened at 2002-05-21 21:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376688aid=558869group_id=22866

Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Priority: 5
Submitted By: Tim Fox (timfox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Delay insert until after ejbPostCreate

Initial Comment:
jboss3.0rc3

I have two entity beans (CMP) with a one-many 
mapping between them - the relation is handled with 
CMR.

The child object has a foreign key column indentifying 
the parent id.

There is referential integrity enforce on the foreign key 
column (not null) in the database.

If I create a new instance of the child class in the 
database, then, since the cmr field representing the 
parent id is not set until the subsequent update query, 
the insert fails.

Net result is unable (or at least very difficult) to use 
CMR currently  in databases with referential integrity.

Since most serious databases will have referential 
integrity enforced this appears a very serious limitation.

Possible solution: to delay insert until after 
ejbPostCreate().

--

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

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] deploy error in scanner thread (cvs head)

[lsanders]

There is a bug in Sun's 1.3 jvm.  Inner classes can not access protected
members inherited from the outer class's super class:

A (defines protected field: log)
B extends A
+--  C (Inner class of B)

Trying to access log from C fails.  This is why all inner-classes of
MainDeployer called the public method getLog() instead of accessing log
directly.

-Larry

- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Justin Casp [EMAIL PROTECTED]
Sent: Monday, May 20, 2002 9:28 AM
Subject: Re: [JBoss-dev] deploy error in scanner thread (cvs head)


Chances are this is due to a problem accessing the Logger log field... when
did Sun decide not to support nested classes... this is getting ugly.

--jason


On Tuesday 21 May 2002 08:43 am, Justin Casp wrote:
 Hi List,
 I've just recently begun to see this error occur sporadically when
starting
 JBoss after being freshly built from the cvs head.  I was able to find a
 build on another machine that's a few days old, and it boots fine.
 However, when I deploy a user ear on this older build (very simple example
 from Wrox book) the same error occurs.  With the latest cvs code, this
 error happens when deploying internal Jboss packages (not sure of the
 terminology).  Since it occurs in the scanner thread, I can't
 undeploy/redeploy the test ear.  Any ideas on what may be causing this?
 I've tried doing a 'build.sh clean' then 'build.sh' but it still happens.
 Let me know if I can help in tracking this down.  I was doing this test
ear
 in order to report another bug, so now I have nested problems.
 Justin


 11:20:13,577 ERROR [MainDeployer] could not start deployment:

file:/home/casp/projects/jboss/jboss-all/build/output/jboss-3.1.0alpha/serv
er/default/deploy/localobjects.jar java.lang.NullPointerException
 at
 org.jboss.util.NestedThrowable$Util.getBoolean(NestedThrowable.java:108)
 at
org.jboss.util.NestedThrowable.clinit(NestedThrowable.java:39)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:120)
 at
 org.jboss.util.NestedThrowable$Util.class$(NestedThrowable.java:27) at
 org.jboss.util.NestedThrowable$Util.clinit(NestedThrowable.java:100)
 at org.jboss.util.NestedException.init(NestedException.java:50)
 at

org.jboss.deployment.DeploymentException.init(DeploymentException.java:44
) at

org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStartComman
d.java:190) at

org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartCommand.ja
va:84) at

org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java
:384) at

org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.jav
a:198) at
 org.jboss.ejb.EntityContainer.startService(EntityContainer.java:360)
 at
 org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198)
 at org.jboss.ejb.Container.invoke(Container.java:782)
 at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1024)
 at
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at

org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja
va:867) at $Proxy0.start(Unknown Source)
 at
 org.jboss.system.ServiceController.start(ServiceController.java:339)
 at java.lang.reflect.Method.invoke(Native Method)
 at

org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa
tcher.java:284) at
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
 at $Proxy19.start(Unknown Source)
 at org.jboss.ejb.EjbModule.startService(EjbModule.java:442)
 at
 org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198)
 at java.lang.reflect.Method.invoke(Native Method)
 at

org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa
tcher.java:284) at
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at

org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja
va:867) at $Proxy0.start(Unknown Source)
 at
 org.jboss.system.ServiceController.start(ServiceController.java:339)
 at java.lang.reflect.Method.invoke(Native Method)
 at

org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa
tcher.java:284) at
 org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
 at $Proxy5.start(Unknown Source)
 at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:391)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:693)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:528)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:490)
 at java.lang.reflect.Method.invoke(Native Method)
 

[JBoss-dev] flush=true

[Mahesh Agarwal]

Hi All

I am facing this error, can anyone please help me out solving this.

Thanks a  lot
Mahesh

org.apache.jasper.compiler.CompileException:
C:\JBoss-2.4.4_Tomcat-3.2.3\tomcat\webapps\zeborg\jsp\zeborg\buyer\MarketSum
mary.jsp(76,36) jsp:include needs to have flush=true
at
org.apache.jasper.compiler.IncludeGenerator.(IncludeGenerator.java:100)
at
org.apache.jasper.compiler.JspParseEventListener.handleInclude(JspParseEvent
Listener.java:875)
at
org.apache.jasper.compiler.DelegatingListener.handleInclude(DelegatingListen
er.java:185)
at org.apache.jasper.compiler.Parser$Include.accept(Parser.java:299)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1077)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1042)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1038)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:209)
at
org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:612)
at
org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:146)
at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:542)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspSe
rvlet.java:258)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:268)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
at org.apache.tomcat.core.Handler.service(Handler.java:287)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:81
2)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:758)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC
onnectionHandler.java:213)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)
at java.lang.Thread.run(Thread.java:479)

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] JBoss 3.1 startup problem

[Andreas Schaefer]

Hi Geeks

Just changed log. to getLog() and server. to
getServer() and now I can startup JBoss server
again.

BTW the same problem happens in most of the
TestCases !! 

Have fun

x
Andreas Schaefer
Senior Consultant
JBoss Group, LLC
x



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] deploy error in scanner thread (cvs head)

[Jason Dillon]

 There is a bug in Sun's 1.3 jvm.  Inner classes can not access protected
 members inherited from the outer class's super class:

I think it is ironic that Sun's vm does not support the language spec... 

Does anyone know if there is a bug filed on this?

--jason


 A (defines protected field: log)
 B extends A
 +--  C (Inner class of B)

 Trying to access log from C fails.  This is why all inner-classes of
 MainDeployer called the public method getLog() instead of accessing log
 directly.

 -Larry

 - Original Message -
 From: Jason Dillon [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]; Justin Casp
 [EMAIL PROTECTED] Sent: Monday, May 20, 2002 9:28 AM
 Subject: Re: [JBoss-dev] deploy error in scanner thread (cvs head)


 Chances are this is due to a problem accessing the Logger log field... when
 did Sun decide not to support nested classes... this is getting ugly.

 --jason

 On Tuesday 21 May 2002 08:43 am, Justin Casp wrote:
  Hi List,
  I've just recently begun to see this error occur sporadically when

 starting

  JBoss after being freshly built from the cvs head.  I was able to find a
  build on another machine that's a few days old, and it boots fine.
  However, when I deploy a user ear on this older build (very simple
  example from Wrox book) the same error occurs.  With the latest cvs code,
  this error happens when deploying internal Jboss packages (not sure of
  the terminology).  Since it occurs in the scanner thread, I can't
  undeploy/redeploy the test ear.  Any ideas on what may be causing this?
  I've tried doing a 'build.sh clean' then 'build.sh' but it still happens.
  Let me know if I can help in tracking this down.  I was doing this test

 ear

  in order to report another bug, so now I have nested problems.
  Justin
 
 
  11:20:13,577 ERROR [MainDeployer] could not start deployment:

 file:/home/casp/projects/jboss/jboss-all/build/output/jboss-3.1.0alpha/serv

 er/default/deploy/localobjects.jar java.lang.NullPointerException
  at
  org.jboss.util.NestedThrowable$Util.getBoolean(NestedThrowable.java:108)
  at

 org.jboss.util.NestedThrowable.clinit(NestedThrowable.java:39)

  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:120)
  at
  org.jboss.util.NestedThrowable$Util.class$(NestedThrowable.java:27) at
  org.jboss.util.NestedThrowable$Util.clinit(NestedThrowable.java:100)
  at org.jboss.util.NestedException.init(NestedException.java:50)
  at

 org.jboss.deployment.DeploymentException.init(DeploymentException.java:44

 ) at

 org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStartComman

 d.java:190) at

 org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartCommand.ja

 va:84) at

 org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java

 :384) at

 org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.jav

 a:198) at
  org.jboss.ejb.EntityContainer.startService(EntityContainer.java:360)
  at
  org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198)
  at org.jboss.ejb.Container.invoke(Container.java:782)
  at
  org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1024) at
  org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at

 org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja

 va:867) at $Proxy0.start(Unknown Source)
  at
  org.jboss.system.ServiceController.start(ServiceController.java:339)
  at java.lang.reflect.Method.invoke(Native Method)
  at

 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa

 tcher.java:284) at
  org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
  at $Proxy19.start(Unknown Source)
  at org.jboss.ejb.EjbModule.startService(EjbModule.java:442)
  at
  org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198)
  at java.lang.reflect.Method.invoke(Native Method)
  at

 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa

 tcher.java:284) at
  org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at

 org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja

 va:867) at $Proxy0.start(Unknown Source)
  at
  org.jboss.system.ServiceController.start(ServiceController.java:339)
  at java.lang.reflect.Method.invoke(Native Method)
  at

 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa

 tcher.java:284) at
  org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
  at $Proxy5.start(Unknown Source)
  at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:391)
  at 

[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work

[chris]

=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=

JAVA VERSION DETAILS
java version 1.3.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc))

=

HERE ARE THE LAST 50 LINES OF THE LOG FILE

Hello,

The org.jboss.Shutdown class does not seem to work.

That is, the jboss_redhat_init.sh script called it and the jboss 
server did not stop...

Please could we get this fixed...

Or tell me what I should be calling to get the server shutdown...

Now I will return to the old faithful method - kill -9

See ya,
Chris

PS This is automated - just to make it really annoying...

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] JavaSoft Bug 4401977

[Scott M Stark]

That particular bug is which is why it can't be exactly the issue we
are seeing. I don't see any open bugs relating to inner classes and
protected base class fields JDK1.4.

On Tuesday 21 May 2002 06:56 pm, Scott M Stark wrote:
 This bug seems the closest match to the problem we are seeing
 and has a reproducible testcase. The issue is claimed to be
 fixed in 1.4 and the testcase does run correctly with 1.4 so it
 can't be exactly the problem. In general there seem to be many
 bugs reported about inner classes accessing protected base class
 members or methods.
 http://developer.java.sun.com/developer/bugParade/bugs/4401977.html

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 


 ___

 Don't miss the 2002 Sprint PCS Application Developer's Conference
 August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development




___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] UILConnectionFactory

[paritosh Das]

Hi
We are using Jboss for our projects, we are 
using JbossMQ for sending and receiving messages, our front end is applet 
.
while using default connection factory which is 
basically using two way socket connection, we are unable to receive messages 
from the queue/topic but we can send/publish the message over the 
network
If we use UILconnectionFactory we are able to 
receive message over the network but we cann't close the connection by 
Connection.close() method it gives an error like

org.jboss.mq.SpyJMSException: Error 
whle closing UILClientIL connection
at 
org.jboss.mq.Connection.asynchFailure(Connection.java:412)
at 
org.jboss.mq.il.uil.UILClientILService.run(UILClientILService.java:216)
at java.lang.Thread.run(Unknown 
Source)

if any one has 
the solution,

Warm Regards,Paritosh DasEmail: [EMAIL PROTECTED]Home: 
09811160056

[JBoss-dev] [ jboss-Bugs-559012 ] Why no deploy error for service CNFE

[noreply]

Bugs item #559012, was opened at 2002-05-21 22:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=559012group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why no deploy error for service CNFE

Initial Comment:
If I deploy a service such as the following for which 
there is no my.company.MyService class available, 
the service successfull deploys. Why?

deploy 821cat bad-service.xml
?xml version=1.0 encoding=UTF-8?

server
  mbean code=my.company.MyService 
name=user:service=MyService
attribute 
name=MyAttributeAttributeValue/attribute
  /mbean
/server

2002-05-21 22:31:18,765 DEBUG 
[org.jboss.deployment.scanner.URLDeploymentSca
nner] Watch URL for: file:/D:/usr/JBoss3.0/jboss-
all/build/output/jboss-3.0.0RC4/server/log4j-
chap2/deploy/jmx-html-adaptor.sar - 
file:/D:/usr/JBoss3.0/jboss-all/build/output/jboss-
3.0.0RC4/server/log4j-chap2/deploy/jmx-html-
adaptor.sar
2002-05-21 22:31:18,765 INFO  
[org.jboss.deployment.MainDeployer] Starting 
deployment of package: file:/D:/usr/JBoss3.0/jboss-
all/build/output/jboss-3.0.0RC4/server/log4j-
chap2/deploy/bad-service.xml
2002-05-21 22:31:18,781 DEBUG 
[org.jboss.deployment.MainDeployer] Starting 
deployment (init step) of package at: 
file:/D:/usr/JBoss3.0/jboss-all/build/output/jboss-
3.0.0RC4/server/log4j-chap2/deploy/bad-
service.xml
2002-05-21 22:31:18,781 DEBUG 
[org.jboss.deployment.MainDeployer] using 
deployer 
org.jboss.deployment.SARDeployer@78a212
2002-05-21 22:31:18,796 DEBUG 
[org.jboss.deployment.SARDeployer] about to copy 
0 local directories
2002-05-21 22:31:18,796 DEBUG 
[org.jboss.deployment.MainDeployer] found 0 
subpackages of file:/D:/usr/JBoss3.0/jboss-
all/build/output/jboss-3.0.0RC4/server/log4j-
chap2/deploy/bad-service.xml
2002-05-21 22:31:18,796 DEBUG 
[org.jboss.deployment.MainDeployer] Watching 
new file: file:/D:/usr/JBoss3.0/jboss-
all/build/output/jboss-3.0.0RC4/server/log4j-
chap2/deploy/bad-service.xml
2002-05-21 22:31:18,796 DEBUG 
[org.jboss.deployment.MainDeployer] create step 
for deployment file:/D:/usr/JBoss3.0/jboss-
all/build/output/jboss-3.0.0RC4/server/log4j-
chap2/deploy/bad-service.xml
2002-05-21 22:31:18,796 DEBUG 
[org.jboss.deployment.SARDeployer] Deploying 
SAR, create step: url file:/D:/usr/JBoss3.0/jboss-
all/build/output/jboss-3.0.0RC4/server/log4j-
chap2/deploy/bad-service.xml
2002-05-21 22:31:18,796 DEBUG 
[org.jboss.system.ServiceCreator] About to create 
bean: user:service=MyService
2002-05-21 22:31:18,796 DEBUG 
[org.jboss.system.ServiceCreator] code: 
my.company.MyService
2002-05-21 22:31:18,890 DEBUG 
[org.jboss.system.ServiceCreator] Class not found 
for mbean: user:service=MyService
2002-05-21 22:31:18,890 DEBUG 
[org.jboss.deployment.MainDeployer] Done with 
create step of deploying bad-service.xml
2002-05-21 22:31:18,890 DEBUG 
[org.jboss.deployment.MainDeployer] start step for 
deployment file:/D:/usr/JBoss3.0/jboss-
all/build/output/jboss-3.0.0RC4/server/log4j-
chap2/deploy/bad-service.xml
2002-05-21 22:31:18,890 DEBUG 
[org.jboss.deployment.SARDeployer] Deploying 
SAR, start step: url file:/D:/usr/JBoss3.0/jboss-
all/build/output/jboss-3.0.0RC4/server/log4j-
chap2/deploy/bad-service.xml
2002-05-21 22:31:18,890 DEBUG 
[org.jboss.deployment.MainDeployer] Final (start) 
deployment step successfully completed on 
package: bad-service.xml
2002-05-21 22:31:18,890 INFO  
[org.jboss.deployment.MainDeployer] Successfully 
completed deployment of package: 
file:/D:/usr/JBoss3.0/jboss-all/build/output/jboss-
3.0.0RC4/server/log4j-chap2/deploy/bad-
service.xml


--

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

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-559018 ] CMR table column name wrong

[noreply]

Bugs item #559018, was opened at 2002-05-22 05:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=559018group_id=22866

Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Vincent Zhao (vincentzhao)
Assigned to: Nobody/Anonymous (nobody)
Summary: CMR table column name wrong

Initial Comment:
In your cmp-example, the jbosscmp-jdbc.xml file, it 
reads:ejb-relationship-role
ejb-relationship-role-namelineitem-belongsto-
order/ejb-relationship-role-name
foreign-key-fields
foreign-key-field
field-nameordernumber/field-name
column-nameORDER_NUMBER/column-name
/foreign-key-field
/foreign-key-fields
It seems in the LINE_ITEM table, it should has a 
column named ORDER_NUMBER, but in fact it is 
named order.

--

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

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] log4j.jar appender loading

[Scott M Stark]

Inclusion of log4j.jar in the ServerLoader bootclasspath breaks
loading of unbundled classes used by appenders such as the JavaMail
classes since the DOMConfigurator used Class.forName to load appenders,
etc. Either the class loader created by the ServerLoader needs to be a
custom
subclass that dynamcically integrates with the UCL loader repository when
available, or we need to subclass org.apache.log4j.xml.DOMConfigurator and
override the parseXXX methods to use the TCL.

log4j: Attaching appender named [ErrorNotifications] to appender named
[ASYNCH].
log4j: Class name: [org.apache.log4j.net.SMTPAppender]
java.lang.NoClassDefFoundError: javax/mail/Multipart
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:115)
at
org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:159)
at
org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator
.java:144)
at
org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:196)
at
org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator
.java:144)
at
org.apache.log4j.xml.DOMConfigurator.parseChildrenOfCategoryElement(DOMConfi
gurator.java:361)
at
org.apache.log4j.xml.DOMConfigurator.parseRoot(DOMConfigurator.java:330)
at
org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:693)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:593)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:545)
at
org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.java:615)
at
org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.ja
va:488)
at
org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.jav
a:437)
at java.util.TimerThread.mainLoop(Timer.java:430)
at java.util.TimerThread.run(Timer.java:380)


Scott Stark
Chief Technology Officer
JBoss Group, LLC



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Should JMS ConnectionFactory be serializable?

[Scott M Stark]

I think there is agreement that is should be serializable and there already
a bug
on this so it just needs to be done.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 20, 2002 6:19 PM
Subject: [JBoss-dev] Should JMS ConnectionFactory be serializable?


I have brought this up before, but now I am hurting from it... I spoke with
David a little on this, but that is all it has been was talk.

I am using the JMS RA to obtain a QueueConnectionFactory, then use it to
construct the other JMS bits (QueueConnection, QueueSession).  The problem
that I have is that I pass that factory to some component which needs to
serialize it (plus some other state) to recover from a system failure.
Under
the current 3.0 branch this fails with:

java.io.NotSerializableException:
org.jboss.resource.connectionmanager.CachedConnectionManager

I think that I will run into a few problems trying to use that RA outside of
an EJB scope, so I will have to reimplement this in a different manner...
but
I think this problem might hit me again when and if one of my session beans
which uses the JMS RA passivates.

My understanding of the EJB spec leaves me to believe that the container
does
not need to perform any special attention to a resource maanger factory.  At
one point I looked up the text from the spec and posted it to the forums...
but I can't seem to find it now... and I am too busy to go and find it
again.
Forum search is no good...

Anyways, the other point is that this is a manged object and in concept
should
have all of the information it needs to create new connections.  Based on
that I would think it should be serializable.

So I don't know what is supposed to happen... the EJB spec reads like it
should be serializable, though the JMS interfaces are not marked as
serializable... but the connection manager stuff from the JCA are...

Anyone have a clue what is the right thing todo here?

BTW, do we have passivation/activation tests to check that the right thing
is
done with other JCA related stuff?

--jason

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-559024 ] Converting EJB-ql to SQL goes wrong

[noreply]

Bugs item #559024, was opened at 2002-05-22 06:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=559024group_id=22866

Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Henk Laracker (hlaracker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Converting EJB-ql to SQL goes wrong 

Initial Comment:
I'am using version 3.0 RC3
jdk 1.4,windows 2000 

The ejb statement is :
select object(o) from TaskDB as o where 
(o.relWaDB.relCodesDB.code = ?1 or 
o.relWaDB.code = ?1)

the sql statement generated by jboss is :

SELECT t0_o.syscode 
FROM TASK t0_o
, WA t2_o_relWaDB
, CODES t1_o_relWaDB_relCodesDB 
WHERE t1_o_relWaDB_relCodesDB.code = ?
OR t2_o_relWaDB.code = ?
AND ( t0_o.wa_syscode=t2_o_relWaDB.syscode 
AND t2_o_relWaDB.project_syscode= 
t1_o_relWaDB_relCodesDB.syscode)

The braces in the ejb-ql statement are not present in 
the sql statement. This results in a different result then 
expected. What do i have to do the get the braces in 
the sql statement?

--

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

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development