Re[6]: [JBoss-dev] URLConnection and opened files

2003-01-15 Thread Scott M Stark
Somehow the URL handlers cache has the sun file protocol handler from the start,
at least as early as a debugger will let me stop in the URL.getURLStreamHandler
method. You need to flush this handler cache by setting a URLStreamHandlerFactory.
The change to make your example work is to install a factory that always returns
null:

Tests 1371cat tstProtocol.java
import java.io.*;
import java.net.*;

class tstProtocol
{
   static class NullFactory implements java.net.URLStreamHandlerFactory
   {
  public URLStreamHandler createURLStreamHandler(final String protocol)
  {
 return null;
  }
   }

public static void main(String[] args) throws Exception
{
   // set handler pkgs
   System.out.println(java.protocol.handler.pkgs:  + System.getProperty(java.
protocol.handler.pkgs));

   // Flush the handlers cache by setting a noop factory
   URL.setURLStreamHandlerFactory(new NullFactory());

   URL url = new URL(file, null, args[0]);
   System.out.println(url:  + url);
   URLConnection urlCon = url.openConnection();
   System.out.println(connection class:  + urlCon.getClass().getName());

   url = new URL(other, null, args[0]);
   System.out.println(url:  + url);
   urlCon = url.openConnection();
   System.out.println(connection class:  + urlCon.getClass().getName());
}
}

Tests 1369java -cp .;/tmp/JBoss/jboss-3.0.5/client/jboss-common-client.jar
-Djava.protocol.handler.pkgs=org.jboss.net.protocol tstProtocol /tmp
java.protocol.handler.pkgs: org.jboss.net.protocol
url: file:/tmp
connection class: org.jboss.net.protocol.file.FileURLConnection
java.net.MalformedURLException: unknown protocol: other
at java.net.URL.init(URL.java:302)
at java.net.URL.init(URL.java:219)
at java.net.URL.init(URL.java:238)
at tstProtocol.main(tstProtocol.java:27)


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: Alex Loubyansky [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]
Sent: Tuesday, January 14, 2003 9:48 PM
Subject: Re[6]: [JBoss-dev] URLConnection and opened files


 Yes, I thought about it too. There are two cases:
 - the thread creating URL can't find custom handlers;
 - Sun's handler was somehow initialized/used before (before setting the
 property or somehow else?)
 
 But I can't understand why my standalone test doesn't work. I set
 property in the command line and my handlers are in the classpath.
 I don't see any chance for Sun's handler to be used first.
 
 Ok, I'll update JBoss-3.0 and see.
 
 Thanks,
 alex



---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



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

2003-01-15 Thread Jules Gosnell
Would you try the latest 3.2 package

As far as Jetty is concerned the only difference between Jboss-3.0 and 
3.2 is that 3.0 contains Jasper1 and 3.2 contains Jasper2.

If Jasper1 is broken, and Jasper2 works OK, then I will probably upgrade 
 Jasper on jboss-3.2.

Jules


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

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Bannister (beoch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Jasper in release 3.0.5 is 

Initial Comment:
Windows 2000 
JDK 1.4.1_01
JBoss 3.0.5

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

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

The exception thrown is:


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


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

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

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


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

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


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

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

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

[JBoss-dev] Question for statistic number about JBoss

2003-01-15 Thread EXCELSIS - Guenter Eppler
Hello

I am doing some research about open source software and I am interested in
some statistic figures on JBoss.
Hopefully somebody can help me and send me back some of the following
numbers or give me some information where I can find this.

- project team size
  - coders
  - voters
  - commiters
- is there a chief architect (or chief architect group) ?
- the total lines of code in the JBoss project(number)
- number of JBoss installations worldwide
- the average release interval
- site of the mailing list
  - developer
  - announcements

I say thank you to all the people which will provide som information.

Best Regards

Guenter Eppler
[EMAIL PROTECTED]




---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure

2003-01-15 Thread SourceForge.net
Bugs item #667341, was opened at 2003-01-13 19:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Pending
Resolution: None
Priority: 5
Submitted By: Peter Luttrell (objec)
Assigned to: Jules Gosnell (jules_gosnell)
Summary: Initial Session AUTH failure

Initial Comment:
JBoss3.0.5 - release with jdk1.4.1_01
Before this I was using JBoss3.0.5RC1 and this problem 
did NOT occur.

After I startup JBoss or redeploy my ear, which contains 
a war which uses authentication (my login module), the 
very first session that attempts to authenticate fails. If i 
try it again in the same browser window it still fails.

If i open a new window (new sesison id), it works.

This happens every time i deploy. I have tried opening a 
new browser after i deploy but the problem still happens.

This is a problem introduced between JBoss3.0.5-RC1 
and 3.0.5-Release.

--

Comment By: Jules Gosnell (jules_gosnell)
Date: 2003-01-15 10:22

Message:
Logged In: YES 
user_id=49106

The fix is in (Branch_3_0 and 3_2) - please confirm
resolution so I can close this.

Jules


--

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

Message:
Logged In: YES 
user_id=175228

Edit jbossweb.sar/webdefault.xml and set the 
redirectWelcome init-param of the default servlet to true to
have welcome pages secured.
See bug 621521 for the details of what is going on.

--

Comment By: Peter Luttrell (objec)
Date: 2003-01-15 02:25

Message:
Logged In: YES 
user_id=472835

Based on gregs comments, it sounds like this is
reproduceable via much simplier means then my case.

My case:

i am hitting my webapp by 

http://myserver/mycontext/

based on my deployment descriptor 
welcome-file-list
welcome-fileindex.html/welcome-file
/welcome-file-list
jetty should take me to
http://myserver/mycontext/index.html, which is this:

html
head
titleMy Company Name/title
meta http-equiv=refresh content=0;URL=index.jsp
 /head
 body
/body
/html

So somewhere there's a problem. 

I'm doing this rerouting becase i've secured index.jsp and i
can't make this the welcome page because Jetty does not
check security on this page. I would prefer that it did,
however i believe that this is an unspeced part of the spec.
I don't know any other way to do this: I need to log in
directly from the page that results from hitting the context
directly.

--

Comment By: Greg Wilkins (gregwilkins)
Date: 2003-01-14 20:56

Message:
Logged In: YES 
user_id=44062

A simple test case would be to have a servlet that looks at
getPathInfo to see if a path param is included in it.

I had thought it would effect all requests - but in
retesting it only appears to be effecting connections via
mod_jk and AJP13

I'll do some extra tests and see if I can come up with a
normal HTTP test case.


--

Comment By: Scott M Stark (starksm)
Date: 2003-01-14 19:17

Message:
Logged In: YES 
user_id=175228

I have created a servlet that creates a session and that is 
secured and returns a page with a URL to itself with URL that 
is encoded to enable URL rewriting. I don't have a problem 
accessing this servlet on the first attempt when there is no 
session, or on any subsequent attempt. I have disabled 
cookies in my browser so I know the URL rewriting is taking 
place. In the absence of a testcase that demonstrates the 
problem I can't judge whether this problem warrents a new 
3.0.6 release.


--

Comment By: Greg Wilkins (gregwilkins)
Date: 2003-01-14 09:53

Message:
Logged In: YES 
user_id=44062

This issue is not so much security related, but URL
processing of
path parameters like ;jsessionid.

If you are writing your webapp correctly, you will be
rewriting your URLs.   If the server has not seen a cookie
from the client it will insert such a path parameter.  

The problem is that path parameters are only being correctly
decoded on the first request of a persistent connection. 
For all other requests, they are being seen as part of the
URL rather than as something extra.  

Thus my own test harnesses for this past without a problem
as they 
were the first request on a connection.

Webapps that do not rewrite URLs (many) or who have apps
that create a session before authetication takes place -
will probably not be effective.  So it's not totally broken
- just significantly so.

I'm done a fixed release of Jetty (4.2.5) and Jules is lined
up to make a replacement jbossweb.sar 





--

Comment By: 

[JBoss-dev] [ jboss-Bugs-647839 ] JSP Issue

2003-01-15 Thread SourceForge.net
Bugs item #647839, was opened at 2002-12-03 14:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=647839group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Pending
Resolution: None
Priority: 5
Submitted By: Sloan Seaman (sseaman)
Assigned to: Jules Gosnell (jules_gosnell)
Summary: JSP Issue

Initial Comment:
OS: Win 2K Pro
JDK: 1.3.1-b24
No trace dumped to screen.

Issue:
I have a custom tag like so:
render:render 
template=../../../global/comment/commentShow.jsp
render:put key=BGCOLOR value=%=bgColors
[bgColorIdx]%/
render:put key=COMMENT value=%=comment%
/
render:put key=REPLY_LINK 
value=/leaguecentral/lc/schedule/comment/commentRe
ply.jsp?eventId=%=eventId%parentId=%
=comment.getCommentId()%/
/render:render

The %=% does not seem to get replaced for my 
REPLY_LINK variable. All of the others seem to work 
fine.

It seems to occur any time I have text in my value= 
tag before the %=%
i.e. this would also not work:
value=blah blah blah %=test%

--

Comment By: Jules Gosnell (jules_gosnell)
Date: 2003-01-15 10:28

Message:
Logged In: YES 
user_id=49106

This looks liks a Jasper (3rd party) problem.

Please confirm whether it also exists in the JBoss/Tomcat
bundle.

If it does, it is a Jasper problem and should be addressed
to that project.

If it isn't, it is most likely due to Jetty using a bad
Jasper version, or some inadequacy in the integration - in
which case we will look at it.

Jules


--

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


---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



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

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

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

Initial Comment:
Windows 2000 
JDK 1.4.1_01
JBoss 3.0.5

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

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

The exception thrown is:


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


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

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

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


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

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


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

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

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

[JBoss-dev] [ jboss-Bugs-654332 ] jsp:plugin name=x value=%=val%

2003-01-15 Thread SourceForge.net
Bugs item #654332, was opened at 2002-12-16 03:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=654332group_id=22866

Category: CatalinaBundle
Group: v4.0
Status: Open
Resolution: None
Priority: 5
Submitted By: jeff dickenson (dickensonj)
Assigned to: Nobody/Anonymous (nobody)
Summary: jsp:plugin name=x value=%=val%

Initial Comment:
OS = Win2000
JDK Version 1.4.1
JBoss 3.0.4 with Tomcat 4.1.12

Issue: JSP calling java class 

The code generated for the following jsp:params block 
inside a jsp:plugin element:

   jsp:params
 jsp:param name=scp value=%= scp % /
 jsp:param name=demoMode value=%= 
demoMode % /
 jsp:param name=wsdlURL value=%= wsdlURL 
% /
 jsp:param name=wsProxy value=%= wsProxy 
% /
   /jsp:params

does not use the *value* of the four variables but instead 
has 'value= scp', i.e. the *name* of the variable without 
double quotes.

--

Comment By: Jules Gosnell (jules_gosnell)
Date: 2003-01-15 10:24

Message:
Logged In: YES 
user_id=49106

This is a Tomcat, not a Jetty/JBossWeb issue. 

--

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


---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-644287 ] in a Filter, getServletPath() empty

2003-01-15 Thread SourceForge.net
Bugs item #644287, was opened at 2002-11-26 19:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=644287group_id=22866

Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Pending
Resolution: None
Priority: 5
Submitted By: James Manning (jmm)
Assigned to: Jules Gosnell (jules_gosnell)
Summary: in a Filter, getServletPath() empty

Initial Comment:
using the servlet 2.3 API, in a defined filter (extends
HttpServlet implements Filter),  inside method public
void doFilter(ServletRequest request, ServletResponse
response, FilterChain filterChain)

HttpServletRequest httpServletRequest =
(HttpServletRequest)request;
String current_file = httpServletRequest.getServletPath();

This works great under Tomcat 4.x but returns an empty
string (not null, just empty) in jboss 3.0.4

Trying to put together the minimal webapp to show the
bug now.  Wanted to go ahead and get the bug posted
just in case it's known or something

--

Comment By: Jules Gosnell (jules_gosnell)
Date: 2003-01-15 10:29

Message:
Logged In: YES 
user_id=49106

Greg is asking for clarification from the RFC

--

Comment By: Greg Wilkins (gregwilkins)
Date: 2003-01-04 14:01

Message:
Logged In: YES 
user_id=44062


Your filter is mapped to /* and you have no servlets.  

The servlet spec says for getServletPath:

The path section that directly corresponds to the mapping
which activated this request. This path starts with a / 
character except in the case where the request is matched
with the  /*  pattern, in which case it is the empty string.

So I think we are correct to return the empty string.



--

Comment By: Greg Wilkins (gregwilkins)
Date: 2003-01-04 13:40

Message:
Logged In: YES 
user_id=44062

Can you attach the source code of your example please.


--

Comment By: James Manning (jmm)
Date: 2002-11-26 21:09

Message:
Logged In: YES 
user_id=11485

in case it helps, adding another check for getRequestURI shows:

(under Tomcat 4.x)

10095 [HttpProcessor[8000][3]] INFO TestFilter  - ***
getServletPath gives /foo/bar/ack
10095 [HttpProcessor[8000][3]] INFO TestFilter  - ***
getRequestURI gives /filter/foo/bar/ack

under jboss 3.0.4

16:09:28,870 INFO  [TestFilter] *** getServletPath gives
16:09:28,870 INFO  [TestFilter] *** getRequestURI gives
/filter/foo/bar/ack

Both are being hit by IE with a url of
http://127.0.0.1:8080/filter/foo/bar/ack
(port number changed to point to each one)

--

Comment By: James Manning (jmm)
Date: 2002-11-26 20:13

Message:
Logged In: YES 
user_id=11485

on Tomcat 4.x

0 [HttpProcessor[8000][3]] INFO TestFilter  - ***
getServletPath gives /foo/bar/ack

So this appears (afaict) to be a jboss breakage

--

Comment By: James Manning (jmm)
Date: 2002-11-26 20:02

Message:
Logged In: YES 
user_id=11485

this is the minimal test-case AFAICT.  logging shows:

15:02:14,709 INFO  [TestFilter] *** getServletPath gives

--

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


---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] JBossMQ

2003-01-15 Thread Hiram Chirino

that sounds right..

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of John
 Fawcett
 Sent: Tuesday, January 14, 2003 8:14 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] JBossMQ
 
 
 Hi,
 
 I want to make sure I understand the asynchronous delivery mechanism.
 I've implemented my MessageConsumer to do the following:
 
 Add self to Connection's message consumer list
 While(consumer is open){
   while(server is delivering synchronously){
   Send Receive Requests until the Server is Drained
   }
   Wait for Asynch Delivery
 }
 
 
 Is this the proper pattern?
 Thanks,
 fawce
 
 
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]] On Behalf Of
 Hiram Chirino
 Sent: Friday, January 10, 2003 6:50 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] JBossMQ
 
 
 
 Your kinda right.  the loop is there for the case where the destination
 is queue based (p2p and durable subs).  The polling happens when the
 queue is full.  Now when the queue is not full (or in the pub sub case,
 there is no queue), then the thread goes into asynch mode and it waits
 for the message to get delivered async via the ClientIL.receive method.
 I'll comment the code a little:
 
// gets the next message in queue or registers us for asynch
 delivery if none available.
mes = session.connection.receive( subscription, 0 );
if ( mes == null ) // should always be null for pub-sub case.
{
   // start waiting for the message to get delivered asynch
   waitingForMessage = true;
   while ( ( messages.isEmpty()  !closed ) || (
 !session.running ) )
   {
  try
  {
 // messages gets signaled once ClientIL.receive finishes
 processing the message.
 messages.wait();
  } catch ( InterruptedException e )
  {
  }
   }
   if ( closed )
   {
  waitingForMessage = false;
  break outer;
   }
   // the message sent via ClientIL.receive should now be sitting
 in messages
   mes = ( SpyMessage )messages.removeFirst();
   waitingForMessage = false;
   }
 
 
 I hope that helped!  I think the XIL is great idea!  We might even be
 able to develop a c base API to access mq services (important in the
 integration space).
 
 Regards,
 Hiram
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of 
  John Fawcett
  Sent: Thursday, January 09, 2003 8:09 PM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] JBossMQ
 
 
  Hi,
 
  I am working on a new invocation layer (IL) for JbossMQ that encodes 
  all communication in Xml (XIL). I've got the IL pretty near 
  completion, and I am working on a C# jbossmq client.  I am trying to 
  develop the TopicSubsciber, which is an extension of MessageConsumer. 
  In reviewing the code in the jbossmq java sources, it looks to me like
 
  the client to a topic actually runs a loop sending receive requests to
 
  the server regularly.
 
  Is this really necessary? Once the connection has been established, 
  why can't the server just invoke the ClientIL.receive method (which 
  actually sends the message to the client) when a message arrives at 
  the destination? It looks to me like the current implementation is not
 
  truly asynchronous...
  What am I missing?
 
  Thanks,
  fawce
 
 
  -
  John Fawcett
  CTO, Tamale Software, LLC
  26 Fox Road
  Waltham, MA 02451
 
 
 
  ---
  This SF.NET email is sponsored by:
  SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! 
  http://www.vasoftware.com 
  ___
  Jboss-development mailing list [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 ---
 This SF.NET email is sponsored by:
 SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
 http://www.vasoftware.com
 ___
 Jboss-development mailing list [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 ---
 This SF.NET email is sponsored by: Take your first step towards giving 
 your online business a competitive advantage. Test-drive a Thawte SSL 
 certificate - our easy online guide will show you how. Click here to get 
 started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.NET email is sponsored by: Take your first step towards giving 
your online 

Re[6]: [JBoss-dev] URLConnection and opened files

2003-01-15 Thread Alex Loubyansky
Here are my findings.

First, JBoss-3.0 is ok. The problem is in JBoss-3.2 and HEAD.

Second, I found the cause.
The resources we want to load with our custom handlers
through class loaders must be added to the classpath AFTER the
(custom) URLStreamHandlerFactory is setup.

URLClassLoaders hold their URLs.
The URLs created before the custom URLStreamHandlerFactory is set up
have Sun's handler. System class loader is a subclass of the
URLClassLoader. Thus, its URLs have Sun's handler. (It seems to me even
if java.protocol.handler.pkgs is setup. Is it a VM's bug or mine?)

Suppose we attempt to load resource that was in the classpath before
the custom handler factory was setup. The URL for the resource is
constructed with: URL(URL context, String spec).
where the context URL comes from the class loader with Sun's handler.
Then resource's URL's handler is assigned context.handler.
So, it doesn't matter whether the custom handler factory is setup.

alex

Tuesday, January 14, 2003, 9:49:45 PM, you wrote:

SMS Oh, I now remeber looking at this but I can't remember the context. There
SMS is a cache of handlers as the URL level. If the file protocol is referenced
SMS before the custom JBoss handler is available then the default Sun one will
SMS be used. Is there a difference between 3.0 and 3.2 with regard to when the
SMS custom protocol handlers are installed? I'll check later today.


SMS 
SMS Scott Stark
SMS Chief Technology Officer
SMS JBoss Group, LLC
SMS 

SMS - Original Message - 
SMS From: Alex Loubyansky [EMAIL PROTECTED]
SMS To: Scott M Stark [EMAIL PROTECTED]
SMS Sent: Tuesday, January 14, 2003 7:07 AM
SMS Subject: Re[4]: [JBoss-dev] URLConnection and opened files


 I'm a bit confused. I wrote a simple standalone test.
 
 - main
 public static void main(String[] args) throws Exception
 {
// set handler pkgs
System.out.println(java.protocol.handler.pkgs:  + 
System.getProperty(java.protocol.handler.pkgs));
 
URL url = new URL(file, null, args[0]);
System.out.println(url:  + url);
URLConnection urlCon = url.openConnection();
System.out.println(connection class:  + urlCon.getClass().getName());
 
url = new URL(other, null, args[0]);
System.out.println(url:  + url);
urlCon = url.openConnection();
System.out.println(connection class:  + urlCon.getClass().getName());
 }
 
 - run
 java -Djava.protocol.handler.pkgs=org.avoka.test.files.protocol -classpath %cp% 
org.avoka.test.files.FilesTest build.xml
 
 - output
 java.protocol.handler.pkgs: org.avoka.test.files.protocol
 url: file:build.xml
 connection class: sun.net.www.protocol.file.FileURLConnection
 url: other:build.xml
 connection class: org.avoka.test.files.protocol.other.OtherURLConnection
 
 I do have org.avoka.test.files.protocol.file.Handler and
 org.avoka.test.files.protocol.file.FileURLConnection on the classpath.
 My file.Handler isn't called. Am I missing something?
 
 This same thing happens with JBoss-3.2 and HEAD but not JBoss-3.0 (my
 3.0 is not up to date).
 
 JDK1.3.1_05, J2SDK1.4.0
 Win2K
 
 Thanks,
 alex




---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Fw: [jboss-cvs] jboss-common/src/main/org/jboss/net/protocol/resource ResourceURLConnection.java

2003-01-15 Thread Alex Loubyansky
JBoss-3.2 doesn't have
   +  String urlStr = target.toString();
   +  target = new URL(urlStr);

But just adding this doesn't help me.

BTW, is java.protocol.handler.pkgs setup after the SCL is created?
As I see it is, but how is it supposed to be? I would expect vice
versa.

alex

Wednesday, January 15, 2003, 2:17:48 AM, you wrote:

SMS Here is the context in which I looked into the JBoss file protocol handler not 
being used.
SMS As far as I remember, the issue was that very early on there are file URLs being
SMS created and these were picking up the default file protocol handler. Recreating 
the
SMS URL after the URLStreamHandlerFactory was installed resulted in the JBoss file
SMS protocol handler being used.

SMS 
SMS Scott Stark
SMS Chief Technology Officer
SMS JBoss Group, LLC
SMS 

SMS - Original Message - 
SMS From: Scott M Stark [EMAIL PROTECTED]
SMS To: [EMAIL PROTECTED]
SMS Sent: Sunday, September 29, 2002 12:05 PM
SMS Subject: [jboss-cvs] jboss-common/src/main/org/jboss/net/protocol/resource 
ResourceURLConnection.java


   User: starksm 
   Date: 02/09/29 13:05:18
 
   Modified:src/main/org/jboss/net/protocol/resource Tag: Branch_3_0
 ResourceURLConnection.java
   Log:
   Recreate the URL obtained from the class loader as the file URLs are not
   using the org.jboss.net.protocol.file handler for some reason. Creating a
   new URL from the CL URL string does use our URLStreamHandlerFactory. This
   fixes a problem with the log4j.xml file changes not being seen due to
   the invalid lastModified of the default sun file protocol handler.
   
   Revision  ChangesPath
   No   revision
   
   
   No   revision
   
   
   1.2.2.2   +17 -5 
jboss-common/src/main/org/jboss/net/protocol/resource/ResourceURLConnection.java
   
   Index: ResourceURLConnection.java
   ===
   RCS file: 
/cvsroot/jboss/jboss-common/src/main/org/jboss/net/protocol/resource/ResourceURLConnection.java,v
   retrieving revision 1.2.2.1
   retrieving revision 1.2.2.2
   diff -u -r1.2.2.1 -r1.2.2.2
   --- ResourceURLConnection.java 17 May 2002 22:25:41 - 1.2.2.1
   +++ ResourceURLConnection.java 29 Sep 2002 20:05:18 - 1.2.2.2
   @@ -22,7 +22,7 @@
/**
 * Provides access to system resources as a URLConnection.
 *
   - * @version tt$Revision: 1.2.2.1 $/tt
   + * @version tt$Revision: 1.2.2.2 $/tt
 * @author  a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
 */
public class ResourceURLConnection
   @@ -50,7 +50,8 @@
  ClassLoader cl = Thread.currentThread().getContextClassLoader();
  URL target = cl.getResource(name);

   -  if (target == null) {
   +  if (target == null)
   +  {
 cl = ClassLoader.getSystemClassLoader();
 target = cl.getResource(name);
  }
   @@ -58,12 +59,23 @@
  if (target == null)
 throw new FileNotFoundException(Could not locate resource:  + name);

   -  if (log.isTraceEnabled()) {
   +  /* The file URLs being returned by the class loaders are not using the
   + org.jboss.net.protocol.file handler for some reason so here we
   + recreate the url to make sure it goes through our
   + URLStreamHandlerFactory. The cause should be tracked down but this
   + works for now.
   +  */
   +  String urlStr = target.toString();
   +  target = new URL(urlStr);
   +  if (log.isTraceEnabled())
   +  {
 log.trace(Target resource URL:  + target);
   - try {
   + try
   + {
log.trace(Target resource URL connection:  + 
target.openConnection());
 }
   - catch (Exception ignore) {}
   + catch (Exception ignore)
   + {}
  }
  
  return target;




---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] JNuke dev

2003-01-15 Thread David Jencks
I tried to do something like this about a year ago but it didn't work 
with the then-current xdoclet.   I think it will be pretty easy with 
current xdoclet.

Marc wanted to do this with ejbs, just drop bean class in, xdoclet 
generates interfaces, dd, etc, and we deploy.

JRun did/does something like this.

david jencks
On Tuesday, January 14, 2003, at 02:16 PM, Dain Sundstrom wrote:

Bill,

This reminds me of an I deal I has last night (couldn't sleep).  I was 
thinking of the script based MBean support Sacha added, and I thought 
can we make plain old java work like a scripting language.  Here is 
what I came up with:
  + The user writes a class BlahService.java
  + This source file is places in our deployment directory
  + We run Xdoclet on it to generate the MBean deployment descriptor
  + We compile the java file
  + Deploy

Java as a scripting language.

What do you think?

-dain

On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote:

The only negative comment I have in using JMX is that the PHP 
community may
have a tough time switching over to Nukes on JBoss if you have to 
have a
package structure like a SAR or a WAR.  I hate to say it, but does it 
need
to be dumbed-down for the PHP community?  This type of community 
needs to
be able to edit a JSP and immediately see the change on the 
webserver.  Is
it possible to be all JSP based for themes, modules and blocks?  You 
could
use a URL fragement and JSP:Include to decide what theme to use.

Just a thought.  Maybe JMX and such is the way to go.  Just want to 
give you
something to think about.

Bill

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
julien viet
Sent: Tuesday, January 14, 2003 11:31 AM
To: SourceForge.net
Subject: [JBoss-dev] JNuke dev


hi folks,

 JNuke adventure has started.
After analysis of PostNuke I've began the development, still early 
though.

 I keep everything that's good in PostNuke and throw all the shit 
away :

 modules, blocks, permissions system, url system and themes.

 JMX is used for PostNuke components : themes,
modules and blocks are all JMX mbeans. Here are my reasons :

 A : general

 1.we need a component structure, why not JMX ? after all
   another forum say that's lightweight.

 2.theses components do not have to scale, i.e the number of modules,
   blocks and themes is very small.

 B : for modules

 1.Ability to deploy/undeploy when application is running.

 2.It's easy to deploy additional modules as a separate deployment 
and
   have them register in the same registry.

 3.PostNuke is all about invoking module functions.
   Url like index.php?module=Userop=register means
   that the PN must call the method register on module User.
   For me that means that the servlet retrieves the mbean
   under the name jnuke:publicmodules:name=User
   and invokes the operation register().

 4.When a module is installed and configured it plug
   block mbeans in the JMX.

 C : for blocks, same reasons as above except 3 and 4
 as invocation is typed for 3.

 D : for themes, same reasons as above except 3 and 4
 as invocation is typed for 3.


 EJB are used for the model :

 UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will
be CMP 2.0 beans. We'll use local invocations and same trick
as in forum to make them faster. Plus more beans.

 Each module is made of :

 1.ModuleMBean : is the module itself, does not provide 
fucntionnalities,
  it's used to manager the PublicModule. Main operations are 
lifecycle
  (initialize, activate, unactivate, uninitialize)

 2.PublicModuleMBean : is created when ModuleMBean activates and is
   responsible for serving requests. The MBean is dynamic and 
operations
   with no arguments and no returns are served.

  It's up to the module to do as he wants : if he wants MVC it can, 
it
  it wants to mix HTML and code, it can. First modules won't be MVC
  as they simply don't need.

  It's up to the model to have the persistence mecanisms it wants. 
First
  modules will use EJB. With lifecycle operations, each module can 
install
  itself, for instance :

  a ModuleMBean is plugged :
  1.module configuration, setup of variables
  2.initialize : module can creates table, deploy EJB, plugs block.
  3.activate : module
  then go to block admin and creates instances of blocks (if module
  use blocks), display them on the page.

 Each block is made of :

 1.BlockMBean : manages BlockInstanceMBean.
 2.BlockInstanceMBean : is a block instance, it contains a title
and a position
   on web page + 3 operations : display(), edit(), update().
   display() : displays the block instance
   edit() : used to edit the block in block administration
   update() : used to upate the block in block admin

 Each them is made of various callbacks that displays HTML on the 
page.
 It has to provide location of files like css, gifs, etc...
 THe first them I did is made of a servlet that register to JMX
 and the doGet operation serves the files. It's 

[JBoss-dev] [ jboss-Bugs-668533 ] ejbql / 3.0.5 - error in generated sql for MSSQL 2000

2003-01-15 Thread SourceForge.net
Bugs item #668533, was opened at 2003-01-15 16:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668533group_id=22866

Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Halil-C. Gürsoy (che---)
Assigned to: Nobody/Anonymous (nobody)
Summary: ejbql / 3.0.5 - error in generated sql for MSSQL 2000

Initial Comment:
Hi Folks,

i have the following finder defined for my CMP entity:

 query
query-method
   method-namefindByRoot/method-name
   method-params
   /method-params
/query-method
ejb-ql![CDATA[SELECT OBJECT(o) FROM
Geschaeftsfeld o WHERE o.parentGF IS NULL AND
o.ebene=0]]/ejb-ql
 /query

parentGF is a cmr field (see added file):
  ejb-relation 

ejb-relation-nameGeschaeftsfeld-Children/ejb-relation-name
 !-- bidirectional --
 ejb-relationship-role 
   
ejb-relationship-role-nameGF-Parent-has-Children/ejb-relationship-role-name
multiplicityOne/multiplicity
relationship-role-source 
   ejb-nameGeschaeftsfeld/ejb-name
/relationship-role-source
cmr-field 
   cmr-field-namegFChildren/cmr-field-name
  
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
 /ejb-relationship-role
 ejb-relationship-role 
   
ejb-relationship-role-nameChild-of-Parent-GF/ejb-relationship-role-name
multiplicityMany/multiplicity
relationship-role-source 
   ejb-nameGeschaeftsfeld/ejb-name
/relationship-role-source
cmr-field 
   cmr-field-nameparentGF/cmr-field-name
/cmr-field
 /ejb-relationship-role
  /ejb-relation

With the 3.0.5 release i observerved that the finder
doesn't function anymore, in contrast to 3.0.4. The
following sql statements are generated.

During deployment i found this:

2003-01-15 15:52:16,904 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Geschaeftsfeld.findByRoot]
EJB-QL: SELECT OBJECT(o) FROM Geschaeftsfeld o WHERE
o.parentGF IS NULL AND o.ebene=0

2003-01-15 15:52:16,914 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Geschaeftsfeld.findByRoot]
SQL: SELECT t0_o.geschaeftsfeld_id FROM
geschaeftsfelder t0_o WHERE (t0_o.uebergeordnete_id IS
NULL AND t0_o.ebene = 0) AND
(t0_o.uebergeordnete_id=t0_o.geschaeftsfeld_id)

As you can see, there is a additional join in the
second bracket which causes the error and that is not
defined in the finder.

And then i access this finder:

15:41:37,356 DEBUG [findByRoot] Executing SQL: SELECT
t0_o.geschaeftsfeld_id FROM geschaeftsfelder t0_o WHERE
(t0_o.uebergeordnete_id IS NULL AND t0_o.ebene = 0
) AND (t0_o.uebergeordnete_id=t0_o.geschaeftsfeld_id)


In 3.0.4, for the same ear, the following sql-statement
is executed:

16:23:42,204 DEBUG [findByRoot] Executing SQL: SELECT
t0_o.geschaeftsfeld_id FROM geschaeftsfelder t0_o WHERE
t0_o.uebergeordnete_id IS NULL AND t0_o.ebene = 0

Maybe this is because this fix i have read in the
readme for 3.0.5?
-
module: src/main/org/jboss/ejb/plugins/cmp/jdbc
; files: 
JDBCEJBQLCompiler.java

comments:
fixed bug with one-to-one and IS [NOT] NULL on a CMR
field that is not a foreign key
-

Running all on
- Win2k prof. SP2
- JB 3.0.5 / Tomcat 4.1.18
- JDK 1.4.1-b21


--

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


---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-665037 ] HomeHandle causing NoInitialContextException in JBOSS3.0.4

2003-01-15 Thread SourceForge.net
Bugs item #665037, was opened at 2003-01-09 16:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=665037group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Shone Sadler (ssadler)
Assigned to: Scott M Stark (starksm)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4

Initial Comment:
When running our remote clients we get a 
NoInitialContextException.  The exception is caused by 
a call to HomeHandle.getEJBHome().  After Looking 
through the source code for JBOSS, it seems that 
JBOSS 3.0.4's 
com.jboss.proxy.ejb.handle.HomeHandleImpl does not 
serialize the JNDI context information like is should (and 
used to in JBOSS2.4.  Instead it always creates a new 
InitialContext in the getEJBHome method.  The following 
example illustrates the problem.

import 
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;


import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;

public class Example {
   public static void main(String[] args) throws Exception 
{
 Properties _prop = new Properties();
  _prop.setProperty
(java.naming.factory.initial,org.jnp.interfaces.NamingC
ontextFactory);
  _prop.setProperty
(java.naming.factory.url.pkgs,org.jboss.naming:org.jnp.
interfaces);
  _prop.setProperty
(java.naming.provider.url,localhost);
  _prop.setProperty
(java.naming.provider.port,1099);

  InitialContext _ic = new InitialContext(_prop);
  POFObjectManagerRemoteHome _om_home = 
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
(qlink/POFObjectManager),POFObjectManagerRemote
Home.class);

  HomeHandle _hhandle = _om_home.getHomeHandle
();
  //Here is where the NoInitialContextException is 
thrown
  _om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
   }
}


Thanks,

Shone Sadler
Senior Software Developer
Q-Link Technologies



OS: Win2000
JDK:1.3.1_06

Server Trace:

C:\developmentjava Example
Exception in thread main java.rmi.ServerException: 
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to 
specify class name in e
vironment or system property, or as an applet 
parameter, or in an application r
source file:  java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify 
class name in environme
t or system property, or as an applet parameter, or in an 
application resource
ile:  java.naming.factory.initial
at 
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at 
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at 
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)




--

Comment By: Oskari Kettunen (aok)
Date: 2003-01-15 18:06

Message:
Logged In: YES 
user_id=558871

Forgot to mention:

I was actually getting XYZ not bound from 
StatelessHandleImpl, because the new InitialContext().lookup
(jndiName) caught onto the client side JNDI, not the one 
discovered with specific properties. Same problem, obviously.

Oskari Kettunen,
Krocus Communications,
Finland


--

Comment By: Oskari Kettunen (aok)
Date: 2003-01-15 17:58

Message:
Logged In: YES 
user_id=558871

I've run into this also, and would like to add a sidenote:

When using HA-JNDI discoverServer broadcast, the jndi 
properties are not sufficient information for accurately 
determining the location of the EJB. Having just any server 
with a similar bean respond when invoking 
Handle.getEJBObject(), as transparent as it may be, doesn't 
seem like 'robust' persistent reference to an EJB object as 
the J2EE javadoc suggests.

I intended to submit this bug along with a patch as soon as I 
got time for fixing it, but as work is already underway, this is 
purely additional FYI.

Oskari Kettunen,
Krocus Communications,
Finland


--

Comment By: Scott M Stark (starksm)
Date: 2003-01-12 23:42

Message:
Logged In: YES 
user_id=175228

Yes, that is a silly regression in 3.x. You have to restore the 
handle in a context with a jndi.properties file that matches 
that in which the handle was looked up. It will be addressed 
in the 3.0.6 and 3.2 releases.

--

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



[JBoss-dev] sub-deployments

2003-01-15 Thread MNewcomb
I have a WAR file with an applet.  The applet requires some old classes that
conflict with those required by JSPs/Servlets in the WAR file.  The classes
for the applet are in a jar file, applet_only_classes.jar.  When I deploy my
WAR, JBoss creates a UCL for this jar file, even though it is only intended
to be 'served', not used by the server.  Every now and then I get
ClassFormatErrors and Linkage problems inside JBoss because when the server
code goes looking for classes, it finds these old classes instead of the
correct ones.

WAR:
- applet_only_classes.jar
- *.html
- *.jsp
- WEB-INF/web.xml
- WEB-INF/lib/server_classes.jar

Shouldn't only stuff in WEB-INF be subject to sub-deployment?  That would
solve my problem because applet_only_classes.jar would not be found and
therefore would hose up the server.

Basic problem is, SubDeployerSupport.init() tries to deploy everything in a
'deployable item' through SubDeployerSupport.processNestedDeployments().

What happens if you want to have a web site that serves up your old
application releases as jar files?

We could override isDeployable in AbstractWebContainer and do a
super.isDeployable()  'WEB-INF' is in the given url.

Is there someway around this that I'm missing?

Thanks,
Michael


---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Question for statistic number about JBoss

2003-01-15 Thread Bill Burke
Most of your stats can be found at sourceforge.

http://sourceforge.net/projects/jboss/

More comments follow

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of
 EXCELSIS - Guenter Eppler
 Sent: Wednesday, January 15, 2003 5:13 AM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] Question for statistic number about JBoss


 Hello

 I am doing some research about open source software and I am interested in
 some statistic figures on JBoss.
 Hopefully somebody can help me and send me back some of the following
 numbers or give me some information where I can find this.

 - project team size
   - coders
   - voters
   - commiters

72 developers worldwide.

 - is there a chief architect (or chief architect group) ?

There is a services company, JBoss Group, that provides
consulting/training/support.  We are the caretakers of the project.

See http://www.jboss.org/team.jsp  and
http://www.jboss.org/developers/projects/jboss/projects.jsp for more
information on leadership.

 - the total lines of code in the JBoss project(number)

We have over 20 projects covering all of J2EE, AOP, WebServices, IDE
integration and such.  All source code zipped up is over 20megs.  Let's do
the math.

100 bytes per line

20,000,000 bytes / 100 = 200,000 lines of code.

 - number of JBoss installations worldwide

2.4 million downloads since 1999.

 - the average release interval

Bi-monthly

 - site of the mailing list
   - developer
   - announcements


www.jboss.org



Bill Burke
Chief Architect
JBoss Group, LLC




---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Transaction propagation change

2003-01-15 Thread Barlow, Dustin
The fix of putting the transaction context in the transient_payload, as
apposed to the as_is_payload.  A while back I got Tyrex to somewhat work in
the 3.2 series, but the only way I could get passed the NonSerializable
exception was to change the code in org.jboss.invocation.Invocation.java to
put the transaction context in the transient_payload.  I was not very
comfortable with this change being that I wasn't sure what the overall
transaction integrity implications where for making the patch.  I just
followed the directions I found here
http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg21152.html
and it got me past the error.

Having a distributed transaction context is especially important for example
when you have a EJB from one jboss instance posting a message to a JMS queue
on another jboss instance that in turn has a MDB that calls another EJB on
that second instance.  If I want that all to be under one transaction and
thus rollback as one business unit of work, there is no way to do that (that
i'm aware of) with native JBoss in the 3.x series.  I know one could use
Tyrex, but the author doesn't recommend using Tyrex in a production
environment and so I'm a little leary to use it myself.

Plus the other fix that Scott described where RequiresNew is honored.  Also,
it would be useful to not propogate the transaction context to the receiver
node if the caller is not apart of a container transaction (with a
transaction semantic of NEVER in the ejb-jar.xml).

Dustin

 -Original Message-
 From: David Jencks [mailto:[EMAIL PROTECTED]]
 Sent: Monday, January 13, 2003 9:37 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Transaction propagation change
 
 
 
 On Monday, January 13, 2003, at 08:58 AM, Barlow, Dustin wrote:
 
  Will this fix also be back ported to the 3.x series as 
 well?  This is 
  a huge
  issue for those of us who are or plan to use more then one 
 jboss node 
  in our
  applications.
 
 Which fix?  Not propagating anything is easy to port.  Enabling 
 distributed transactions is a lot of work that is not all 
 done and may 
 not be easy to backport.  I certainly don't want to try with 3.0, I 
 might consider 3.2.
 
 david jencks
  Dustin
 
  -Original Message-
  From: Scott M Stark [mailto:[EMAIL PROTECTED]]
  Sent: Sunday, January 12, 2003 4:19 AM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] Transaction propagation change
 
 
  Regarding bug: [ 663114 ] MarshallException when accessing
  remote bean, this is
  due to a change made to store the transaction context of an
  Invocation in the as_is_payload
  rather than the transient_payload map about the time of the
  3.0.0 release. Our tx
  info never has been serializable, and the marshalled form of
  the tpc is handled at the
  MarshalledInvocation layer anyway rather than relying on the
  correct form of the tx
  context being placed into the Invocation.
 
  In the case of this particular bug, an EJB A on host 1 calls
  an EJB B on host 2. Both
  EJBs uses REQUIRED transaction attributes for all methods, so
  according to the
  EJB spec this call should actually fail since the expectation
  a client can assume is that
  the existing transaction context of EJB A will be propagated.
  However, we fail all calls
  regardless of the transaction attributes. If EJB B was using
  RequiresNew the call should
  succeed.
 
  I'm inclined to move the transaction context into the
  transient_payload map to allow
  valid calls to succeed. This does raise the possibility that
  the application data can become
  corrupted if it does expected distributed transaction
  semantics on inter-server EJB calls.
 
  We need to cleanup the tx propagation so that its consistent
  with the spec. Both for
  the case of not supporting tx propagation and the case of
  supporting it. Is this being
  included in the 4.0 changes concerning the distributed
  transaction support?
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
 
  ---
  This SF.NET email is sponsored by:
  SourceForge Enterprise Edition + IBM + LinuxWorld = 
 Something 2 See!
  http://www.vasoftware.com
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 
 
  ---
  This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
  are you planning your Web Server Security? Click here to get a FREE
  Thawte SSL guide and find the answers to all your  SSL 
 security issues.
  http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 ---
 This SF.NET 

[JBoss-dev] [ jboss-Bugs-668533 ] ejbql / 3.0.5 - error in generated sql for MSSQL 2000

2003-01-15 Thread SourceForge.net
Bugs item #668533, was opened at 2003-01-15 16:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668533group_id=22866

Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Halil-C. Gürsoy (che---)
Assigned to: Nobody/Anonymous (nobody)
Summary: ejbql / 3.0.5 - error in generated sql for MSSQL 2000

Initial Comment:
Hi Folks,

i have the following finder defined for my CMP entity:

 query
query-method
   method-namefindByRoot/method-name
   method-params
   /method-params
/query-method
ejb-ql![CDATA[SELECT OBJECT(o) FROM
Geschaeftsfeld o WHERE o.parentGF IS NULL AND
o.ebene=0]]/ejb-ql
 /query

parentGF is a cmr field (see added file):
  ejb-relation 

ejb-relation-nameGeschaeftsfeld-Children/ejb-relation-name
 !-- bidirectional --
 ejb-relationship-role 
   
ejb-relationship-role-nameGF-Parent-has-Children/ejb-relationship-role-name
multiplicityOne/multiplicity
relationship-role-source 
   ejb-nameGeschaeftsfeld/ejb-name
/relationship-role-source
cmr-field 
   cmr-field-namegFChildren/cmr-field-name
  
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
 /ejb-relationship-role
 ejb-relationship-role 
   
ejb-relationship-role-nameChild-of-Parent-GF/ejb-relationship-role-name
multiplicityMany/multiplicity
relationship-role-source 
   ejb-nameGeschaeftsfeld/ejb-name
/relationship-role-source
cmr-field 
   cmr-field-nameparentGF/cmr-field-name
/cmr-field
 /ejb-relationship-role
  /ejb-relation

With the 3.0.5 release i observerved that the finder
doesn't function anymore, in contrast to 3.0.4. The
following sql statements are generated.

During deployment i found this:

2003-01-15 15:52:16,904 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Geschaeftsfeld.findByRoot]
EJB-QL: SELECT OBJECT(o) FROM Geschaeftsfeld o WHERE
o.parentGF IS NULL AND o.ebene=0

2003-01-15 15:52:16,914 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Geschaeftsfeld.findByRoot]
SQL: SELECT t0_o.geschaeftsfeld_id FROM
geschaeftsfelder t0_o WHERE (t0_o.uebergeordnete_id IS
NULL AND t0_o.ebene = 0) AND
(t0_o.uebergeordnete_id=t0_o.geschaeftsfeld_id)

As you can see, there is a additional join in the
second bracket which causes the error and that is not
defined in the finder.

And then i access this finder:

15:41:37,356 DEBUG [findByRoot] Executing SQL: SELECT
t0_o.geschaeftsfeld_id FROM geschaeftsfelder t0_o WHERE
(t0_o.uebergeordnete_id IS NULL AND t0_o.ebene = 0
) AND (t0_o.uebergeordnete_id=t0_o.geschaeftsfeld_id)


In 3.0.4, for the same ear, the following sql-statement
is executed:

16:23:42,204 DEBUG [findByRoot] Executing SQL: SELECT
t0_o.geschaeftsfeld_id FROM geschaeftsfelder t0_o WHERE
t0_o.uebergeordnete_id IS NULL AND t0_o.ebene = 0

Maybe this is because this fix i have read in the
readme for 3.0.5?
-
module: src/main/org/jboss/ejb/plugins/cmp/jdbc
; files: 
JDBCEJBQLCompiler.java

comments:
fixed bug with one-to-one and IS [NOT] NULL on a CMR
field that is not a foreign key
-

Running all on
- Win2k prof. SP2
- JB 3.0.5 / Tomcat 4.1.18
- JDK 1.4.1-b21


--

Comment By: Stefan Kuehnel (skuehnel)
Date: 2003-01-15 16:51

Message:
Logged In: YES 
user_id=596644

I was just to file a similar bug report. So I just add that I have similar problems 
under Linux with a MySQL database.  Can provide the exact EJB QL and SQL statements if 
necessary.

--

Comment By: Halil-C. Gürsoy (che---)
Date: 2003-01-15 16:50

Message:
Logged In: YES 
user_id=455149

I should mention that geschaeftsfeld_id is the pk of the
entity, which is found in the wrong statement.




--

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


---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-665037 ] HomeHandle causing NoInitialContextException in JBOSS3.0.4

2003-01-15 Thread SourceForge.net
Bugs item #665037, was opened at 2003-01-09 16:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=665037group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Shone Sadler (ssadler)
Assigned to: Scott M Stark (starksm)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4

Initial Comment:
When running our remote clients we get a 
NoInitialContextException.  The exception is caused by 
a call to HomeHandle.getEJBHome().  After Looking 
through the source code for JBOSS, it seems that 
JBOSS 3.0.4's 
com.jboss.proxy.ejb.handle.HomeHandleImpl does not 
serialize the JNDI context information like is should (and 
used to in JBOSS2.4.  Instead it always creates a new 
InitialContext in the getEJBHome method.  The following 
example illustrates the problem.

import 
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;


import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;

public class Example {
   public static void main(String[] args) throws Exception 
{
 Properties _prop = new Properties();
  _prop.setProperty
(java.naming.factory.initial,org.jnp.interfaces.NamingC
ontextFactory);
  _prop.setProperty
(java.naming.factory.url.pkgs,org.jboss.naming:org.jnp.
interfaces);
  _prop.setProperty
(java.naming.provider.url,localhost);
  _prop.setProperty
(java.naming.provider.port,1099);

  InitialContext _ic = new InitialContext(_prop);
  POFObjectManagerRemoteHome _om_home = 
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
(qlink/POFObjectManager),POFObjectManagerRemote
Home.class);

  HomeHandle _hhandle = _om_home.getHomeHandle
();
  //Here is where the NoInitialContextException is 
thrown
  _om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
   }
}


Thanks,

Shone Sadler
Senior Software Developer
Q-Link Technologies



OS: Win2000
JDK:1.3.1_06

Server Trace:

C:\developmentjava Example
Exception in thread main java.rmi.ServerException: 
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to 
specify class name in e
vironment or system property, or as an applet 
parameter, or in an application r
source file:  java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify 
class name in environme
t or system property, or as an applet parameter, or in an 
application resource
ile:  java.naming.factory.initial
at 
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at 
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at 
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)




--

Comment By: Oskari Kettunen (aok)
Date: 2003-01-15 17:58

Message:
Logged In: YES 
user_id=558871

I've run into this also, and would like to add a sidenote:

When using HA-JNDI discoverServer broadcast, the jndi 
properties are not sufficient information for accurately 
determining the location of the EJB. Having just any server 
with a similar bean respond when invoking 
Handle.getEJBObject(), as transparent as it may be, doesn't 
seem like 'robust' persistent reference to an EJB object as 
the J2EE javadoc suggests.

I intended to submit this bug along with a patch as soon as I 
got time for fixing it, but as work is already underway, this is 
purely additional FYI.

Oskari Kettunen,
Krocus Communications,
Finland


--

Comment By: Scott M Stark (starksm)
Date: 2003-01-12 23:42

Message:
Logged In: YES 
user_id=175228

Yes, that is a silly regression in 3.x. You have to restore the 
handle in a context with a jndi.properties file that matches 
that in which the handle was looked up. It will be addressed 
in the 3.0.6 and 3.2 releases.

--

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


---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668533 ] ejbql / 3.0.5 - error in generated sql for MSSQL 2000

2003-01-15 Thread SourceForge.net
Bugs item #668533, was opened at 2003-01-15 16:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668533group_id=22866

Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Halil-C. Gürsoy (che---)
Assigned to: Nobody/Anonymous (nobody)
Summary: ejbql / 3.0.5 - error in generated sql for MSSQL 2000

Initial Comment:
Hi Folks,

i have the following finder defined for my CMP entity:

 query
query-method
   method-namefindByRoot/method-name
   method-params
   /method-params
/query-method
ejb-ql![CDATA[SELECT OBJECT(o) FROM
Geschaeftsfeld o WHERE o.parentGF IS NULL AND
o.ebene=0]]/ejb-ql
 /query

parentGF is a cmr field (see added file):
  ejb-relation 

ejb-relation-nameGeschaeftsfeld-Children/ejb-relation-name
 !-- bidirectional --
 ejb-relationship-role 
   
ejb-relationship-role-nameGF-Parent-has-Children/ejb-relationship-role-name
multiplicityOne/multiplicity
relationship-role-source 
   ejb-nameGeschaeftsfeld/ejb-name
/relationship-role-source
cmr-field 
   cmr-field-namegFChildren/cmr-field-name
  
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
 /ejb-relationship-role
 ejb-relationship-role 
   
ejb-relationship-role-nameChild-of-Parent-GF/ejb-relationship-role-name
multiplicityMany/multiplicity
relationship-role-source 
   ejb-nameGeschaeftsfeld/ejb-name
/relationship-role-source
cmr-field 
   cmr-field-nameparentGF/cmr-field-name
/cmr-field
 /ejb-relationship-role
  /ejb-relation

With the 3.0.5 release i observerved that the finder
doesn't function anymore, in contrast to 3.0.4. The
following sql statements are generated.

During deployment i found this:

2003-01-15 15:52:16,904 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Geschaeftsfeld.findByRoot]
EJB-QL: SELECT OBJECT(o) FROM Geschaeftsfeld o WHERE
o.parentGF IS NULL AND o.ebene=0

2003-01-15 15:52:16,914 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Geschaeftsfeld.findByRoot]
SQL: SELECT t0_o.geschaeftsfeld_id FROM
geschaeftsfelder t0_o WHERE (t0_o.uebergeordnete_id IS
NULL AND t0_o.ebene = 0) AND
(t0_o.uebergeordnete_id=t0_o.geschaeftsfeld_id)

As you can see, there is a additional join in the
second bracket which causes the error and that is not
defined in the finder.

And then i access this finder:

15:41:37,356 DEBUG [findByRoot] Executing SQL: SELECT
t0_o.geschaeftsfeld_id FROM geschaeftsfelder t0_o WHERE
(t0_o.uebergeordnete_id IS NULL AND t0_o.ebene = 0
) AND (t0_o.uebergeordnete_id=t0_o.geschaeftsfeld_id)


In 3.0.4, for the same ear, the following sql-statement
is executed:

16:23:42,204 DEBUG [findByRoot] Executing SQL: SELECT
t0_o.geschaeftsfeld_id FROM geschaeftsfelder t0_o WHERE
t0_o.uebergeordnete_id IS NULL AND t0_o.ebene = 0

Maybe this is because this fix i have read in the
readme for 3.0.5?
-
module: src/main/org/jboss/ejb/plugins/cmp/jdbc
; files: 
JDBCEJBQLCompiler.java

comments:
fixed bug with one-to-one and IS [NOT] NULL on a CMR
field that is not a foreign key
-

Running all on
- Win2k prof. SP2
- JB 3.0.5 / Tomcat 4.1.18
- JDK 1.4.1-b21


--

Comment By: Halil-C. Gürsoy (che---)
Date: 2003-01-15 16:50

Message:
Logged In: YES 
user_id=455149

I should mention that geschaeftsfeld_id is the pk of the
entity, which is found in the wrong statement.




--

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


---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: Re[2]: [JBoss-dev] JNuke dev

2003-01-15 Thread Alex Loubyansky
I meant specifying them in XDoclet style, not XML.

/**
 * @classAttr
 */
class MyClass {

 /**
  * @fieldAttr
  */
 private int myField;

 /**
  * @methodAttr
  */
 public void myMethod() {

BTW, could you please exmplain what is the purpose of the 'name' attribute
in class-metadata element?
In the forum or here.

Thanks,
alex


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On
 Behalf Of Bill Burke
 Sent: Wednesday, January 15, 2003 4:23 PM
 To: [EMAIL PROTECTED]
 Subject: RE: Re[2]: [JBoss-dev] JNuke dev


 Yes definately Alex.  I've incorporated the idea of class/method/field
 metadata in the AOP framework I've been working on.  Please
 refer to the AOP
 forum.

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On
 Behalf Of Alex
  Loubyansky
  Sent: Wednesday, January 15, 2003 1:01 AM
  To: Dain Sundstrom
  Subject: Re[2]: [JBoss-dev] JNuke dev
 
 
  I also thought about support class/method/field level metadata
  attributes for aspects deploying the source file this way.
  But this could be a limiting solution for aspects development.
 
  alex
 
  Tuesday, January 14, 2003, 9:16:20 PM, you wrote:
 
  DS Bill,
 
  DS This reminds me of an I deal I has last night (couldn't
  sleep).  I was
  DS thinking of the script based MBean support Sacha added,
 and I thought
  DS can we make plain old java work like a scripting
 language.  Here is
  DS what I came up with:
  DS+ The user writes a class BlahService.java
  DS+ This source file is places in our deployment directory
  DS+ We run Xdoclet on it to generate the MBean
 deployment descriptor
  DS+ We compile the java file
  DS+ Deploy
 
  DS Java as a scripting language.
 
  DS What do you think?
 
  DS -dain



---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-665037 ] HomeHandle causing NoInitialContextException in JBOSS3.0.4

2003-01-15 Thread SourceForge.net
Bugs item #665037, was opened at 2003-01-09 06:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=665037group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Shone Sadler (ssadler)
Assigned to: Scott M Stark (starksm)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4

Initial Comment:
When running our remote clients we get a 
NoInitialContextException.  The exception is caused by 
a call to HomeHandle.getEJBHome().  After Looking 
through the source code for JBOSS, it seems that 
JBOSS 3.0.4's 
com.jboss.proxy.ejb.handle.HomeHandleImpl does not 
serialize the JNDI context information like is should (and 
used to in JBOSS2.4.  Instead it always creates a new 
InitialContext in the getEJBHome method.  The following 
example illustrates the problem.

import 
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;


import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;

public class Example {
   public static void main(String[] args) throws Exception 
{
 Properties _prop = new Properties();
  _prop.setProperty
(java.naming.factory.initial,org.jnp.interfaces.NamingC
ontextFactory);
  _prop.setProperty
(java.naming.factory.url.pkgs,org.jboss.naming:org.jnp.
interfaces);
  _prop.setProperty
(java.naming.provider.url,localhost);
  _prop.setProperty
(java.naming.provider.port,1099);

  InitialContext _ic = new InitialContext(_prop);
  POFObjectManagerRemoteHome _om_home = 
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
(qlink/POFObjectManager),POFObjectManagerRemote
Home.class);

  HomeHandle _hhandle = _om_home.getHomeHandle
();
  //Here is where the NoInitialContextException is 
thrown
  _om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
   }
}


Thanks,

Shone Sadler
Senior Software Developer
Q-Link Technologies



OS: Win2000
JDK:1.3.1_06

Server Trace:

C:\developmentjava Example
Exception in thread main java.rmi.ServerException: 
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to 
specify class name in e
vironment or system property, or as an applet 
parameter, or in an application r
source file:  java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify 
class name in environme
t or system property, or as an applet parameter, or in an 
application resource
ile:  java.naming.factory.initial
at 
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at 
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at 
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)




--

Comment By: Scott M Stark (starksm)
Date: 2003-01-15 09:27

Message:
Logged In: YES 
user_id=175228

Well, how robust would it be to fix to the node in the cluster 
that previously handled the create only to find that node no 
longer exists?

--

Comment By: Oskari Kettunen (aok)
Date: 2003-01-15 08:06

Message:
Logged In: YES 
user_id=558871

Forgot to mention:

I was actually getting XYZ not bound from 
StatelessHandleImpl, because the new InitialContext().lookup
(jndiName) caught onto the client side JNDI, not the one 
discovered with specific properties. Same problem, obviously.

Oskari Kettunen,
Krocus Communications,
Finland


--

Comment By: Oskari Kettunen (aok)
Date: 2003-01-15 07:58

Message:
Logged In: YES 
user_id=558871

I've run into this also, and would like to add a sidenote:

When using HA-JNDI discoverServer broadcast, the jndi 
properties are not sufficient information for accurately 
determining the location of the EJB. Having just any server 
with a similar bean respond when invoking 
Handle.getEJBObject(), as transparent as it may be, doesn't 
seem like 'robust' persistent reference to an EJB object as 
the J2EE javadoc suggests.

I intended to submit this bug along with a patch as soon as I 
got time for fixing it, but as work is already underway, this is 
purely additional FYI.

Oskari Kettunen,
Krocus Communications,
Finland


--

Comment By: Scott M Stark (starksm)
Date: 2003-01-12 13:42

Message:
Logged In: YES 
user_id=175228

Yes, that is a silly regression in 3.x. You have to restore the 
handle in a context with a jndi.properties file that matches 

Re[2]: JBossScript was RE: [JBoss-dev] JNuke dev

2003-01-15 Thread Danilo Luiz Rheinheimer
Hi,

Tuesday, January 14, 2003, 6:19:23 PM, you wrote:
ws And what would be the goal for that?
ws Could you give examples?

  I have another idea scripts use inside JBoss.
  The discussion here is to deploy scripts and then a deployer will converted
they to MBean/Session beans and so on.
  My idea is to have a script engine inside JBoss to be used by
clients.

  This is what I want to do :

  - a simple MBean with a method show()
  - inside this method the BeanShell console is called
  - this will popup a console on the screen where the user can type and
  execute scripts.

  This can be used to test beans and so on. It runs inside JBoss.
  
  I have a very simple prototype of this, and I will make it avaliable
tomorrow.
  What is the apropriate forum to discuss this ?

  Comments ?

-- 
Best regards,
 Danilomailto:[EMAIL PROTECTED]




---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: Re[2]: [JBoss-dev] JNuke dev

2003-01-15 Thread Bill Burke
This may or may not disappear.  The thought is to name the whole metadata
block for purposes of redeployment or undeployment.  Am I making sense?

Bill

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Alex
 Loubyansky
 Sent: Wednesday, January 15, 2003 10:56 AM
 To: [EMAIL PROTECTED]
 Subject: RE: Re[2]: [JBoss-dev] JNuke dev


 I meant specifying them in XDoclet style, not XML.

 /**
  * @classAttr
  */
 class MyClass {

  /**
   * @fieldAttr
   */
  private int myField;

  /**
   * @methodAttr
   */
  public void myMethod() {

 BTW, could you please exmplain what is the purpose of the 'name' attribute
 in class-metadata element?
 In the forum or here.

 Thanks,
 alex


  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On
  Behalf Of Bill Burke
  Sent: Wednesday, January 15, 2003 4:23 PM
  To: [EMAIL PROTECTED]
  Subject: RE: Re[2]: [JBoss-dev] JNuke dev
 
 
  Yes definately Alex.  I've incorporated the idea of class/method/field
  metadata in the AOP framework I've been working on.  Please
  refer to the AOP
  forum.
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On
  Behalf Of Alex
   Loubyansky
   Sent: Wednesday, January 15, 2003 1:01 AM
   To: Dain Sundstrom
   Subject: Re[2]: [JBoss-dev] JNuke dev
  
  
   I also thought about support class/method/field level metadata
   attributes for aspects deploying the source file this way.
   But this could be a limiting solution for aspects development.
  
   alex
  
   Tuesday, January 14, 2003, 9:16:20 PM, you wrote:
  
   DS Bill,
  
   DS This reminds me of an I deal I has last night (couldn't
   sleep).  I was
   DS thinking of the script based MBean support Sacha added,
  and I thought
   DS can we make plain old java work like a scripting
  language.  Here is
   DS what I came up with:
   DS+ The user writes a class BlahService.java
   DS+ This source file is places in our deployment directory
   DS+ We run Xdoclet on it to generate the MBean
  deployment descriptor
   DS+ We compile the java file
   DS+ Deploy
  
   DS Java as a scripting language.
  
   DS What do you think?
  
   DS -dain



 ---
 This SF.NET email is sponsored by: Take your first step towards giving
 your online business a competitive advantage. Test-drive a Thawte SSL
 certificate - our easy online guide will show you how. Click here to get
 started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-665037 ] HomeHandle causing NoInitialContextException in JBOSS3.0.4

2003-01-15 Thread SourceForge.net
Bugs item #665037, was opened at 2003-01-09 16:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=665037group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Shone Sadler (ssadler)
Assigned to: Scott M Stark (starksm)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4

Initial Comment:
When running our remote clients we get a 
NoInitialContextException.  The exception is caused by 
a call to HomeHandle.getEJBHome().  After Looking 
through the source code for JBOSS, it seems that 
JBOSS 3.0.4's 
com.jboss.proxy.ejb.handle.HomeHandleImpl does not 
serialize the JNDI context information like is should (and 
used to in JBOSS2.4.  Instead it always creates a new 
InitialContext in the getEJBHome method.  The following 
example illustrates the problem.

import 
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;


import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;

public class Example {
   public static void main(String[] args) throws Exception 
{
 Properties _prop = new Properties();
  _prop.setProperty
(java.naming.factory.initial,org.jnp.interfaces.NamingC
ontextFactory);
  _prop.setProperty
(java.naming.factory.url.pkgs,org.jboss.naming:org.jnp.
interfaces);
  _prop.setProperty
(java.naming.provider.url,localhost);
  _prop.setProperty
(java.naming.provider.port,1099);

  InitialContext _ic = new InitialContext(_prop);
  POFObjectManagerRemoteHome _om_home = 
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
(qlink/POFObjectManager),POFObjectManagerRemote
Home.class);

  HomeHandle _hhandle = _om_home.getHomeHandle
();
  //Here is where the NoInitialContextException is 
thrown
  _om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
   }
}


Thanks,

Shone Sadler
Senior Software Developer
Q-Link Technologies



OS: Win2000
JDK:1.3.1_06

Server Trace:

C:\developmentjava Example
Exception in thread main java.rmi.ServerException: 
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to 
specify class name in e
vironment or system property, or as an applet 
parameter, or in an application r
source file:  java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify 
class name in environme
t or system property, or as an applet parameter, or in an 
application resource
ile:  java.naming.factory.initial
at 
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at 
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at 
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)




--

Comment By: Oskari Kettunen (aok)
Date: 2003-01-15 20:34

Message:
Logged In: YES 
user_id=558871

Well, I am aware of this, hence no patch from me as of yet. 

Also, as you may have noticed, I stretched the issue over to 
StatelessHandleImpl. Having it store some preference of 
which HARMIServer to hit upon reconnecting should not 
make it any less robust. And I don't see why it should be any 
different for HomeHandles.

The hindrance is the need to mess with 
JRMPInvokerProxyHA et al. and this shouldn't be any of their 
concern.

Just wanted to point an issue and hoped you would come up 
with a neat solution as usual.

I reckon sticking with the exact same bean as long as 
possible would would help a lot of people. It not being 
possible, I'll live with it.


Oskari Kettunen,
Krocus Communications,
FINLAND


(a long)
P.S.
I am also very aware that my view is partly result of 
stretching the spec:

We have a load of (seppuku) CMR/CMR entities accessed 
via (clustered) SSB facades. We do not want the overhead of 
clustering stateful facades, but we do like the performance 
gain of hitting the same entity container within the same 
session with some probability. Add to this an external fully 
round robin http-load balancer and you get a glimpse of my 
problem field.

One (bad) approach would have been shoving the handle in to 
the HttpSession and let that distribute, assuming it was able 
distinguish between targets.

Another (efficient, but not elegant) is dumping the session ID 
into a ThreadLocal upon receiving a request, and have a 
custom load balance policy divide the hash code modulus 
target list length. Can't be any worse than RoundRobin, and 
in normal circumstances gives a nice gain in performance.


Re[3]: JBossScript was RE: [JBoss-dev] JNuke dev

2003-01-15 Thread Danilo Luiz Rheinheimer
Wednesday, January 15, 2003, 3:27:16 PM, you wrote:

DLR   This can be used to test beans and so on. It runs inside JBoss.
DLR   I have a very simple prototype of this, and I will make it avaliable
DLR tomorrow.

  Install this SAR to a simple example :

  http://www.danilo.floripa.com.br/script-mbean.sar

  Invoke the show() method of the Sigea:service=SigeaScriptManager
MBean. You must to be on the same machine of the server.
  You will see the BeanShell Desktop.
  It is running in the same VM of JBoss.
  So it can be used to write scripts in a very convenient way.

  There are some problems with this quick sample :

  - It uses the BeanShell Desktop class, and it was done to be a
  standalone application. So when you exit it will shutdown your
  jboss server. In a production implementation we need to fix this.

  - There are no access to all the classes on the JBoss enviroment.
  Click with the right button on the BeanShell Desktop and click on
  new class browser to see what is avaliable to scripts. I need to
  study more the classloader architecture to make this really work.

  What do you think ? This can be usefull ?

-- 
Best regards,
 Danilomailto:[EMAIL PROTECTED]




---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668313 ] jboss 3.0.5 can't redeploy tomcat

2003-01-15 Thread SourceForge.net
Bugs item #668313, was opened at 2003-01-15 05:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668313group_id=22866

Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Adam Heath (doogie)
Assigned to: Scott M Stark (starksm)
Summary: jboss 3.0.5 can't redeploy tomcat

Initial Comment:
Download jboss-3.0.5_tomcat-4.1.18.zip.  Unpack.  Start
server.  Touch
server/default/deploy/tomcat41-service.xml.  The wars,
then tomcat undeploy.  Tomcat then redeploys.  however,
when the wars try to reploy, there LinkageErrors.

2003-01-14 23:01:19,006 INFO 
[org.jboss.deployment.MainDeployer] Starting deployment
of package: file:/home.local/adam/brainfood/jboss/p/jb
oss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/
2003-01-14 23:01:19,126 INFO 
[org.jboss.web.catalina.EmbeddedCatalinaService41]
deploy, ctxPath=/invoker, warUrl=file:/home.local/adam/brai
nfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/
2003-01-14 23:01:20,470 INFO 
[org.jboss.web.localhost.Engine]
WebappLoader[/invoker]: Deploying class repositories to
work directory /home.
local/adam/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/tomcat-4.1.x/work/MainEngine/localhost/invoker
2003-01-14 23:01:20,520 INFO 
[org.jboss.web.localhost.Engine]
WebappLoader[/invoker]: Deploy class files
/WEB-INF/classes to /home.local/ad
am/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/WEB-INF/classes
2003-01-14 23:01:21,369 INFO 
[org.jboss.web.localhost.Engine]
ContextConfig[/invoker]: Added certificates - request
attribute Valve
2003-01-14 23:01:21,635 INFO 
[org.jboss.web.localhost.Engine]
ContextConfig[/invoker]: Configured an authenticator
for method BASIC
2003-01-14 23:01:21,993 INFO 
[org.jboss.web.catalina.EmbeddedCatalinaService41]
Using Java2 parent classloader delegation: true
2003-01-14 23:01:21,998 INFO 
[org.jboss.web.localhost.Engine]
StandardManager[/invoker]: Seeding random number
generator class java.securit
y.SecureRandom
2003-01-14 23:01:22,003 INFO 
[org.jboss.web.localhost.Engine]
StandardManager[/invoker]: Seeding of random number
generator has been comple
ted
2003-01-14 23:01:22,252 ERROR
[org.jboss.web.localhost.Engine]
StandardContext[/invoker]: Exception starting filter
ReadOnlyAccessFilter
java.lang.LinkageError: loader constraints violated
when linking javax/servlet/FilterConfig class
at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:254)
at
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:314)
at
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:120)
at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3158)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3602)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579)
at
org.jboss.web.catalina.EmbeddedCatalinaService41.createWebContext(EmbeddedCatalinaService41.java:432)
at
org.jboss.web.catalina.EmbeddedCatalinaService41.performDeploy(EmbeddedCatalinaService41.java:306)
at
org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:300)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:814)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627)
at
org.jboss.deployment.MainDeployer.addDeployer(MainDeployer.java:230)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.deployment.SubDeployerSupport.startService(SubDeployerSupport.java:98)
at
org.jboss.web.catalina.EmbeddedCatalinaService41.startService(EmbeddedCatalinaService41.java:263)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003)
at $Proxy4.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:413)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
   

Re[4]: [JBoss-dev] JNuke dev

2003-01-15 Thread Alex Loubyansky
BB This may or may not disappear.  The thought is to name the whole metadata
BB block for purposes of redeployment or undeployment.  Am I making sense?

Frankly, I don't see, currently. I am not asking to remove it, just to
clarify.

Thanks,
alex

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Alex
 Loubyansky
 Sent: Wednesday, January 15, 2003 10:56 AM
 To: [EMAIL PROTECTED]
 Subject: RE: Re[2]: [JBoss-dev] JNuke dev


 I meant specifying them in XDoclet style, not XML.

 /**
  * @classAttr
  */
 class MyClass {

  /**
   * @fieldAttr
   */
  private int myField;

  /**
   * @methodAttr
   */
  public void myMethod() {

 BTW, could you please exmplain what is the purpose of the 'name' attribute
 in class-metadata element?
 In the forum or here.

 Thanks,
 alex




---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re[6]: [JBoss-dev] URLConnection and opened files

2003-01-15 Thread Jeremy Boynes
Alex

The light went on and I'm now wondering if I triggered this with the changes
for deployment scanning.

IIRC the code used to generate new URLs from the File paths returned during
the scan, basically using the URL(String) constructor with the path.

It now creates URLs relative to the location being scanned using the
URL(URL, String) version. The context URL is the one obtained from
ServerConfig.getServerHomeURL().

If this is set before the custom handler factory is set up, then all
deployed URLs would be using Sun's handler :-(

I think this is happening because ServerImpl.doInit() creates the
ServerConfigImpl before setting up the URLStreamHandlerFactory.

Would it make sense just to move the factory set-up to the very start of
doInit()?

Jeremy

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Alex
 Loubyansky
 Sent: Wednesday, January 15, 2003 5:21 AM
 To: Scott M Stark
 Subject: Re[6]: [JBoss-dev] URLConnection and opened files


 Here are my findings.

 First, JBoss-3.0 is ok. The problem is in JBoss-3.2 and HEAD.

 Second, I found the cause.
 The resources we want to load with our custom handlers
 through class loaders must be added to the classpath AFTER the
 (custom) URLStreamHandlerFactory is setup.

 URLClassLoaders hold their URLs.
 The URLs created before the custom URLStreamHandlerFactory is set up
 have Sun's handler. System class loader is a subclass of the
 URLClassLoader. Thus, its URLs have Sun's handler. (It seems to me even
 if java.protocol.handler.pkgs is setup. Is it a VM's bug or mine?)

 Suppose we attempt to load resource that was in the classpath before
 the custom handler factory was setup. The URL for the resource is
 constructed with: URL(URL context, String spec).
 where the context URL comes from the class loader with Sun's handler.
 Then resource's URL's handler is assigned context.handler.
 So, it doesn't matter whether the custom handler factory is setup.

 alex




---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668700 ] jars in ear/war/WEB-INF/lib aren't redeployed correctly

2003-01-15 Thread SourceForge.net
Bugs item #668700, was opened at 2003-01-15 20:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668700group_id=22866

Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Heath (doogie)
Assigned to: Scott M Stark (starksm)
Summary: jars in ear/war/WEB-INF/lib aren't redeployed correctly

Initial Comment:
Deploy an ear, that contains a war, that contains a
.jar in WEB-INF/lib.  Touch tomcat41-service.xml.  The
war(but not the ear) is undeployed.  Tomcat is
undeployed.  Tomcat is redeployed.  The war
redeployment  is attempted, but fails with the
following exception:

2003-01-15 13:57:36,560 INFO 
[org.jboss.web.localhost.Engine]
WebappLoader[/partymgr]: Deploy JAR
/WEB-INF/lib/partymgr.jar to /home.local/
adam/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/soapfiend.ear/partymgr.war/WEB-INF/lib/partymgr.jar
2003-01-15 13:57:36,912 ERROR
[org.jboss.web.localhost.Engine]
ContextConfig[/partymgr] Exception processing JAR at
resource path /WEB-INF/l
ib/partymgr.jar
javax.servlet.ServletException: Exception processing
JAR at resource path /WEB-INF/lib/partymgr.jar
at
org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930)
at
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868)
at
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3567)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579)
at
org.jboss.web.catalina.EmbeddedCatalinaService41.createWebContext(EmbeddedCatalinaService41.java:432)
at
org.jboss.web.catalina.EmbeddedCatalinaService41.performDeploy(EmbeddedCatalinaService41.java:306)
at
org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:300)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:814)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627)
at
org.jboss.deployment.MainDeployer.addDeployer(MainDeployer.java:230)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.deployment.SubDeployerSupport.startService(SubDeployerSupport.java:98)
at
org.jboss.web.catalina.EmbeddedCatalinaService41.startService(EmbeddedCatalinaService41.java:263)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003)
at $Proxy4.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:413)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy2.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:229)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:814)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:591)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy3.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:435)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:561)
2003-01-15 13:57:37,873 ERROR
[org.jboss.web.localhost.Engine] - Root Cause -
java.lang.IllegalStateException: Illegal class loader
binding
at
org.apache.naming.resources.DirContextURLStreamHandler.get(DirContextURLStreamHandler.java:234)
at

[JBoss-dev] [ jboss-Bugs-594137 ] SOAPAction not set

2003-01-15 Thread SourceForge.net
Bugs item #594137, was opened at 2002-08-12 19:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=594137group_id=22866

Category: JBossSOAP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Dr. Christoph Georg Jung (cgjung)
Summary: SOAPAction not set

Initial Comment:
The auto-generated wsdl-file is missing soapAction,
whch should be th e same as wsdl:operation name.
This is neccesary for M$ Soap toolkit to work, and
maybe other SOAP implementations like for perl.

   wsdl:operation name=insertPerson  HERE - V
***HERE-***  wsdlsoap:operation soapAction=/
  wsdl:input

wsdlsoap:body use=encoded
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
namespace=xxx/
  /wsdl:input
  wsdl:output
wsdlsoap:body use=encoded
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
namespace=xxx/
  /wsdl:output
/wsdl:operation

--

Comment By: Marius Kotsbak (mkotsbak)
Date: 2003-01-15 21:15

Message:
Logged In: YES 
user_id=366650

BTW: perl clients works without soapaction

--

Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-09-11 12:03

Message:
Logged In: YES 
user_id=366650

OK. I can try with the new version 3.0 of the soap toolkit
first.

--

Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-11 10:46

Message:
Logged In: YES 
user_id=175199

Now, here we are. That´s a bug in the MS-SOap Toolkit, if 
you ask me:

From AxisServlet:

private String getSoapAction(HttpServletRequest req)
throws AxisFault
{
String soapAction =(String)req.getHeader
(HTTPConstants.HEADER_SOAP_ACTION);

if (soapAction == null) {
AxisFault af = new AxisFault(Client.NoSOAPAction,
 JavaUtils.getMessage
(noHeader00,
  SOAPAction),
 null, null);
  }


Which means that the call will fault when there is no such 
soapAction header. It will not fault (and be further processed), 
if your soapAction header is  (and that is what the 
generated wsdl is saying, if you ask me).







--

Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-09-11 10:30

Message:
Logged In: YES 
user_id=366650

Here is the error when using the wsdl-file directly with
empty soapAction from MS Soap toolkit:

SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
 SOAP-ENV:Body
  SOAP-ENV:Fault
   faultcode
xmlns:ns1=http://xml.apache.org/axis/;ns1:Client.NoSOAPAction/faultcode
   faultstringno SOAPAction header!/faultstring
   detail
ns2:stackTrace
xmlns:ns2=http://xml.apache.org/axis/;no SOAPAction header!
at
org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:509)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:344)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:313)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:554)
at
org.mortbay.jetty.servlet.WebApplicationHandler.handle(WebApplicationHandler.java:199)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1572)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1522)
at
org.mortbay.http.HttpServer.service(HttpServer.java:795)
at org.jboss.jetty.Jetty.service(Jetty.java:531)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:784)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:941)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:799)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:186)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:322)
at
org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:713)
at java.lang.Thread.run(Thread.java:536)
/ns2:stackTrace
   /detail
  /SOAP-ENV:Fault
 /SOAP-ENV:Body
/SOAP-ENV:Envelope)

I will send a question about this to the axis-list with
reference to this bug

--

Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-09 12:25

Message:
Logged In: YES 
user_id=175199

I looked again at the Axis Emitter code and there is the 
following line in writeBindingOperation:

// If the soapAction option is OPERATION, force
// soapAction to the name of the operation. If NONE,
// force 

Re[6]: [JBoss-dev] URLConnection and opened files

2003-01-15 Thread Scott M Stark
Yes, the setup of the URL handlers should be the very first thing done in doInit.
There is nothing in that layer that can rely on ServerConfig information as this
is just standard URL protocol handler extension stuff.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: Jeremy Boynes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 15, 2003 11:42 AM
Subject: Re[6]: [JBoss-dev] URLConnection and opened files


 Alex
 
 The light went on and I'm now wondering if I triggered this with the changes
 for deployment scanning.
 
 IIRC the code used to generate new URLs from the File paths returned during
 the scan, basically using the URL(String) constructor with the path.
 
 It now creates URLs relative to the location being scanned using the
 URL(URL, String) version. The context URL is the one obtained from
 ServerConfig.getServerHomeURL().
 
 If this is set before the custom handler factory is set up, then all
 deployed URLs would be using Sun's handler :-(
 
 I think this is happening because ServerImpl.doInit() creates the
 ServerConfigImpl before setting up the URLStreamHandlerFactory.
 
 Would it make sense just to move the factory set-up to the very start of
 doInit()?
 
 Jeremy



---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668710 ] jboss.org vilolaties w3c-standards and doesn't render right

2003-01-15 Thread SourceForge.net
Bugs item #668710, was opened at 2003-01-15 21:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668710group_id=22866

Category: JBossDoc
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Nobody/Anonymous (nobody)
Summary: jboss.org vilolaties w3c-standards and doesn't render right

Initial Comment:
jboss.org has 56 violations of the HTML 4.01
Transitional that it is supposed to conform to
according to:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.jboss.org%2Fcharset=%28detect+automatically%29doctype=%28detect+automatically%29verbose=1

Another validator:
http://www.htmlhelp.com/cgi-bin/validate.cgi?url=http://www.jboss.org/warnings=yesinput=yes

This gives the result that I have attached a screenshot
of, the menu is repeated 1/4 to the right of the menu
in both mozilla and opera browsers (havent't checked
others).

Please update the webpage so it follows the web
standards as jboss follows sun's EJB standards.

--

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


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] [ jboss-Bugs-668710 ] jboss.org vilolaties w3c-standards and doesn't render right

2003-01-15 Thread Jeff Haynie
Is this is JOKE? I think I'd prefer to spend my time on AOP / JB4.
geez.. ... ;)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
SourceForge.net
Sent: Wednesday, January 15, 2003 3:27 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] [ jboss-Bugs-668710 ] jboss.org vilolaties
w3c-standards and doesn't render right


Bugs item #668710, was opened at 2003-01-15 21:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668710grou
p_id=22866

Category: JBossDoc
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Nobody/Anonymous (nobody)
Summary: jboss.org vilolaties w3c-standards and doesn't render right

Initial Comment:
jboss.org has 56 violations of the HTML 4.01
Transitional that it is supposed to conform to
according to:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.jboss.org%2Fcharset=
%28detect+automatically%29doctype=%28detect+automatically%29verbose=1

Another validator:
http://www.htmlhelp.com/cgi-bin/validate.cgi?url=http://www.jboss.org/w
arnings=yesinput=yes

This gives the result that I have attached a screenshot
of, the menu is repeated 1/4 to the right of the menu
in both mozilla and opera browsers (havent't checked
others).

Please update the webpage so it follows the web
standards as jboss follows sun's EJB standards.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668710grou
p_id=22866


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] [ jboss-Bugs-668710 ] jboss.org vilolaties w3c-standardsand doesn't render right

2003-01-15 Thread Adam Heath
On Wed, 15 Jan 2003, Jeff Haynie wrote:

 Is this is JOKE? I think I'd prefer to spend my time on AOP / JB4.
 geez.. ... ;)

So what if it is?  The fact that people are spending time checking it is in
and of itself something to be proud of.

JBoss is getting pushed into all corners of the world, and so more and more
eyes are focusing on it.



---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668736 ] Cannot tokenize withOracle Net8 JDBC connection descriptions

2003-01-15 Thread SourceForge.net
Bugs item #668736, was opened at 2003-01-15 15:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668736group_id=22866

Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Hayward (shayward)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot tokenize withOracle Net8 JDBC connection descriptions

Initial Comment:
If you define a Oracle datasource in oracle-xa-service.xml
using Net8 connection descriptions like:
config-property 
name=XADataSourceProperties 

type=java.lang.StringURL=jdbc:oracle:thin:@
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=
(PROTOCOL=TCP)(PORT=1521)(HOST=10.1.1.1)))
(connect_data=(server=dedicated)(sid=foo_database)))
/config-property


when you use this datasource, Jboss gets the following 
exception:
2003-01-15 14:58:31,590 INFO  
[org.jboss.system.server.Server] JBoss (MX 
MicroKernel) [3.0.4 Date:200211021607] Started in 
0m:15s:462ms
2003-01-15 14:59:08,583 WARN  
[org.jboss.resource.adapter.jdbc.xa.XAManagedConnecti
onFactory] Unable to create and initialize XADataSource:
java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken
(StringTokenizer.java:235)
at 
org.jboss.resource.adapter.jdbc.xa.XAManagedConnecti
onFactory.parseProperties
(XAManagedConnectionFactory.java:491)
at 
org.jboss.resource.adapter.jdbc.xa.XAManagedConnecti
onFactory.getXADS
(XAManagedConnectionFactory.java:455)
at 
org.jboss.resource.adapter.jdbc.xa.XAManagedConnecti
onFactory.createManagedConnection
(XAManagedConnectionFactory.java:368)
at 
org.jboss.resource.connectionmanager.InternalManaged
ConnectionPool.createConnection
(InternalManagedConnectionPool.java:259)
at 
org.jboss.resource.connectionmanager.InternalManaged
ConnectionPool.getConnection
(InternalManagedConnectionPool.java:106)
at 
org.jboss.resource.connectionmanager.JBossManagedC
onnectionPool$BasePool.getConnection
(JBossManagedConnectionPool.java:323)
at 
org.jboss.resource.connectionmanager.BaseConnection
Manager2.getManagedConnection
(BaseConnectionManager2.java:467)
at 
org.jboss.resource.connectionmanager.BaseConnection
Manager2.allocateConnection
(BaseConnectionManager2.java:532)
at 
org.jboss.resource.connectionmanager.BaseConnection
Manager2$ConnectionManagerProxy.allocateConnection
(BaseConnectionManager2.java:814)
at 
org.jboss.resource.adapter.jdbc.JDBCDataSource.getCo
nnection(JDBCDataSource.java:110)

I found that XAManagedConnectionFactory uses:
StringTokenizer tokens = new StringTokenizer
(xaDataSourceProperties, ;=);

and Oracle JDBC allows Net8 (name=value) type 
connection descriptors, but with this code JBOSS does 
not.

--

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


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668786 ] LinkageError: loader constraints violated

2003-01-15 Thread SourceForge.net
Bugs item #668786, was opened at 2003-01-15 17:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668786group_id=22866

Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Hayward (shayward)
Assigned to: Nobody/Anonymous (nobody)
Summary: LinkageError: loader constraints violated

Initial Comment:
I am using JDK1.3.1-b24 on Window 2000 pro.

here is the error I get when calling a EJB and it tries to 
open a JDBC connection to a Oracle database:

2003-01-15 10:57:50,796 INFO  
[org.jboss.system.server.Server] JBoss (MX 
MicroKernel) [3.0.4 Date:200211021607] Started in 
0m:22s:463ms

2003-01-15 10:58:44,242 ERROR 
[org.jboss.ejb.plugins.LogInterceptor] Unexpected Error:
java.lang.LinkageError: loader constraints violated when 
linking javax/sql/ConnectionEventListener class

=
Now here is what my research has uncovered.  
I am using Oracle therefore I have classes12.zip in the 
lib directory.
I turned on DEBUG logging in conf/log4j.xml
I then run again and I see in the log that 
javax.sql.ConnectionEventListener.class was found in 2 
jars. 
1. classes12.zip (Oracle JDBC drivers)
2. jboss-j2ee.jar 

after some investigation I discovered that these interface 
classes are different (they should be the same as Sun's 
J2ee 1.2.1 version of them)  so I download Sun's source 
for j2ee1.2.1 and found that jboss version of 
javax.sql.ConnectionEventListener.java is indeed 
different from jboss's version of the same interface:

Sun's version of javax.sql.ConnectionEventListener 
declares:
void connectionClosed...
void connectionErrorOccurred...

Jboss's version of javax.sql.ConnectionEventListener 
declares:
public void connectionClosed
public void connectionErrorOccurred

I believe that I get the LinkageError because the Oracle 
classes12.zip has the exact same copy as Sun's.


--

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


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Transaction propagation change

2003-01-15 Thread Hiram Chirino

Just a small correction..  your example would have to be in at least 2 units
of work.  There is NO WAY to put a JMS message and get it again in a single
transaction.

Regards,
Hiram

 Having a distributed transaction context is especially important
 for example
 when you have a EJB from one jboss instance posting a message to
 a JMS queue
 on another jboss instance that in turn has a MDB that calls another EJB on
 that second instance.  If I want that all to be under one transaction and
 thus rollback as one business unit of work, there is no way to do
 that (that
 i'm aware of) with native JBoss in the 3.x series.  I know one could use
 Tyrex, but the author doesn't recommend using Tyrex in a production
 environment and so I'm a little leary to use it myself.







---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668789 ] Autodeployment does not work

2003-01-15 Thread SourceForge.net
Bugs item #668789, was opened at 2003-01-16 00:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668789group_id=22866

Category: None
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Arentz (sateh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Autodeployment does not work

Initial Comment:
Jboss-3.2.0RC1

When copying a new .ear in the deploy directory, nothing happens.

Standard config, nothing changed.

 S.

--

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


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Transaction propagation change

2003-01-15 Thread danch
And having a way to do that would probably be a Bad Idea. Propogating a 
transaction through asynchronous transports doesn't sound like a good 
idea to me, anyway.

-danch

Hiram Chirino wrote:
Just a small correction..  your example would have to be in at least 2 units
of work.  There is NO WAY to put a JMS message and get it again in a single
transaction.

Regards,
Hiram



Having a distributed transaction context is especially important
for example
when you have a EJB from one jboss instance posting a message to
a JMS queue
on another jboss instance that in turn has a MDB that calls another EJB on
that second instance.  If I want that all to be under one transaction and
thus rollback as one business unit of work, there is no way to do
that (that
i'm aware of) with native JBoss in the 3.x series.  I know one could use
Tyrex, but the author doesn't recommend using Tyrex in a production
environment and so I'm a little leary to use it myself.








---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [ jboss-Bugs-668789 ] Autodeployment does not work

2003-01-15 Thread SourceForge.net
Bugs item #668789, was opened at 2003-01-15 15:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668789group_id=22866

Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Stefan Arentz (sateh)
Assigned to: Scott M Stark (starksm)
Summary: Autodeployment does not work

Initial Comment:
Jboss-3.2.0RC1

When copying a new .ear in the deploy directory, nothing happens.

Standard config, nothing changed.

 S.

--

Comment By: Scott M Stark (starksm)
Date: 2003-01-15 15:29

Message:
Logged In: YES 
user_id=175228

You are going to have to provide more info than this as it 
works fine for me:

15:21:22,109 INFO  [MainDeployer] Deployed package: 
file:/C:/tmp/JBoss/jboss-3.2.0RC1/server/default/conf/jboss-
service.xml
15:21:22,109 INFO  [Server] JBoss (MX MicroKernel) 
[3.2.0RC1 (build: CVSTag=JBoss_3_2_0_RC1 
date=200301142016)] Started in 19s:547ms
...
Copy jbosstest-web.ear into deploy
...
15:21:52,140 INFO  [MainDeployer] Starting deployment of 
package: file:/C:/tmp/JBoss/jboss-
3.2.0RC1/server/default/deploy/jbosstest-web.ear
15:21:52,156 INFO  [EARDeployer] Init J2EE application: 
file:/C:/tmp/JBoss/jboss-
3.2.0RC1/server/default/deploy/jbosstest-web.ear
15:21:52,203 INFO  [EJBDeployer] looking for nested 
deployments in : file:/C:/tmp/JBoss/jboss-
3.2.0RC1/server/default/tmp/deploy/server/default/deploy
/jbosstest-web.ear/29.jbosstest-web.ear-contents/cts.jar
15:21:52,218 INFO  [EJBDeployer] looking for nested 
deployments in : file:/C:/tmp/JBoss/jboss-
3.2.0RC1/server/default/tmp/deploy/server/default/deploy
/jbosstest-web.ear/29.jbosstest-web.ear-contents/jbosstest-
web-ejbs.jar
15:21:52,484 INFO  [EjbModule] Creating
15:21:52,500 INFO  [EjbModule] Deploying BMPBean
15:21:52,578 INFO  [EjbModule] Deploying 
BMPCallbackBean
15:21:52,593 INFO  [EjbModule] Deploying CMPBean
15:21:52,625 INFO  [EjbModule] Deploying 
StatelessSessionBean
15:21:52,640 INFO  [EjbModule] Deploying 
StatefulSessionBean
15:21:52,671 INFO  [StatefulSessionContainer] Creating
15:21:52,687 INFO  
[StatefulSessionFilePersistenceManager] Creating
15:21:52,687 INFO  
[StatefulSessionFilePersistenceManager] Created
15:21:52,687 INFO  [StatefulSessionContainer] Created
15:21:52,718 INFO  [EntityContainer] Creating
15:21:52,718 INFO  [EntityContainer] Created
15:21:52,734 INFO  [EntityContainer] Creating
15:21:52,734 INFO  [EntityContainer] Created
15:21:52,750 INFO  [EntityContainer] Creating
15:21:52,750 INFO  [EntityContainer] Created
15:21:52,750 INFO  [StatelessSessionContainer] Creating
15:21:52,765 INFO  [StatelessSessionContainer] Created
15:21:52,765 INFO  [EjbModule] Created
15:21:52,953 INFO  [EjbModule] Creating
15:21:52,984 INFO  [EjbModule] Deploying Entity
15:21:53,000 INFO  [EjbModule] Deploying ENCBean0
15:21:53,000 INFO  [EjbModule] Deploying ENCBean1
15:21:53,015 INFO  [EjbModule] Deploying SecuredEJB
15:21:53,031 INFO  [JaasSecurityManagerService] Created 
securityMgr=org.jboss.security.plugins.JaasSecurityManager
@88a1b
15:21:53,031 INFO  [JaasSecurityManagerService] 
setCachePolicy, c=org.jboss.util.TimedCachePolicy@232ea4
15:21:53,031 INFO  [JaasSecurityManagerService] Added 
other, 
org.jboss.security.plugins.SecurityDomainContext@4b12d9 
to map
15:21:53,046 INFO  [EjbModule] Deploying UnsecuredEJB
15:21:53,046 INFO  [EjbModule] Deploying OptimizedEJB



--

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


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Transaction propagation change

2003-01-15 Thread marc fleury
one of my favorite topics is coming up again 
One day I will sit down and write a tx spec.

Ok frankly WHY DO WE CARE THAT MESSAGING IS ASYNCHRONOUS WITH RESPECT TO
TRANSACTION.  Yeah I know the answer you could have a long running
transaction and messages and queues and bla bla bla.  BS BS BS.  

So the method returns immediately.  SO WHAT? the listener that will pick
up the message and act upon it may very well want to synchronize with
the GLOBAL transaction going on in the web.  And commit or rollback
according to the outcome. 

The scenario is simple. 

Image A does something and sends messages to n instances with a global
transaction associated to it. 

n recievers get the message get the TPC and register with the global tx.
If the global tx is still running then all good 2phi dance starts bla
bla bla. if the tx is out (too old) then the guy who woke up late just
says sorry can't register and possibly no one cares or he can notify
(whatever the app rollback semantics are). 

AT A SYSTEM LEVEL I DONT SEE A REASON FOR THIS BAD IDEA SYNDROME. IN
fact it always has struck me that there is NO WAY to propagate a TX with
a message.  

you know what? this is something we can VERY easily do in JBoss.  Adding
the message in the new rewrite may be the usual 'put an interceptor
here' deal, once we make progress on the rewrite. 

But the point is simple, the asynchronous nature of the transport
protocol should not have an impact on the definition of a web
transaction. 

IN fact it is a requisite for web services (generic way)Tx definitions. 

Many threads TX!

/water-walking

marcf

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]] On 
 Behalf Of danch
 Sent: Wednesday, January 15, 2003 6:18 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Transaction propagation change
 
 
 And having a way to do that would probably be a Bad Idea. 
 Propogating a 
 transaction through asynchronous transports doesn't sound like a good 
 idea to me, anyway.
 
 -danch
 
 Hiram Chirino wrote:
  Just a small correction..  your example would have to be in 
 at least 2 
  units of work.  There is NO WAY to put a JMS message and 
 get it again 
  in a single transaction.
  
  Regards,
  Hiram
  
  
 Having a distributed transaction context is especially 
 important for 
 example when you have a EJB from one jboss instance posting 
 a message 
 to a JMS queue
 on another jboss instance that in turn has a MDB that calls 
 another EJB on
 that second instance.  If I want that all to be under one 
 transaction and
 thus rollback as one business unit of work, there is no way to do
 that (that
 i'm aware of) with native JBoss in the 3.x series.  I 
 know one could use
 Tyrex, but the author doesn't recommend using Tyrex in a production
 environment and so I'm a little leary to use it myself.
 
  
 
 
 
 
 ---
 This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
 is essential in establishing user confidence by providing 
 assurance of 
 authenticity and code integrity. Download our Free Code 
 Signing guide: 
 http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0028en
 
 
 ___
 Jboss-development mailing list [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: Re[6]: [JBoss-dev] URLConnection and opened files

2003-01-15 Thread Jeremy Boynes
OK - changed this in 3.2 and HEAD and I can now delete a .war archive I
couldn't before.

Alex, can you let me know if this worked for you. Sorry about the hassle.


 Yes, the setup of the URL handlers should be the very first thing
 done in doInit.
 There is nothing in that layer that can rely on ServerConfig
 information as this
 is just standard URL protocol handler extension stuff.




---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668805 ] 32RC1 - Every JMS message creates and destroys my MDB

2003-01-15 Thread SourceForge.net
Bugs item #668805, was opened at 2003-01-15 15:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668805group_id=22866

Category: JBossMQ
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: 32RC1 - Every JMS message creates and destroys my MDB

Initial Comment:

It appears that for each message, JBoss calls ejbCreate
and ejbDestroy.

Before this release, it looked like ejbDestroy was
never being called.

I can't browse CVS on SourceForge, maybe someone could
take a look at what might have changed in:

./src/main/org/jboss/ejb/plugins/AbstractInstancePool.java

Thanks!

--

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


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668805 ] 32RC1 - Every JMS message creates and destroys my MDB

2003-01-15 Thread SourceForge.net
Bugs item #668805, was opened at 2003-01-16 00:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668805group_id=22866

Category: JBossMQ
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: 32RC1 - Every JMS message creates and destroys my MDB

Initial Comment:

It appears that for each message, JBoss calls ejbCreate
and ejbDestroy.

Before this release, it looked like ejbDestroy was
never being called.

I can't browse CVS on SourceForge, maybe someone could
take a look at what might have changed in:

./src/main/org/jboss/ejb/plugins/AbstractInstancePool.java

Thanks!

--

Comment By: Stefan Arentz (sateh)
Date: 2003-01-16 01:45

Message:
Logged In: YES 
user_id=66079

I see the same behaviour. Also, the StrictMaximumSize fix in 3.0.5 that worked so 
great doesn't seem to work at all in 3.2.0RC1. I see the same behaviour of creating 
MDBs as in 3.0.4. This could be related.

 S.

--

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


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668805 ] 32RC1 - Every JMS message creates and destroys my MDB

2003-01-15 Thread SourceForge.net
Bugs item #668805, was opened at 2003-01-15 15:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668805group_id=22866

Category: JBossMQ
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: 32RC1 - Every JMS message creates and destroys my MDB

Initial Comment:

It appears that for each message, JBoss calls ejbCreate
and ejbDestroy.

Before this release, it looked like ejbDestroy was
never being called.

I can't browse CVS on SourceForge, maybe someone could
take a look at what might have changed in:

./src/main/org/jboss/ejb/plugins/AbstractInstancePool.java

Thanks!

--

Comment By: Elias Ross (genman)
Date: 2003-01-15 16:58

Message:
Logged In: YES 
user_id=556458

I do have a fix:  Copy the jboss-3.2 beta3
server/default/lib/jboss.jar over the RC1 version, and the
problem seems to go away.  I'll hunt done some diff's for
the bug.

--

Comment By: Stefan Arentz (sateh)
Date: 2003-01-15 16:45

Message:
Logged In: YES 
user_id=66079

I see the same behaviour. Also, the StrictMaximumSize fix in 3.0.5 that worked so 
great doesn't seem to work at all in 3.2.0RC1. I see the same behaviour of creating 
MDBs as in 3.0.4. This could be related.

 S.

--

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


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-668805 ] 32RC1 - Every JMS message creates and destroys my MDB

2003-01-15 Thread SourceForge.net
Bugs item #668805, was opened at 2003-01-15 15:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668805group_id=22866

Category: JBossMQ
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: 32RC1 - Every JMS message creates and destroys my MDB

Initial Comment:

It appears that for each message, JBoss calls ejbCreate
and ejbDestroy.

Before this release, it looked like ejbDestroy was
never being called.

I can't browse CVS on SourceForge, maybe someone could
take a look at what might have changed in:

./src/main/org/jboss/ejb/plugins/AbstractInstancePool.java

Thanks!

--

Comment By: Elias Ross (genman)
Date: 2003-01-15 17:25

Message:
Logged In: YES 
user_id=556458


Here is a trace log:

01:19:38,588 TRACE [JMSContainerInvoker] processing message:
org.jboss.mq.SpyTextMessage {
Header {
   jmsDestination  : QUEUE.dialogserver
   jmsDeliveryMode : 2
   jmsExpiration   : 0
   jmsPriority : 4
   jmsMessageID: ID:10-10426799785858
   jmsTimeStamp: 1042679978585
   jmsCorrelationID: null
   jmsReplyTo  : null
   jmsType : null
   jmsRedelivered  : false
   jmsPropertiesReadWrite:false
   msgReadOnly : true
   producerClientId: ID:10
}
Body {
   text:env/env
}
}
01:19:38,589 DEBUG [ProxyFactoryFinderInterceptor]
invokerBInding is null in ProxyFactoryFinder
01:19:38,589 TRACE [LogInterceptor] Start method=onMessage
01:19:38,591 TRACE [TxInterceptorCMT] Current transaction in
MI is TransactionImpl:XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//14, BranchQual=]
01:19:38,591 TRACE [TxInterceptorCMT] TX_REQUIRED for onMessage
01:19:38,591 TRACE [TxInterceptorCMT] Thread came in with tx
TransactionImpl:XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//14, BranchQual=]01:19:38,592
TRACE [MessageDrivenInstancePool] Get instance
org.jboss.ejb.plugins.MessageDrivenInstancePool@c9537b#0#class
com.proteusmobile.dialogserver.interpreter.DialogInterpreterMDB
01:19:38,592 INFO  [DialogInterpreterMDB] ejbCreate

01:19:38,711 TRACE [MessageDrivenInstancePool] 0/100 Free
instance:org.jboss.ejb.plugins.MessageDrivenInstancePool@c9537b#null#TransactionImpl:XidImpl
[FormatId=257, GlobalId=eross.m-qube.com//14,
BranchQual=]#false#class
com.proteusmobile.dialogserver.interpreter.DialogInterpreterMDB
01:19:38,712 TRACE [MessageDrivenInstancePool] Discard
instance:org.jboss.ejb.plugins.MessageDrivenInstancePool@c9537b#org.jboss.ejb.MessageDrivenEnterpriseContext@128647a#null#false#class
com.proteusmobile.dialogserver.interpreter.DialogInterpreterMDB
01:19:38,713 TRACE [TxInterceptorCMT] TxInterceptorCMT: In
finally
01:19:38,714 TRACE [LogInterceptor] End method=onMessage


--

Comment By: Elias Ross (genman)
Date: 2003-01-15 16:58

Message:
Logged In: YES 
user_id=556458

I do have a fix:  Copy the jboss-3.2 beta3
server/default/lib/jboss.jar over the RC1 version, and the
problem seems to go away.  I'll hunt done some diff's for
the bug.

--

Comment By: Stefan Arentz (sateh)
Date: 2003-01-15 16:45

Message:
Logged In: YES 
user_id=66079

I see the same behaviour. Also, the StrictMaximumSize fix in 3.0.5 that worked so 
great doesn't seem to work at all in 3.2.0RC1. I see the same behaviour of creating 
MDBs as in 3.0.4. This could be related.

 S.

--

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


---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] JSR-77 refactoring has begun

2003-01-15 Thread Scott M Stark
I started the refactoring of the JSR-77 layer to pull it out of the core. The initial 
checkin
focuses on the SAR related code. The change will be to move the JSR-77 object creation
out of the core deployers and components and into the JSR-77 module itself. The
interaction between the two layer is vis JMX notifications. So far this has simplified
both the core and the JSR-77 code. I expect this to be complete by the end of the
week. Beyond that updating the classes to the JSR-77 1.0 final release and populating
the statistics is what will take some work.


Scott Stark
Chief Technology Officer
JBoss Group, LLC



---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Transaction propagation change

2003-01-15 Thread danch
I think you're talking about giving people something more like 
asynchronous method invocations (one-way) than traditional MOM style 
messages, right?

My MOM exists to keep me and my brothers from fighting: she takes 
notes one to the other, maybe 'forgets' the particularly nasty ones, 
makes sure there's a cooling off period, etc. The purpose of MOM is to 
decouple - propagating transactions with the message is a bad idea 
because you're using a hammer to turn a screw.

An asynch. invocation on the other hand, ought to take the transaction 
with it, but I think you want a different programming model than the 
JMS overhead crap (look up three object in JNDI, call three factories, 
sacrifies three virgin goats...) I wouldn't care if it were 
implemented on the same infrastructure as JBossMQ, but I'd really want 
a more light-weight programming model - like an asynchronous Aspect 
for the target object, or something...

-danch

marc fleury wrote:
one of my favorite topics is coming up again 
One day I will sit down and write a tx spec.

Ok frankly WHY DO WE CARE THAT MESSAGING IS ASYNCHRONOUS WITH RESPECT TO
TRANSACTION.  Yeah I know the answer you could have a long running
transaction and messages and queues and bla bla bla.  BS BS BS.  

So the method returns immediately.  SO WHAT? the listener that will pick
up the message and act upon it may very well want to synchronize with
the GLOBAL transaction going on in the web.  And commit or rollback
according to the outcome. 

The scenario is simple. 

Image A does something and sends messages to n instances with a global
transaction associated to it. 

n recievers get the message get the TPC and register with the global tx.
If the global tx is still running then all good 2phi dance starts bla
bla bla. if the tx is out (too old) then the guy who woke up late just
says sorry can't register and possibly no one cares or he can notify
(whatever the app rollback semantics are). 

AT A SYSTEM LEVEL I DONT SEE A REASON FOR THIS BAD IDEA SYNDROME. IN
fact it always has struck me that there is NO WAY to propagate a TX with
a message.  

you know what? this is something we can VERY easily do in JBoss.  Adding
the message in the new rewrite may be the usual 'put an interceptor
here' deal, once we make progress on the rewrite. 

But the point is simple, the asynchronous nature of the transport
protocol should not have an impact on the definition of a web
transaction. 

IN fact it is a requisite for web services (generic way)Tx definitions. 

Many threads TX!

/water-walking

marcf


-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]] On 
Behalf Of danch
Sent: Wednesday, January 15, 2003 6:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Transaction propagation change


And having a way to do that would probably be a Bad Idea. 
Propogating a 
transaction through asynchronous transports doesn't sound like a good 
idea to me, anyway.

-danch

Hiram Chirino wrote:

Just a small correction..  your example would have to be in 

at least 2 

units of work.  There is NO WAY to put a JMS message and 

get it again 

in a single transaction.

Regards,
Hiram




Having a distributed transaction context is especially 


important for 

example when you have a EJB from one jboss instance posting 


a message 

to a JMS queue
on another jboss instance that in turn has a MDB that calls 


another EJB on


that second instance.  If I want that all to be under one 


transaction and


thus rollback as one business unit of work, there is no way to do
that (that
i'm aware of) with native JBoss in the 3.x series.  I 


know one could use


Tyrex, but the author doesn't recommend using Tyrex in a production
environment and so I'm a little leary to use it myself.








---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] ThreadPooling in JMX? Its broken

2003-01-15 Thread Bill Burke
Ok, I was doing some coding and found that my ThreadLocal variable was the
same even between remote MBean invocations.  Is there some ThreadPooling
going on that is not releasing the ThreadLocal variables?

TESTCASE:

1. remotely invoke on method test1 - this sets testit ThreadLocal variable
to hello
2. return from remote invocation
3. remotey invoke on method test2 - this just prints out value of testit
ThreadLocal variable.  It will still be hello!

How the hell can you clear ThreadLocal variables if you are thread pooling?
I'm using the RMI Connector to invoke on my MBean.

Thanks,

Bill



import javax.management.MBeanRegistration;
import javax.management.MBeanServer;
import javax.management.ObjectInstance;
import javax.management.ObjectName;
import org.jboss.logging.Logger;
import org.jboss.system.ServiceMBeanSupport;

public class ThreadLocalTester
   extends ServiceMBeanSupport
   implements ThreadLocalTesterMBean, MBeanRegistration
{
   // Constants 
   // Attributes ---
   static Logger log = Logger.getLogger(AOPTester.class);
   MBeanServer m_mbeanServer;
   ThreadLocal testit = new ThreadLocal();

   // Static ---

   // Constructors -
   public ThreadLocalTester()
   {}

   // Public ---

   // MBeanRegistration implementation ---
   public ObjectName preRegister(MBeanServer server, ObjectName name)
   throws Exception
   {
  m_mbeanServer = server;
  return name;
   }

   public void postRegister(Boolean registrationDone)
   {}
   public void preDeregister() throws Exception
   {}
   public void postDeregister()
   {}

   protected void startService()
  throws Exception
   {
   }

   protected void stopService() {}


   public void test1()
   {
  testit.set(hello);
   }

   public void test2()
   {
  System.out.println(testit.get());
   }

   // Inner classes -
}



---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] WANTED: Lead JBoss Developers

2003-01-15 Thread Bill Burke
We're looking for Lead Developer volunteers.  Please, no emails if you've
never contributed to JBoss.  If you've never contributed to JBoss you'll
need to show some significant initiative before you are even considered.

http://www.jboss.org/developers/projects/jboss/projects.jsp

Please click on Task List to get more information on these projects.

Benefits include.
- Shape the future direction of JBoss
- Name recognition.
- Experience leading a worldwide distributed project
- Visibility.  You may be called on to write articles for magazines and
other publications
- Great Resume builder
- Higher consideration within JBoss Thankgiving Compensation Plan

Being a lead is a lot of responsibility so think before you speak.  Also, if
you become a successful JBoss Lead, don't be surprised if we recruit you to
join JBossGroup, the consulting arm of JBoss.

Projects:

XDoclet:
expand and maintain the JBoss XDoclet integration.  EJBs, JMX/MBeans, AOP,
JBossScript.  Preferably somebody who has already done work on JBoss XDoclet
or XDoclet.

Management:
Web Management Console, MC4J integration, JSR-77.  Some of you I have
already talked about this and have expressed interest.  Express again, and
back it up with some work.

QA (TestSuite):
Need somebody to extrapolate the JUnit extensions we have in the JBoss
testsuite and package and market it as a JBoss downloadable offering.  Also,
documentation for this.

Benchmarking:
Somebody to integrate RICE/Rubis into our CVS.  Somebody to
write/find/incorporate a JMS benchmark.  Somebody to benchmark using ECPERF,
RICE/Rubis, and new JMS benchmarking.   This is interesting work since you
must leverage your knowledge on clustering, caching, and configuration.
Touches all parts of JBoss.



Bill Burke
Chief Architect
JBoss Group, LLC




---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] RE: [JBoss-user] WANTED: Lead JBoss Developers

2003-01-15 Thread Bill Burke
Oh yes and don't forget one of the biggest advantages:

Your technology contributions become a standard.  With over 2.4 million
downloads, JBoss is becoming as big a Linux.  Become a rock star.  Get
involved.

Bill

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke
 Sent: Wednesday, January 15, 2003 9:37 AM
 To: Jboss-Dev; JBoss 2
 Subject: [JBoss-user] WANTED: Lead JBoss Developers


 We're looking for Lead Developer volunteers.  Please, no emails if you've
 never contributed to JBoss.  If you've never contributed to JBoss you'll
 need to show some significant initiative before you are even considered.

 http://www.jboss.org/developers/projects/jboss/projects.jsp

 Please click on Task List to get more information on these projects.

 Benefits include.
 - Shape the future direction of JBoss
 - Name recognition.
 - Experience leading a worldwide distributed project
 - Visibility.  You may be called on to write articles for magazines and
 other publications
 - Great Resume builder
 - Higher consideration within JBoss Thankgiving Compensation Plan

 Being a lead is a lot of responsibility so think before you
 speak.  Also, if
 you become a successful JBoss Lead, don't be surprised if we
 recruit you to
 join JBossGroup, the consulting arm of JBoss.

 Projects:

 XDoclet:
 expand and maintain the JBoss XDoclet integration.  EJBs, JMX/MBeans, AOP,
 JBossScript.  Preferably somebody who has already done work on
 JBoss XDoclet
 or XDoclet.

 Management:
 Web Management Console, MC4J integration, JSR-77.  Some of you I have
 already talked about this and have expressed interest.  Express again, and
 back it up with some work.

 QA (TestSuite):
 Need somebody to extrapolate the JUnit extensions we have in the JBoss
 testsuite and package and market it as a JBoss downloadable
 offering.  Also,
 documentation for this.

 Benchmarking:
 Somebody to integrate RICE/Rubis into our CVS.  Somebody to
 write/find/incorporate a JMS benchmark.  Somebody to benchmark
 using ECPERF,
 RICE/Rubis, and new JMS benchmarking.   This is interesting work since you
 must leverage your knowledge on clustering, caching, and configuration.
 Touches all parts of JBoss.


 
 Bill Burke
 Chief Architect
 JBoss Group, LLC
 



 ---
 This SF.NET email is sponsored by: Take your first step towards giving
 your online business a competitive advantage. Test-drive a Thawte SSL
 certificate - our easy online guide will show you how. Click here to get
 started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-user



---
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re[8]: [JBoss-dev] URLConnection and opened files

2003-01-15 Thread Alex Loubyansky
Thursday, January 16, 2003, 1:38:59 AM, you wrote:

JB OK - changed this in 3.2 and HEAD and I can now delete a .war archive I
JB couldn't before.

JB Alex, can you let me know if this worked for you. Sorry about the hassle.

Yes, it works now.
Thanks,
alex




---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] ThreadPooling in JMX? Its broken

2003-01-15 Thread Scott M Stark
There is no reason to expect that distinct invocations use distinct threads.
The invocation entry point is responsible for establishing the thread
context. In this case the try{...} finally{...} of the JRMPInvoker has
to clear the thread locals if it wants to limit the context to the invocation
lifetime.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Juha Lindfors [EMAIL PROTECTED]; Tom Elrod [EMAIL PROTECTED]; 
Jeff Haynie [EMAIL PROTECTED];
Scott. Stark@Jboss. Org [EMAIL PROTECTED]; Jboss-Dev 
[EMAIL PROTECTED]
Sent: Wednesday, January 15, 2003 8:34 PM
Subject: [JBoss-dev] ThreadPooling in JMX? Its broken


 Ok, I was doing some coding and found that my ThreadLocal variable was the
 same even between remote MBean invocations.  Is there some ThreadPooling
 going on that is not releasing the ThreadLocal variables?

 TESTCASE:

 1. remotely invoke on method test1 - this sets testit ThreadLocal variable
 to hello
 2. return from remote invocation
 3. remotey invoke on method test2 - this just prints out value of testit
 ThreadLocal variable.  It will still be hello!

 How the hell can you clear ThreadLocal variables if you are thread pooling?
 I'm using the RMI Connector to invoke on my MBean.

 Thanks,

 Bill



 import javax.management.MBeanRegistration;
 import javax.management.MBeanServer;
 import javax.management.ObjectInstance;
 import javax.management.ObjectName;
 import org.jboss.logging.Logger;
 import org.jboss.system.ServiceMBeanSupport;

 public class ThreadLocalTester
extends ServiceMBeanSupport
implements ThreadLocalTesterMBean, MBeanRegistration
 {
// Constants 
// Attributes ---
static Logger log = Logger.getLogger(AOPTester.class);
MBeanServer m_mbeanServer;
ThreadLocal testit = new ThreadLocal();

// Static ---

// Constructors -
public ThreadLocalTester()
{}

// Public ---

// MBeanRegistration implementation ---
public ObjectName preRegister(MBeanServer server, ObjectName name)
throws Exception
{
   m_mbeanServer = server;
   return name;
}

public void postRegister(Boolean registrationDone)
{}
public void preDeregister() throws Exception
{}
public void postDeregister()
{}

protected void startService()
   throws Exception
{
}

protected void stopService() {}


public void test1()
{
   testit.set(hello);
}

public void test2()
{
   System.out.println(testit.get());
}

// Inner classes -
 }



---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development