AW: [JBoss-dev] [JBoss.net] - JBoss.net HTTP Basic Authentication problem
Hi Curt, From http://www.jboss.org/developers/guides/jboss.net/security p Hint: Some web service implementations, such as the M$ Soap Toolkit do not send basic authentication data until the server will present them a 401 message. To ensure that the JBossAuthenticationHandler will not route an unauthenticated call with a null security association further down the line, but notify the client, you should set the validateUnauthenticatedCalls option to false. See a href=http://www.nsdev.org/jboss/stories/jboss-net.html;Neal Sanches investigations about that topic/a. /p The default is that unauthenticated calls are routed through with a null association. How do you implement role checking? Through ejb-security or JBossAuthorizationHandler? CGJ -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von jcurt Gesendet: Dienstag, 3. Februar 2004 02:57 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] [JBoss.net] - JBoss.net HTTP Basic Authentication problem View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3819987#3819987 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3819987 I'm seeing unexpected behavior when accessing a secured JBoss.net web service. The web service is configured to require HTTP Basic Authentication. Here are the 3 cases, the third one is the problem: 1. If the SOAP/HTTP request contains a valid username/password (i.e. Authentication header field is set to a valid username+password) then the service can be accessed as expected. 2. If the request contains an incorrect username/password (i.e. Authentication header field set, but invalid username and/or password), then the server returns 401 Unauthorized as expected. 3. If the request does not contain an Authentication header field entry, the server returns 500 Internal Server Error. In this case, the server should return 401 Unauthorized so the client's HTTP layer knows that it needs to obtain authorization information (i.e. prompt user for a username password). As it is, the client has no idea how to deal with the error. I have verified this behavior using a TCP Monitor. Also, I have verified that web applications on JBoss do NOT exhibit this behavior, i.e. they behave as expected in case #3 when accessing a secured html or jsp page. I am using server version: jboss 3.2.1 w/tomcat 4.1.24 Has anyone else dealt with this? Thanks, -Curt --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Cvs head build error
Shame on me and incremental recompilation through Eclipse! Sorry, CGJ -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Scott M Stark Gesendet: Freitag, 30. Januar 2004 21:43 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] Cvs head build error I fixed it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Wang Sent: Friday, January 30, 2004 10:36 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Cvs head build error Hi, I just did a fresh check out (from jboss-head). Here is the build error I got in jboss.net. Thanks, -Ben compile-classes: [javac] Compiling 12 source files to E:\cvsroot\jboss-head\jboss.net\output\classes\main [javac] E:\cvsroot\jboss-head\jboss.net\src\main\org\jboss\net\ws4ee\metadata\We bservices.java:81: unreported exception javax.xml.transform.TransformerException; must be caught or declared to be thrown [javac] new WebserviceDescription((Node) allDescriptions.get( --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] WSDL generation broken in =3.2.2?
Marek,
How does the wsdl look like under 3.0.6 or 3.2.1?
There is indeed some jboss.net specific code that builds service meta-data
from the JMX introspection API, but this code should just drive the Axis
WSDL-Emitter (which then generates the seemingly invalid xsd fragment).
CGJ
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Marek
Lange
Gesendet: Donnerstag, 22. Januar 2004 18:41
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] WSDL generation broken in =3.2.2?
We have a problem to migrate from 3.0.6 to 3.2.3 which is related to our
webservices. The webservices are working correctly after the migration.
The problem occurs when we try to access the WSDL (e.g. by using XML-Spy
as client):
Schema error - undefined schema component 'simpleContent' encountered -
expected: (annotation | list | restriction | union)
This is the excerpt of the WSDL:
schema targetNamespace=http://net.jboss.org/jmx;
xmlns=http://www.w3.org/2001/XMLSchema;
import namespace=http://schemas.xmlsoap.org/soap/encoding/; /
simpleType name=ObjectNameType
simpleContent
extension base=xsd:string /
/simpleContent
/simpleType
/schema
The W3C Validator gives the following error:
Invalid per cvc-complex-type.1.2.4: element
{http://www.w3.org/2001/XMLSchema}:simpleContent not allowed here (1) in
element {http://www.w3.org/2001/XMLSchema}:simpleType, expecting
[{http://www.w3.org/2001/XMLSchema}:annotation,{http://www.w3.org/2001/XMLSc
hema}:union,{http://www.w3.org/2001/XMLSchema}:restriction,{http://www.w3.or
g/2001/XMLSchema}:list]:
In JBoss 3.0.6 and 3.2.1 the problem does not exist. Does JBoss generate
a wrong WSDL?
Thanks a million,
-marek
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Playing a part in the JBoss development effort
Get a sourceforge account and subscribe to the mailing-list on the http://www.sourceforge.net/projects/jboss page (there is also the description of how to access the cvs and the list of open tasks). Best, CGJ -Ursprüngliche Nachricht- Von: Meghshyam Jagannath [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 2. Dezember 2003 22:42 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] Playing a part in the JBoss development effort Hi, I've looked at that. But how do I get onto the development list? Is signing onto [EMAIL PROTECTED] enough? How do I know what's the current status of the various projects, where help is required and how to start off (checking out files, etc.)? thanks! Shyam --- Juha Lindfors [EMAIL PROTECTED] wrote: Hello, this more or less describes the process: http://www.jboss.org/index.html?module=htmlop=userdisplayid=developers/joi n -- Juha __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] AW: Security in JBoss.net
x-posting to jboss-dev/scott in order to get the community/security specialists up-to-date. -Ursprüngliche Nachricht- Von: Jason Essington [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 2. Dezember 2003 01:08 An: Dr.Christoph Jung; Thomas Diesler Betreff: Security in JBoss.net Hi Christoph, Thomas I have looked over the Web Services Security specs available from OASIS (funny, dims just committed them to the specs directory of the wss4j project today). Yeah, it is an important, but quite complicated topic with all these encryption/signing/key-sharing bits. I recently saw a presentation by BEA on WSS and was impressed by the sheer space of possibilities (like, encrypting only an important piece of a web-service call or signing a whole message). It looks like security can be added to JBoss.net on a per-service basis by simply adding the handlers (i'll have to write jboss specific ones) to the requestFlow and responseFlow sections of the service definition in the web-service.xml file. Great. Because we will map the new WS4EE descriptors onto basic Axis ones, we can simply extend the security capabilities to WS4EE, too (the WS4EE handler bit is what I am working on today: I want to have both standard preconfigured handler configurations as well as custom ones, similar to the jboss container configuration). Then enabling security would be as simple as adding something like /* * @jboss-net.security * action=encrypt_sign * more=parameters here */ Yup, I'll have to fiddle with the xDoclet module a little, but I'm no stranger to that. Sounds very good. I´m also thinking about writing a few J2EE1.4 extensions for the xdoclet ejb and web modules. The UsernameToken profile will easily map to the jaas style security used by JBoss, you can have a look at the existing authentication and authorization handlers which are connected (via SimplePrincipal) to a JBoss JAAS Security manager. If you can take those to a new level, that would be great. but X.509 Certificate Tokens Profile will present a bit of a problem I think. An X.509 cert is both an identifier (username) and a credential (password). Any Ideas on how best to map an X.509 Certificate to a JBoss principal? Maybe map the DN to a username? And use the cert serial number as a password, just to map to a user that has defined roles (since a keystore has no concept of roles)? Would be a Principal/Credential combination? That is something that we may have to check with other servers, too. I think that BEA has a quite elaborate notion of keystore and I guess that we would need that for some of the Wss4j, too. CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] WebServer: howto obtain the host and port generic ally
-Ursprüngliche Nachricht- Von: Thomas Diesler [mailto:[EMAIL PROTECTED] Gesendet: Montag, 24. November 2003 15:12 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] WebServer: howto obtain the host and port generically Hallo Christoph, do we realy? In case of JSR109 is it not just a matter of feeding back the user suplied WSDL in webservices.xml? Yeah, but with adjusting all the port component addresses. You see, the general architecture of axis/jboss.net is like many transports hitting the same engine/service endpoint Transport1 (http, context http://localhost:8080/jboss-net/services/*) Transport2 (http, context http://localhost:8080/ws4eesimple/HelloPortComponentEJB) Transport2 (https, whatever context) Transport3 (smtp) ... Transportn (JMS or whatever) - AxisService/AxisEngine --- Service-Endpoint where the transports are a) configurable by the default axis-config.xml and (Transport1, Transport3 ... Transportn) b) setup dynamically in case of WAR-based WS (Transport2 for example) So each service is available under several addresses. It is quite easy to maintain the list of a) transports in AxisService. It should be also possible to register the b) contexts in the ws4ee meta-data. How can you define (in the spirit of JSR109) webservices that spawn ofer more than one endpoint? Sorry, my terminology was wrong. A ws4ee webservice consists of course of several port-components each of which has several addresses following above considerations. CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] WebServer: howto obtain the host and port generic ally
That is what the dynamic wsdl generation facilities of Axis/Jboss.net use and what I was thinking about initially, too. Hoever, you should consider that the wsdl file will spawn over several web services (ejb+war) only one of them is hit over a particular transport (and hence msgcontext properties) and you would have to adjust the other entries (for which you have no transport information) as well to get a valid wsdl ... CGJ -Ursprüngliche Nachricht- Von: Thomas Diesler [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 22. November 2003 17:33 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] WebServer: howto obtain the host and port generically It is much simpler than that, with RPCProvider.generateWSDL you get a MessageContext that actually contains all the info we need to do the mapping. It contains a (large) bag of random things - axis comment: 'in case somebody needs it'. I thought, I share this one :-) -thomas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jung , Dr. Christoph Sent: Freitag, 21. November 2003 10:38 To: '[EMAIL PROTECTED]' Subject: AW: [JBoss-dev] WebServer: howto obtain the host and port generically Hi, -Ursprüngliche Nachricht- Von: Thomas Diesler (E-mail) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 21. November 2003 10:13 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] WebServer: howto obtain the host and port generically Hi all, during webservice deployment the WSDL file may specify a dummy port location. When feeding back the deployed WSDL I would like to (must) tweak the port location such that it reflects the actual URL the webservice is available at. You may want to have a look at the servlet spec/implementation. From its initialisation on, any servlet (including our jboss.net transport servlets org.jboss.net.axis.server.AxisServiceServlet and org.jboss.net.ws4ee.server.WebInvokerServlet) has access to its javax.servlet.ServletConfig and hence its javax.servlet.ServletContext which, to my knowledge, will provide these bits of information. Since AxisServiceServlet is quasi-static to the webservice deployments, registering such data centrally (like in the org.jboss.net.axis.service.AxisService indexed with a transport protocol id http or so) should not be a problem. When it comes to the WebInvokerServlets, this could be a problem of the start order since servlet.init(config) will be called after JSR109Deployer.start() ... maybe we should implement the patching lazily such that the servlets register in the ServiceImplBean upon init(), but WSDL patching is not done until all related deployments have been started and the first WSDL request is done? CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] WebServer: howto obtain the host and port generic ally
Hi, -Ursprüngliche Nachricht- Von: Thomas Diesler (E-mail) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 21. November 2003 10:13 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] WebServer: howto obtain the host and port generically Hi all, during webservice deployment the WSDL file may specify a dummy port location. When feeding back the deployed WSDL I would like to (must) tweak the port location such that it reflects the actual URL the webservice is available at. You may want to have a look at the servlet spec/implementation. From its initialisation on, any servlet (including our jboss.net transport servlets org.jboss.net.axis.server.AxisServiceServlet and org.jboss.net.ws4ee.server.WebInvokerServlet) has access to its javax.servlet.ServletConfig and hence its javax.servlet.ServletContext which, to my knowledge, will provide these bits of information. Since AxisServiceServlet is quasi-static to the webservice deployments, registering such data centrally (like in the org.jboss.net.axis.service.AxisService indexed with a transport protocol id http or so) should not be a problem. When it comes to the WebInvokerServlets, this could be a problem of the start order since servlet.init(config) will be called after JSR109Deployer.start() ... maybe we should implement the patching lazily such that the servlets register in the ServiceImplBean upon init(), but WSDL patching is not done until all related deployments have been started and the first WSDL request is done? CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Sharing classes between WebContainer and JSR109Deployer *was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
-Ursprüngliche Nachricht-
Von: Scott M Stark [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 20. November 2003 15:34
An: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Re: deployment classloader in
AbstractWebContainer
The deployment localCl is only for finding resources, not
classes. The classes class loader is created/assigned by the
MainDeployer after init as this may be the class loader from
an encompassing deployment (ear). Class loading should not be
occurring until create.
All right. I changed the ws4ee classloading to use the subdeployment ucl
(which is indeed
equal to the parent [EJB,WAR] ucl, see DeploymentInfo(parent,...)).
Thanks to your hint, the observed inconsistencies in the EJB case thus went
away.
However, we still have the problem that bytecode from WEB-INF/classes and
WEB-INF/lib (which is referenced in the
webservice.xml, e.g., by defining a service endpoint interface, and needs to
be loaded by JSR109Service.start(...))
- either will never find its way into the war-ucl (tomcats
useJbossClassloader=no option)
- or wont be inserted until
AbstractWebContainer.start(...)-performDeploy(...) is executed
(which comes AFTER JSR109Service.start(...) due to ws4ee being a
subdeployment to the war).
The current workaround in JSR109Service.start(...) (which I know is
certainly conflicting with the idea of allowing scoped war classloading in
general) is to simply inject these urls into the war-ucl before trying to
load bytecode:
//TODO CGJ: we need to share classes between a war and its
//webservice-subdeployment. We do that, similar to the EJB case,
//by the dis sharing the ucl. However, we need to hence extend
the
//ucl with web-inf/classes and lib at this point.
//This somehow conflicts with the notion of jboss-decoupled
//classloading for which I would propose to add another
//slot into DeploymentInfo that carries the
//final Classloader applicationClassLoader as used by the
//individual containers and that should be constructed at
//initialisation time (or is equivalent to ucl per default).
URL warURL = sdi.parent.localUrl != null ? sdi.parent.localUrl :
sdi.parent.url;
String warPath=warURL.getFile();
try{
File classesDir = new File(warPath, WEB-INF/classes);
if (classesDir.exists())
sdi.parent.ucl.addURL(classesDir.toURL());
File libDir = new File(warPath, WEB-INF/lib);
if (libDir.exists())
{
File[] jars = libDir.listFiles();
int length = jars != null ? jars.length : 0;
for (int j = 0; j length; j++)
sdi.parent.ucl.addURL(jars[j].toURL());
}
} catch(MalformedURLException e) {
throw new DeploymentException(Could not extend ws4ee
deployment ucl.,e);
}
As a better solution which bundles the knowledge about war structure in a
central place and which is consistent with the existing classloading
options, I would propose to extend DeploymentInfo with another ClassLoader
applicationLoader; which could be equal to ucl per default, but which would
be set to the actual WebCtxLoader in the Tomcat case or a similar construct
for other web containers already during AbstractWebContainer.init(...)
calling a new ConcreteWebContainer.constructWebLoader(...) method. This
applicationLoader could then be consistently used by JSR109Service to load
shared classes.
What do you think?
CGJ
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
-Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 20. November 2003 15:34 An: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Betreff: [JBoss-dev] Re: deployment classloader in AbstractWebContainer The deployment localCl is only for finding resources, not classes. The classes class loader is created/assigned by the MainDeployer after init as this may be the class loader from an encompassing deployment (ear). Class loading should not be occurring until create. Ahhh. ... that is the ucl then? Guess that ignoring this relation and basing too much on the localCl was my fault. I think I know what to do ... I will care for it, Thomas. CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JNDI binding for J2EE1.4 compliant webservices
-Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 20. November 2003 16:07 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] JNDI binding for J2EE1.4 compliant webservices I agree with that, so what is the confusion? From my reading, I was seeing the relation between server and client programming more analogously to the existing EJB/J2EE specification bits. I was proposing to bind the service references into (global) JNDI by the JSR109Deployer regardless of whether a client app is present (as we do with the ejb stubs). The JSR109ClientDeployer would then only live in client processes and just dealing with generating link-refs into the local client JNDI. Furthermore, there is IMHO the possibility (requirement) to use service-endpoint references in the server programming model just as ejb-ref and servlet-ref. CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] AW: JBoss.NET: web service components as web module
Hi Thomas, I´m just about to commit a pragmatic solution to that issue (need only to get the testcase running ;-). Since we have the JSR109 sub-deployment solution, we have access to the parent deployment info including the local installation dir of the war. JSR109Service (or better the WebService metadata) will, upon the create step, replace any occurence of a web-service-servlet by our AxisServiceServlet tied to the AxisService/AxisServer where the POJO is installed as an ordinary service. (#1 - is then not a problem anymore, only in cases where JSR109 is not present ... But then, the webservices wont work anyway). #3 - The servlet/service context will be compiled into the MessageContext, anyway. Is there any place in the spec where this plays a role in the JavaBean? I do not know what question #2 is targetting at? CGJ -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Montag, 17. November 2003 17:15 An: Jung Christoph (E-mail); Stark Scott (E-mail); Bill Burke (E-mail) Cc: Jboss-Development (E-mail) Betreff: JBoss.NET: web service components as web module Hi folks, J2EE1.4 compliant webservices can be implemented as web components. First I'll tell you briefly how it works then I'll come to some JBoss specific design issues/problems. This is how it works: 1. In webservices.xml specify a servlet-link MyService /servlet-link 2. In web.xml use servlet-name MyService /servlet-name 3. In web.xml use servlet-class com.mypackage.MyServiceBean /servlet-class to name the service endpoint implementation bean So far so good, but com.mypackage.MyServiceBean can be any ordinary POJO - it does not have to be javax.servlet.Servlet. Issues -- #1 How should the servlet container behave when servlet-class is not a servlet #2 If the SE bean is a servlet, is there any way to invoke a method (the actual service method) on it - the org.jboss.web.AbstractWebContainer does not provide a list of deployed (servlet) objects #3 I think we need the above mentioned access, in case the service method needs access to the ServletContext or ServletConfig parameters The current (draft) implementation creates a new service bean for every request, regardless wether it is a servlet or not. Cheers -thomas ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: AW: [JBoss-dev] 3.2.3RC1
Ok, you owe me a beer ;-) CGJ -Ursprüngliche Nachricht- Von: Bernd Koecke [mailto:[EMAIL PROTECTED] Gesendet: Montag, 17. November 2003 17:23 An: [EMAIL PROTECTED] Betreff: Re: AW: [JBoss-dev] 3.2.3RC1 Thanks a lot to Christoph Jung! I checked the redeploy problem of Axis Webservices and all works fine with 3.2.3RC1. Bernd Scott M Stark wrote: If the changes are in by Friday then they will be in the release. -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JNDI lookup problem with webservice client
Thomas, Another possibility of binding webservices into JNDI is using references and an associated ServiceFactory (see the behaviour of external web service references in jboss.net). With that approach, you have more control about the serialisation process, classloading issues and engine affiliations. CGJ -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 11. November 2003 21:27 An: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Betreff: [JBoss-dev] JNDI lookup problem with webservice client Scott, working on the webservice client programing model, I need to bind a javax.xml.rpc.Service to JNDI. In the test below I bind it to the global JNDI namespace. However, when I lookup the service I get null without a NamingException. The code below first tests if the service object can be serialized without JNDI involvement, then it tests if bind/lookup of a trival string object works. Finally the actual service is bound (I can see it in jmx-console) and then looked up again. The last assertion fails. Any idea? cheers -thomas -- String SERVICE_JNDI_NAME = service/HelloWsService1; Service service = new org.apache.axis.client.Service(); // first try to marshal/unmarshal the service without JNDI ByteArrayOutputStream baos = new ByteArrayOutputStream(1024); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(service); oos.close(); ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray()); ObjectInputStream ois = new ObjectInputStream(bais); service = (Service)ois.readObject(); assertNotNull(cannot serialize service, service); // test JNDI lookup with a trivial String InitialContext iniCtx = getInitialContext(); Util.bind(iniCtx, SERVICE_JNDI_NAME, Test JNDI); assertEquals(Test JNDI, iniCtx.lookup(SERVICE_JNDI_NAME)); Util.unbind(iniCtx, SERVICE_JNDI_NAME); service = new org.apache.axis.client.Service(); // now do the actual binding and lookup Util.bind(iniCtx, SERVICE_JNDI_NAME, service); service = (Service)iniCtx.lookup(SERVICE_JNDI_NAME); assertNotNull (cannot lookup service, service); Util.unbind(iniCtx, SERVICE_JNDI_NAME); --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Q: Testsuite] Howto temporarily reconfigure the other security domain
Hi (Scott)! On my way for integrating the yet isolated jboss.net testsuite into the global testsuite, I ran into a particular question: Some (server-side) security features of jboss.net/uddi can only be tested when being provided with some reasonable demo authentication data in the associated other domain. So far, I manually copied dedicated user.properties and roles.properties into the jboss dist (which is configured with an empty other domain). This is not an option for the automated global testsuite anymore. Ive seen some functions in the JBossTestServices to flush the domain, but have no idea how to configure it for using the demo properties just for a particular test case. Should they be copied and moved by the build.xml? Any hints are welcome ... CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] 3.2.3RC1
There were two fixes related to axis classloading and discovery that need to be backported. What is your timeframe? I could submit the stuff on Friday. CU, CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 5. November 2003 16:24 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] 3.2.3RC1 I'm putting together a 3.2.3RC1 release to pickup some recent bug fixes. I'm working on a fix for [ 832561 ] NoSuchMethodException when HAJNDI joins cluster that I want to include. If there are any other must have fixes let me know. -- Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] 3.2.3RC1
-Ursprüngliche Nachricht- Von: Bernd Koecke [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 6. November 2003 09:43 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] 3.2.3RC1 Hi, Christoph Jung made a bugfix for the redeploy bug of webservices. But he made it for JBoss 4. Will it be also present in 3.2.3RC1? Yes, it is now in branch_3_2 Scott, since jboss-net should still be optional in 3.2 (in order to keep backport issues to a minimum), would you mind me deleting the testsuite/webservice stuff after I have integrated it into head? CU, CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBoss Group forks again.
Such a sweety. Congrats and AMSAP (as many sleep as possible ;-). CU, CGJ -Ursprüngliche Nachricht- Von: Bill Burke [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 26. Oktober 2003 18:46 An: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Betreff: [JBoss-dev] JBoss Group forks again. October 26th. 12:36 AM. Proud dad and mom doing fine. http://www.jboss.org/bill/burke/baby.jpg Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: AW: [JBoss-dev] 3.2.2 Issues to resolve
Bernd, There is nothing pathological about your package structure/meta-data. You could do me a facor and send the complete ear to mailto:[EMAIL PROTECTED] in order to quickly reproduce the problem. CU, CGJ -Ursprüngliche Nachricht- Von: Bernd Koecke [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 15. Oktober 2003 12:35 An: [EMAIL PROTECTED] Betreff: Re: AW: [JBoss-dev] 3.2.2 Issues to resolve Hi Christoph, I have an ear-file with some ejb-jars, war-file and one wsr-file. The included webservice is used by one of the EJBs. When I deploy my ear all works fine. All services are available. When I undeploy and deploy the ear again, all services are working, but the webservice can't be found. There are no errors, warnings etc. in server.log at deployment/redeployment, even if I switch level to debug. This happens only when I access the ws after deployment. Without using the webservice I could redeploy several times. But after the first usage and a following redeploy, I have to restart JBoss, otherwise the redeployed ws can't be found by the naming service. Attached are the dds from ear and the dds from the ejb with the webservice (bankchecker-app-net-0.2.0.wsr, bankchecker-app-ejb-0.2.0.jar) and a stacktrace of the NameNotFound- and NullPointerException. I have a small additional problem, maybe with the same reason. I can't set the JNDI-Path in web-service.xml to ws/BankChecker-v0_3_1 or ws/v0_3_1/BankChecker. Axis says at deployment that ws is not bound. Please send me a mail, when I missed something. Thanks a lot, Bernd Jung , Dr. Christoph wrote: Bernd, Could you please resend the symptoms(wsr content, dd, detailed steps you undertake, stacktrace ...) such that I can check whether it is a bug or a config error? CU, CGJ -Ursprüngliche Nachricht- Von: Bernd Koecke [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 14. Oktober 2003 10:21 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] 3.2.2 Issues to resolve Hi, I have a problem with redeployment of a webservice in a wsr-file. Thread on jboss-user: [JBoss-user] Redeploy problem of webservices on JBoss 3.2.2 I'm not sure if it is a bug or a config error. Webservices are not a core requirement of Spec 1.3. So I don't know if, in case of a bug, the solution should go into 3.2.2. But till now I don't have a solution. The newest version I tried was the snapshot from last night. Bernd Scott M Stark wrote: All but 786668 have been addressed and the 3.2 branch is being tagged with JBoss_3_2_2. I will complete the final testing tonight and do the release barring any major issues. -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] 3.2.2 Issues to resolve
Bernd, Could you please resend the symptoms(wsr content, dd, detailed steps you undertake, stacktrace ...) such that I can check whether it is a bug or a config error? CU, CGJ -Ursprüngliche Nachricht- Von: Bernd Koecke [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 14. Oktober 2003 10:21 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] 3.2.2 Issues to resolve Hi, I have a problem with redeployment of a webservice in a wsr-file. Thread on jboss-user: [JBoss-user] Redeploy problem of webservices on JBoss 3.2.2 I'm not sure if it is a bug or a config error. Webservices are not a core requirement of Spec 1.3. So I don't know if, in case of a bug, the solution should go into 3.2.2. But till now I don't have a solution. The newest version I tried was the snapshot from last night. Bernd Scott M Stark wrote: All but 786668 have been addressed and the 3.2 branch is being tagged with JBoss_3_2_2. I will complete the final testing tonight and do the release barring any major issues. -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss.NET] revised schedule, seeking for volunteers *was* RE: [JBoss-dev] 4.0 rollback 1st phase complete
Ivelin ( others), Wrt the rollback and how this will affect JB.net, Anil, Bill and me came to the conclusion that the 3.2 code [that already builds upon Axis1.1Final] would be a sufficient base for the next 4 weeks [in which I am on baby holiday and most likely neither online nor sitting on a computer anyway ;-] Hence I do not want to turn your current attention from where it is needed now. From my experiences, most people currently work on a combination of the 3.2 runtime and the head xdoclet module. Thanks to Neal Sanche, there is a compiled version available at http://www.nsdev.org/jboss/stories/xdoclet-module-jboss-net.jar (not to forget his valuable walkthrough at http://www.nsdev.org/jboss/stories/jboss-net.html). Anil who is now the co-lead would then have a look at porting the UDDI server and driving the JAXR interfaces forward; I would care about reimplementing the WS4EE spec [since the legacy 4.0 version builds upon too much deployment code that has definitely faded - especially the xsl deployer which was introducing too much runtime/configuration instabilities]. Nevertheless we need to broaden the team to reach the overall vision of making JBoss.net a nexus of interoperability in JBoss4 which is a good opportunity for developers to get aquainted to web services technology (in the order of priority): - We could need someone integrating the still separate junit tests of jb.net (we were an optional module in 3.2!) with the overall testsuite. - We could need someone looking at the xdoclet module (there is a JSR on Web Service Metadata pending for which I saw a sneak preview by BEA somewhere ... if we could manage to use these doclet tags as the basis of a WS4EE-xdoclet module, that would be of tremendous usefulness IMHO). - Someone should specialize in making JMX-based web services as comfortable as possible. - Someone should specialize in EJB-based web services and drive forward the existing provider code. - We need an interface to the messaging and remoting modules in order to remove code redundancies. - We need a M$.NET specialist in order to address interoperability issues with C#,VB, etc-Clients. Same holds for Macromedia Flash and JAXRPC4ME. - Someone should get deep knowledge in WS-Security with all its signing, encryption, etc bits and improve the existing connection between JB.Net Security handlers and the jboss security architecture in that direction. - We could need someone having a look at the rolled back smtp/saaj support. These are IMHO extremely fascinating topics for tech-heads and will be highly requested by employers in the next years. Please refer to jboss-devel/anil if you have interest. I´ll send a notice (with a baby picture ;-) when I´m back (and unbelievably keen on doing computing again ;-) Best, CGJ -Original Message- From: Ivelin Ivanov [SMTP:[EMAIL PROTECTED] Sent: Donnerstag, 28. August 2003 19:24 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] 4.0 rollback 1st phase complete Bill, All my recent commits were in Branch_3_2. Do I need to do something to merge them into HEAD or you already did that? How can I help with the web services work? Where to start? ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBoss.net::WSDL to UDDI Converter added to JBoss
Anil, This is great work. It will enable us to finally attach the deployment process automatically to uddi registration! Cool, CGJ -Ursprüngliche Nachricht- Von: Anil Saldhana [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 24. Juli 2003 06:17 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] JBoss.net::WSDL to UDDI Converter added to JBoss Hello All, I have just committed a java file WSDL2UDDIConverter and a testcase StoreUddiUnitTestCase.java. These enable users to provide the url location of a WSDL service and it is deployed in the integrated local jUDDI registry. It uses the open source UDDI4J/WSDL4J Api. This is my first commit. So if there are any mistakes from my side, please forgive me. Thanks to Bill and Dr.Jung for the support/motivation provided. I also thank Scott for RW access and Peter Braswell for the cooperative/informative IM chats. Cheers, Anil __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet _072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Ann] [JBoss.net] Axis 1.1 final in *head*
subject says it all. In addition, jws file support (web service code that is compiled on the fly, similar to jsps) has been enabled in the default conf. CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] jboss-head/testsuite/build has 100 errors for me
Have you checked that all relevant thirdparty modules have been obtained through cvs? BTW: I got no jdo.jar on my workspace either ... Must be some recent addition, I guess. sun-jdo? CGJ -Ursprüngliche Nachricht- Von: Anil Saldhana [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 17. Juni 2003 15:51 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] jboss-head/testsuite/build has 100 errors for me Hello developers, I tried to build the main testcases using jboss-head/testsuite/build I hit 100 compilation errors Some of them are: [javac] /home/saldhana/JBOSSDev/jboss-head/testsuite/src/main/org/jbos s/test/cmp/jbossdo/collection/CollectionUnitTestCase.java:14: package javax.jdo does not exist [javac] import javax.jdo.PersistenceManagerFactory; [javac] /home/saldhana/JBOSSDev/jboss-head/testsuite/src/main/org/jbos s/test/cmp/jbossdo/util/JDOTestCase.java:120: cannot resolve symbol [javac] symbol : variable JDOHelper [javac] location: class org.jboss.test.cmp.jbossdo.util.JDOTestCase [javac] assertTrue(JDOHelper.isDeleted(pc), JDOHelper.isDeleted(pc)) Any suggestions? Have I not brought over the code? Do I need to do something before I build the testsuite? Regards, Anil __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] AW: How to run testcases in jboss.net UDDI Related
Hi Anil, Sorry for not answering earlier. Needed to do some in-house priority 1 support. -Ursprüngliche Nachricht- Von: Anil Saldhana [mailto:[EMAIL PROTECTED] Gesendet: Montag, 2. Juni 2003 06:49 An: christoph Betreff: UDDI Related Dr.CGJ, here are some new factoids after my research - basically search and search and no coding. 1) JUDDI developers are saying that JAXR will work with them if we use the Java WS Dev Pack version from Sun. Also JUDDI has identified some bugs wrt JAXR support. I am not sure what the timeline will be from JUDDI to deliver a jaxr compliant jUDDI. I have posted a question to them. 2) Here is my idea: Users will provide JBoss with the following config data: a) Name of the Web Service. b) Inquiry.URL c) publish.URL plus username/password d) Name of Business. e) Description f) Contact They can also give the publish.url of the internal JBoss UDDI server(if they do not want external one). The username/password is used to get the Authentication Token. The user will enter these for each web service. Can you suggest a good location in jboss.net to allow the user to place this config data? I could not find a config file for this. If I have to create a new config file, please suggest a name and location... I would tend to extend the web-service.xml (wsdd) for that purpose. As with all deployment descriptors it becomes more and more common use to embed tags of a different namespace describing these extensions such that they are close to the data that they descorate. Your suggestions wrt the structure of that data sound very good. Except perhaps username/password (I am no JBoss security expert, but it would be fantastic in the end, if the deployment itself could be signed and identified such that we could publish the stuff Using the credentials of the deployed package/its creator!). But I guess we need to do that until we have such a solution. BTW, reading through the WSDL-UDDI document (I sent the link to you) it came to my mind, that we maybe should separate (also in the descriptors) the issues of registering -business/category -service interface (WSDL) -and concrete location of a service with a link to WSDL The web-service.xml should have different elements for these things with links between, such that they can be individually setup and looked up. For example, it could be possible to just Publish the location of the just deployed service in an already registered business with an already specified interface. The jboss.net tests are not part of the official testsuite (historical issue, we became default not until JBoss4DR1). You can run them with jboss.net/testsuite/build.bat Some of them (Security and External Webservices) will not succeed until you have configured JBoss with appropriate user.properties, role.properties, appropriate system properties for proxy settings for outbound http if you are behind a firewall, and a system property containing a valid google key. Best, CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JB4DR1 Deadline MAY 26
Until 26th of May, I will have a version of W2EE deployment ready (at least the subset of the webservices.xml and jaxrpc-mapping.xml that can be easily mapped via a XSL-driven WebServiceDeployer to the existing web-service.xml/AxisService; deployer hooks in EJBDeployer+WARDeployer-WebServiceDeployer must be coordinated with Bill? And Scott?). I will also have catered for a reasonable auto-registration of web service wsdl in uddi until then. I cannot guarantuee Xdoclet support to generate J2EE1.4 webservices.xml and JAXRPC mappings. Maybe there will be a volunteer for this (one of the xpetstore guys was interested in trying that out?). Maybe the xdoclet team will have something in that direction anyway ... I would delay all web service extensions of JCA and JMS (just a guess from a quick look into the draft) and the tighter integration of the Axis and Jboss invocation stacks then after JB4DR1. CGJ -Ursprüngliche Nachricht- Von: Bill Burke [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 4. April 2003 00:28 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 JBoss Remoting AOP + tx, security, versioning, remoting, clustering, txlock, caching DTM (waiting on David's response) EMB (Enterprise Media Beans) JUDDI integration If I can get it done: AOP + EJB (packaged extensions to EJB) and don't forget Nukes! Anybody got anything to add to this list? Who doesn't think they'll be done by May 5th? Who thinks they'll be cutting it close? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Thursday, April 03, 2003 4:48 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 Ok then there are 4 weeks to get the new stuff done? Marc, Bill, sure we could do a release but what difference would it make if the new features are not in it. Is this a release just to show off AOP? What about any of the other new stuff? Just give the users a solid 3.2 and they will be happy. -dain On Thursday, April 3, 2003, at 03:30 PM, Bill Burke wrote: It will be ready and stable. Functionality freeze is May 5th. What functionality doesn't make it by then will be left out of the release. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Thursday, April 03, 2003 4:01 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 I think you are delusional if you think JB4 will be ready for JavaOne. -dain On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: Guys, We are thinking a lot about the forthcoming JB4 release. It is a truly exciting step for us as we believe we will bring a programming style, whose time has come, to a mass audience. AOP as Bill says is a clear wave for system level services on par with OOP. On top of it and also as a proof of how powerful the approach is we still develop a full J2EE server. Meaning that you can choose to live in the J2EE world work on JBoss J2EE and access all the prepackaged AOP goodies as you have been doing since JBoss2.0. There seems to be a lot of fear at SUN from what I can tell in the press, that we will abandon J2EE. We love J2EE. When really we will support J2EE for the forthcoming future. Never do we talk about abandoning J2EE, we just let the user access core functionality in the open server and think at the AOP level. A more fundamental construct of the framework. The reason we are almost there is that it is also a very old implementation in JBoss. We have been doing it for a long time but never talked/packaged it this way. We make it easy for you to leverage the AOP layer. The implementation is old the way you interact with JBoss is new. It can also be old if you decide to stay at the J2EE level which will be fully supported. But you are now invited to roam in the core JBoss system, in fact you may find it very cozy as you port POJO based applications to JBoss. There will be a stabilization period though. We are making an aggressive push to release JB4 by JavaONE with all our resources dedicated to implementing the final AOP system aspects and porting some of the existing code to that. We're making an aggressive push to release JBoss 4.0 by JavaOne. We're targeting May 26th. That leaves us 2 month from now. I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH To meet this aggressive deadline, we need to set some dates. There will be a functionality freeze, Monday, May 5th. All new functionality commits after May 5th must be approved by either Scott Stark, or Bill Burke. We will not branch May 5th, but instead make the month of May, JBoss 4.0 stability en route to a Developpers Release 1 (DR1). Please think long and hard and fast about your modules. Many of you are
AW: [JBoss-dev] JDT compiler was: php5 is coming
Phil, others,
There is even a more official batch interface to the eclipse compiler in
the org.eclipse.jdt.core plugin which is much like the original Java
compiler:
package org.eclipse.jdt.internal.compiler.batch;
public class Main implements ProblemSeverities {
public Main(PrintWriter outWriter, PrintWriter errWriter, boolean
systemExitWhenFinished) {
...
}
/*
* Low-level API performing the actual compilation
*/
public boolean compile(String[] argv) {
}
/*
* External API
*/
public static void main(String[] argv) {
}
}
I experimented with it and it seems like this is not dependent on any other
part of eclipse (jdtcore.jar is sufficient) and is working in 90% of the
cases just as javac.
But I also got a few additional warnings (import not used, etc - you know
these from the eclipse task bar) and errors which I do not yet know exactly
where they come from (Lacking -sourcepath? Other -target ?). So maybe this
is just an issue in our environment.
CGJ
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 2. April 2003 03:21
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] JDT compiler was: php5 is coming
JDT stands for Java Development Tools and is a subproject of the Eclipse
framework. I looked through the source a bit and it looks like the main
compiler class is org.eclipse.jdt.internal.compiler.Compiler. I found the
source in my plugins directory of Eclipse (no additional download needed)
under the directory org.eclipse.jdt.source_2.1.0/src in the jdtcoresrc.zip.
The only problem is that this is an internal package which means that
there is neither binary nor api contracts between releases. The Eclipse
project committers seems to tend to try to open the API's to everyone once
they stabilize, so if someone puts a little pressure on them, they might be
willing to move this class out of the internal package.
There is a method in the Compiler class with the signature: public void
compile(ICompilationUnit[] sourceUnits)
This looks like the method that would be most useful. The ICompilationUnit
interface isn't the most basic interface in the world. There are quite a
few methods, but a look through the compiler code may give clues to which
methods are necessary. This interface doesn't really care where your java
code came from so it would definately meet the criteria for an in memory
compiler.
The other obstacle is the constructor to the Compiler class. It requires
quite a few interfaces to be fleshed out. The signature is: public
Compiler(INameEnvironment environment, IErrorHandlingPolicy policy, Map
settings, final ICompilerRequestor requestor, IProblemFactory
problemFactory)
It really doesn't look like this was meant to be used outside of the larger
JDT framework, but might be worth the trouble if other alternatives don't
look so good.
-Phil
Scott M Stark
[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
Sent by: cc:
[EMAIL PROTECTED] Subject:
Re: Re[2]: [JBoss-dev] php5 is coming
ceforge.net
04/01/03 02:04 PM
Please respond to
jboss-development
I don't know what JDT is. It was not I who suggested it. The JDT page says:
http://www.eclipse.org/jdt/index.html
The JDT project provides the tool plug-ins that implement a Java IDE
supporting the development of any Java application, including Eclipse
plug-ins. It adds a Java project nature and Java perspective to the Eclipse
Workbench as well as a number of views, editors, wizards, builders, and code
merging and refactoring tools. The JDT project allows Eclipse to be a
development environment for itself.
Not obviously an in memory compiler, but maybe in there somewhere.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: julien viet [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]
Sent: Tuesday, April 01, 2003 11:45 AM
Subject: Re[2]: [JBoss-dev] php5 is coming
what is supposed to be eclipse JDT ?
SMS So get another compiler. We don't need no stinking JSR.
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
[JBoss-dev] [JBoss.net] Bugfixes and updates in 3.2 and HEAD
Title: Nachricht Hi, before 3.2 final will be built, thefollowing bugs have been addressed in Branch_3_2 and HEAD: Bug#638994 - JBossAuthenticationHandler can now handle null-passwords if the associated SecurityDomain does. Bug#594137 - A special HttpActionHandler has been installed in the default http transport chain that will signal its presence to any passing messagecontext requesting to generate WSDL. This way, supporting providers (such as our EJBProvider and the MBeanProvider) can include the correctSoapAction="ServiceName" annotations depending on the transport through which the wsdl request came through. Bug#708691 - The central Deployment repository has been added additional classloader awareness when trying to obtain the service descriptions for generating the http://localhost:8080/jboss-net/services HTML overview page. Bug#617517 - The MBeanProvider has been reworked. We have removed the nasty string array of classnames that was required as the first parameter of each web service invocation, because it operates on MBeanInformation meta-data anyway.The generated WSDL is now much more straightfoward and correct. Finally I have removed the automatic insertionof transactional handlers for ejb-web services from the xdoclet module. These are only needed, if you like to immediately (de-)serialize entity beans into/from XML elements within the scope of some session bean method. If you would like to retain them, you have to annotate your bean with the @jboss.net:processEntities tag. Please keep on providing valuable feedback to us, CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
AW: [JBoss-dev] jboss.net xdoclet subtask
Are you a mail-list-bot or what? If that is the case, you seem to be able to do useful programming in your sparetime ;-) But your parsing subsystem seems not to cope with non-native English emails ... As written in a separate response to your first of the three equivalent emails a week ago (and as should be apparent from CVS), I removed all that jboss-net specific 1.2 stuff from the 3_2 branch and updated to the official xdoclet stuff. The stuff is used by the jboss.net testsuite (and some web-service end-users out there). CGJ -Ursprüngliche Nachricht- Von: Stephen Coy [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 20. März 2003 23:45 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] jboss.net xdoclet subtask Hi, Is it reasonable to assume that the jboss.net xdoclet subtask that was being worked on nearly a year ago is currently not used in anger anywhere? I can see a couple of flavours of the code (in org.jboss.net.xdoclet and also thirdparty/xdoclet/jboss.net) in Branch_3_2, but I can't see any actual uses of it in build files. Th reason I ask is that I'm currently migrating Branch_3_2 to xdoclet 1.2, and I'm not sure what to do with the jboss.net stuff. Steve Coy --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: AW: [JBoss-dev] jboss.net xdoclet subtask
No prob, I even got it three times. Should have read the dates, but I already disposed the original to which I sent you the first reply ;-) CGJ -Ursprüngliche Nachricht- Von: Stephen Coy [mailto:[EMAIL PROTECTED] Gesendet: Montag, 24. März 2003 11:28 An: [EMAIL PROTECTED] Betreff: Re: AW: [JBoss-dev] jboss.net xdoclet subtask Sorry about that. I sent the message twice, because the first attempt did not show up. If you look at the date of the second one, you will see that it was sent about 8 hours before the first one. It eventually arrived about 28 hours after I sent it. I have no idea what it was doing in the meantime. So, I did see your response - to the second message that arrived first :-) Steve Coy On Monday, March 24, 2003, at 07:45 PM, Jung , Dr. Christoph wrote: Are you a mail-list-bot or what? If that is the case, you seem to be able to do useful programming in your sparetime ;-) But your parsing subsystem seems not to cope with non-native English emails ... As written in a separate response to your first of the three equivalent emails a week ago (and as should be apparent from CVS), I removed all that jboss-net specific 1.2 stuff from the 3_2 branch and updated to the official xdoclet stuff. The stuff is used by the jboss.net testsuite (and some web-service end-users out there). CGJ -Ursprüngliche Nachricht- Von: Stephen Coy [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 20. März 2003 23:45 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] jboss.net xdoclet subtask Hi, Is it reasonable to assume that the jboss.net xdoclet subtask that was being worked on nearly a year ago is currently not used in anger anywhere? I can see a couple of flavours of the code (in org.jboss.net.xdoclet and also thirdparty/xdoclet/jboss.net) in Branch_3_2, but I can't see any actual uses of it in build files. Th reason I ask is that I'm currently migrating Branch_3_2 to xdoclet 1.2, and I'm not sure what to do with the jboss.net stuff. Steve Coy --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] jboss.net xdoclet subtask
I will cater for backporting the jboss.net 1.2 module into the 3.2 branch. It is used (in CVS) in the jboss.net testsuite which is still decoupled from the main testsuite as long as J2EE1.4 is not mandatory. CGJ -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 21. März 2003 13:46 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] jboss.net xdoclet subtask At least the copy in HEAD is actually for xdoclet 1.2. When I migrated HEAD to xdoclet 1.2 I basically ignored the jboss.net xdoclet task. I'd say if the testsuite is OK, it is safe to ignore and let the jboss.net folks fix if there is a problem later. thanks david jencks On 2003.03.20 17:44 Stephen Coy wrote: Hi, Is it reasonable to assume that the jboss.net xdoclet subtask that was being worked on nearly a year ago is currently not used in anger anywhere? I can see a couple of flavours of the code (in org.jboss.net.xdoclet and also thirdparty/xdoclet/jboss.net) in Branch_3_2, but I can't see any actual uses of it in build files. Th reason I ask is that I'm currently migrating Branch_3_2 to xdoclet 1.2, and I'm not sure what to do with the jboss.net stuff. Steve Coy --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jboss.net Xdoclet1.2 module now in 3.2 branch *was* AW: [JBoss-dev] Branch_3_2 has been updated to xdoclet 1.2
Hi, Stephens noteworthy effort finally triggered me to backport the current jboss.net xdoclet facilities from HEAD to the 3.2 branch (and to fix the bloody view-type=both problem). Best, CGJ -Ursprüngliche Nachricht- Von: Stephen Coy [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 21. März 2003 15:04 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Branch_3_2 has been updated to xdoclet 1.2 I've updated the build.xml files to use xdoclet 1.2 (pre b3). It has the same jars as HEAD, although with correspondingly different names. I suspect that we should change these at some point to include version info like a lot of the other jars. i will tackle Branch_3_0 next, unless anyone has objections. Note that this means an ant upgrade to 1.5.x is required. Steve Coy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss.net] allowedMethods=* EJBProvider WSDL-Bug resolved in 3.2 and Head *was* AW: [JBoss-user] Remote Beans as Web Services
Title: Nachricht Hi, thanks to Mark and Kevin, we could now trace that the WSDL-Emitter driver code in the Axis1.1 EJBProvider is flawed. It has the "stopClasses" meta-attribute not set such thatthe wsdl generator also tries to build wsdl descriptions formethods declared in EJB interfaces (and produces a lot of namespace-exceptions since the datatypes used there are not Web Service compatible). JBoss.net EJBProvider now has the stopClasses set, again, and should produce more reasonable WSDL-output (provided that your exposed business methods/datatypes are mapped accordingly). Thishas been fixed in head and 3.2 CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
[JBoss-dev] FYI [JBoss.net]: Integrated Uddi Server submitted into HEAD
Hi, I just submitted another step towards J2EE1.4 Web Service compliance. The jboss-net.sar now additionally hosts a uddi-v2 compliant server (currently jUddi0.6.2). It is published upon startup as a web service itself (currently running under http://hostname/axis/services/uddi) via the already existant SOAP/Axis transport layer (now upgraded to Axis1.1 RC1) of JBoss.net The uddi server is secured by a configurable Jboss security domain (java:/jaas/other) and backed by any jdbc data source (java:/DefaultDS). Please make sure that, on order to build jboss.net, you need to update your thirdparties (juddi/juddi/lib/juddi.jar) Next steps are - automatic registration of web services deployed through jboss.net including their wsdl-representation in UDDI. - XSLSubDeployer that maps the new web service descriptor format of J2EE1.4 onto JBoss.net/Axis wsdd. - deployment delegation from EJBDeployer and WarDeployer into the AxisDeployer (the spec is extremely dumb in that respect, but the hooks are already there, so we do this for compliance purposes). - support of jaxrpc mapping descriptors. - support for JCA extensions related to web services. - smarter integration with the invocation stack such that axis handler operations (especially de/-serialialisation) can be moved into the EJB layer (transactions, security, etc.) If anyone is interested in helping with these things (even in reading the extremely boring specifications and explaining them to me ;-), please yell! Best, CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Chris,
The original build problem was indeed caused by my submission in two stages
(the libraries.ent was in the latter stage).
Could you please check that you have the thirdparty/juddi-juddi module on
the build machine?
Thx,
CGJ
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 13. März 2003 18:03
An: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Betreff: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.1_01
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java
HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
location: class org.jboss.net.uddi.server.UddiService
DataStoreFactory factory = DataStoreFactory.getInstance();
^
/home/jboss/jbossci/jboss-head/jboss.net/src/main/org/jboss/net/uddi/server/
UddiService.java:95: cannot resolve symbol symbol : variable
DataStoreFactory
location: class org.jboss.net.uddi.server.UddiService
DataStoreFactory factory = DataStoreFactory.getInstance();
^
/home/jboss/jbossci/jboss-head/jboss.net/src/main/org/jboss/net/uddi/server/
UddiService.java:96: cannot resolve symbol symbol : class DataStore
location: class org.jboss.net.uddi.server.UddiService
DataStore store = factory.aquireDataStore();
^
/home/jboss/jbossci/jboss-head/jboss.net/src/main/org/jboss/net/uddi/server/
UddiService.java:98: cannot resolve symbol symbol : class JDBCDataStore
location: class org.jboss.net.uddi.server.UddiService
if (store instanceof JDBCDataStore) {
^
/home/jboss/jbossci/jboss-head/jboss.net/src/main/org/jboss/net/uddi/server/
UddiService.java:99: cannot resolve symbol symbol : class JDBCDataStore
location: class org.jboss.net.uddi.server.UddiService
Connection connection = ((JDBCDataStore) store).getConnection();
^
/home/jboss/jbossci/jboss-head/jboss.net/src/main/org/jboss/net/uddi/server/
UddiService.java:194: cannot resolve symbol symbol : variable UUID
location: class org.jboss.net.uddi.server.UddiService
UUID.startup();
^
/home/jboss/jbossci/jboss-head/jboss.net/src/main/org/jboss/net/uddi/server/
UddiService.java:195: cannot resolve symbol symbol : variable Auth
location: class org.jboss.net.uddi.server.UddiService
Auth.startup();
^
/home/jboss/jbossci/jboss-head/jboss.net/src/main/org/jboss/net/uddi/server/
UddiService.java:221: cannot resolve symbol symbol : variable Auth
location: class org.jboss.net.uddi.server.UddiService
Auth.shutdown();
^
/home/jboss/jbossci/jboss-head/jboss.net/src/main/org/jboss/net/uddi/server/
UddiService.java:222: cannot resolve symbol symbol : variable UUID
location: class org.jboss.net.uddi.server.UddiService
UUID.shutdown();
^
47 errors
14 warnings
BUILD FAILED
file:/home/jboss/jbossci/jboss-head/jboss.net/build.xml:165: Compile failed;
see the compiler error output for details.
Total time: 3 minutes 17 seconds
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] FYI [JBoss.net]: Integrated Uddi Server submitted into HEAD
I have to warn you a bit before, because it requires getting familiar with web services and the corresponding API´s that JCP has been giving out over the last year. But if you want to dive into that (important, IMHO) matter, then this will be a great experience for you, I promise. In any case, you should have a look at the axis documentation (http://xml.apache.org/axis and from there you will find links to the SOAP spec) because that is the basics of the whole matter. Option a) What about getting a fresh copy of the J2EE 1.4 draft and the Web Services for J2EE spec from http://java.sun.com Option a.1) Then, try to understand the Axis/jboss.net deployment model (works best from the testsuite) and you are ready to understand the pending mismatches between both (see my mail) and could help to define a mapping. Option a.2) You could help to write an xdoclet (http://xdoclet.sourceforge.net) module that builds the new J2EE1.4 descriptors. Option b) You could dive into UDDI (http://www.uddi.org) and figure out a way how to best annotate the jboss.net web-services such that they can be automatically published upon deployment. Interested? CGJ -Ursprüngliche Nachricht- Von: Alex Sumner [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 13. März 2003 17:42 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] FYI [JBoss.net]: Integrated Uddi Server submitted into HEAD Cristoph, I'm interested in helping. I haven't contributed to Jboss before, have been working with it for about a year. I did the training with Marc and Sacha in London last March. I also saw your jboss-net presentation at JavaOne in SF last year. I haven't used jboss-net so far, but am about to start. How can I help? Cheers, Alex Sumner -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jung , Dr. Christoph Sent: 13 March 2003 13:23 To: '[EMAIL PROTECTED]' Subject: [JBoss-dev] FYI [JBoss.net]: Integrated Uddi Server submitted into HEAD Hi, I just submitted another step towards J2EE1.4 Web Service compliance. The jboss-net.sar now additionally hosts a uddi-v2 compliant server (currently jUddi0.6.2). It is published upon startup as a web service itself (currently running under http://hostname/axis/services/uddi) via the already existant SOAP/Axis transport layer (now upgraded to Axis1.1 RC1) of JBoss.net The uddi server is secured by a configurable Jboss security domain (java:/jaas/other) and backed by any jdbc data source (java:/DefaultDS). Please make sure that, on order to build jboss.net, you need to update your thirdparties (juddi/juddi/lib/juddi.jar) Next steps are - automatic registration of web services deployed through jboss.net including their wsdl-representation in UDDI. - XSLSubDeployer that maps the new web service descriptor format of J2EE1.4 onto JBoss.net/Axis wsdd. - deployment delegation from EJBDeployer and WarDeployer into the AxisDeployer (the spec is extremely dumb in that respect, but the hooks are already there, so we do this for compliance purposes). - support of jaxrpc mapping descriptors. - support for JCA extensions related to web services. - smarter integration with the invocation stack such that axis handler operations (especially de/-serialialisation) can be moved into the EJB layer (transactions, security, etc.) If anyone is interested in helping with these things (even in reading the extremely boring specifications and explaining them to me ;-), please yell! Best, CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning
AW: [JBoss-dev] Jboss.net undeployment
John, Which version of jboss/Jboss.net do you use? What error do you get? Jboss.net automatically builds an in-memory undeployment descriptor for Axis from the web-service.xml (it is simply changing the root element name) in order to tear down the web service on undeployment, so this should work. CGJ -Ursprüngliche Nachricht- Von: John Fawcett [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 5. Februar 2003 16:19 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Jboss.net undeployment Hi, Currently, I have to restart jboss to undeploy/redeploy webservices. Hot-deployment works fine, but can not be repeated without a restart. I noticed in the axis doco that they use an undeployment descriptor. Would something similar work for jboss-net? Thanks, fawce --- 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 message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.NET email is sponsored by: 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
AW: [JBoss-dev] Jboss.net undeployment -- false alarm
-Ursprüngliche Nachricht- Von: John Fawcett [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 6. Februar 2003 18:22 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] Jboss.net undeployment -- false alarm Sorry, we had some unrelated transient config errors that I mistakenly attributed to wsr undeployment. Bad for you, good for me ;-) We are currently running against a jboss-head build -- is this feature present in jboss3.2? oui. Thanks and apologies for the false alarm, You can buy me some beers whenever we meet in person ;-) Have a nice weekend and keep on finding bugs, the both thingy is now confirmed, I definitely have to change the template. CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.NET email is sponsored by: 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
AW: [JBoss-dev] JBoss-IDE next steps
Hans, First congratulations for getting started such a badly needed feature around JBoss. I just saw the package Xdoclet-View in your plan and this reminded me of some unfinished prototype that I did last year. It was an experiment of how to write some extensible view for editing meta-data that is similar to the Together/J-Property pane and that is based on doclet annotations (a lot of the single-source technology of Together was implemented that way and it worked nicely IMHO!). The javadoc view has some default editors for the standard tags and you should be able to extend it with additional editors for special tags such that you can derive special views for Entity Beans, Session Beans, Web Services, ... I got it to work to the point that the view extracts information from the java model, writes edit changes back into the java/text model and registers as an update listener in the text model. The view still fails in the issue that events inside Eclipse are not very well-ordered, i.e., the view will receive text events before the java model decides that the selected property does not exist anymore. This leads to nasty glitches which hindered me of publishing any code yet and since then, I did not dive deeper into the Eclipse platform. I guess that you have more knowledge in that direction and hence JBoss-IDE would be the ideal host for the code to prosper? Just tell me if you are interested and I will zip you the stuff. CGJ -Ursprüngliche Nachricht- Von: Hans Dockter [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 3. Februar 2003 13:59 An: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Betreff: [JBoss-dev] JBoss-IDE next steps I've written a next steps proposal for JBoss-IDE available at: http://www.jboss.org/servlet/JiveServlet/download/162-27873-3763505-1281/JBo ss-IDE_next_steps.html Hans --- 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 message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.NET email is sponsored by: 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
AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?
The axis version in the 3.0 branch is a beta. From 3.2 on, we have axis release 1 (it is no more located in the system lib directory, but an integral part of the jboss.net sar) In head, we have axis 1.1beta integrated. Since you seem not to use jboss.net, why don´t you simply update the jar in your 3.0 distro? If you want the nice deployment/security features of jboss.net, however, I recommend obtaining 3.2RCwhatever. CGJ -Ursprüngliche Nachricht- Von: Kevin Roast [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 17. Januar 2003 10:55 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9? Hi, I am interested to know if the following is a known Jboss+AXIS bug: We are testing a system using Jboss3.0.4 using the standard embedded version of AXIS. We are using SOAP calls for our web services which AXIS is parsing using the system XML parser. By default this is Xerces which is fine. However, if I change the parser factory to use Oracle XDK 9 parser then I receive an error from the AXIS SAX parsing thus: java.lang.StringIndexOutOfBoundsException: String index out of range: 323 at java.lang.String.init(String.java:245) at org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121) at org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j ava:137) at org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali zationContextImpl.java:771) at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java: 213) at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j ava:578) at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207) at org.apache.axis.message.RPCElement.getParams(RPCElement.java:231) at org.apache.axis.client.Call.invoke(Call.java:1605) I have inspected the SOAP being parsed and SAX parsed it myself using both Xerces and Oracle XDK and it parses fine. This leads me to believe that AXIS is doing something naughty in the SAX characters() event method i.e. maybe not respecting the start/len parameters? (I'm guessing here from the error) Anyone have any thoughts on this, or I am in completely the wrong ball park? Also - can anyone confirm which version of AXIS is built into Jboss? As I posted this bug to the AXIS-Bug list and they said this particular method no longer exists in the current source line. If possible, I am happy to upgrade the version of AXIS in Jboss - can this be done? Thanks for your time, Kevin --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?
If you do not use jboss-net, simply delete the sar.
CGJ
-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 17. Januar 2003 14:44
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?
Hi,
Thanks for your reply. Unfortuntely simply upgrading the JAR does not work
:( My investigation leads me to believe that parts of the Jboss3.0 AXIS
integration (in jboss-net.sar?) would need to be re-compiled against the
newew AXIS jar to work. For instance, I get this exception when starting
Jboss:
13:34:48,166 ERROR [URLDeploymentScanner]
Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@45bb4fb6{
url=file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not create deployment:
file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/; - nested throwable:
(java.lang.IllegalAccessError: try to access field
org.apache.axis.configuration.FileProvider.myInputStream from class
org.jboss.net.axis.XMLResourceProvider)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827)
I'll take a look at 3.2RC1 and see if it fixes the problem...
Kev
-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]]
Sent: 17 January 2003 10:34
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?
The axis version in the 3.0 branch is a beta.
From 3.2 on, we have axis release 1 (it is no more located in the system lib
directory, but an integral part of the jboss.net sar)
In head, we have axis 1.1beta integrated.
Since you seem not to use jboss.net, why don´t you simply update the jar in
your 3.0 distro?
If you want the nice deployment/security features of jboss.net, however, I
recommend obtaining 3.2RCwhatever.
CGJ
-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 17. Januar 2003 10:55
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?
Hi,
I am interested to know if the following is a known Jboss+AXIS bug:
We are testing a system using Jboss3.0.4 using the standard embedded version
of AXIS. We are using SOAP calls for our web services which AXIS is parsing
using the system XML parser. By default this is Xerces which is fine.
However, if I change the parser factory to use Oracle XDK 9 parser then I
receive an error from the AXIS SAX parsing thus:
java.lang.StringIndexOutOfBoundsException: String index out of range: 323
at java.lang.String.init(String.java:245)
at
org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121)
at
org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j
ava:137)
at
org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali
zationContextImpl.java:771)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
213)
at
org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:578)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParams(RPCElement.java:231)
at org.apache.axis.client.Call.invoke(Call.java:1605)
I have inspected the SOAP being parsed and SAX parsed it myself using both
Xerces and Oracle XDK and it parses fine. This leads me to believe that AXIS
is doing something naughty in the SAX characters() event method i.e. maybe
not respecting the start/len parameters? (I'm guessing here from the error)
Anyone have any thoughts on this, or I am in completely the wrong ball park?
Also - can anyone confirm which version of AXIS is built into Jboss? As I
posted this bug to the AXIS-Bug list and they said this particular method no
longer exists in the current source line. If possible, I am happy to upgrade
the version of AXIS in Jboss - can this be done?
Thanks for your time,
Kevin
---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by
implementing SSL on your Apache Web Server. Click here to get our FREE
Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin
AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?
You can install axis in jboss as you would do in any other application
server: simply deploy it
(and the web service logic+axis deployment descriptors) as a big
web-application.
Jboss-net is glue code that integrates axis a bit more sophisticated, namely
as a
web service archive (wsr) deployer. A wsr is a jar that contains your web
service logic
as well as the corresponding axis deployment descriptor.
Now I am confused: How do you deploy your web services after startup? Of
course, I recommend using jboss.net
Hence upgrading to 3.2 ...
CGJ
-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 17. Januar 2003 15:52
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?
Sorry, I'm a little confused here. How does Jboss integrate with AXIS? If I
delete the SAR will AXIS work? Currently the AXIS service URL doesn't work
if I upgrade the version of AXIS in Jboss 3.0.
Kev
-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]]
Sent: 17 January 2003 14:03
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?
If you do not use jboss-net, simply delete the sar.
CGJ
-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 17. Januar 2003 14:44
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?
Hi,
Thanks for your reply. Unfortuntely simply upgrading the JAR does not work
:( My investigation leads me to believe that parts of the Jboss3.0 AXIS
integration (in jboss-net.sar?) would need to be re-compiled against the
newew AXIS jar to work. For instance, I get this exception when starting
Jboss:
13:34:48,166 ERROR [URLDeploymentScanner]
Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@45bb4fb6{
url=file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not create deployment:
file:/C:/jboss-3.0.4/server/all/deploy/jbossweb.sar/; - nested throwable:
(java.lang.IllegalAccessError: try to access field
org.apache.axis.configuration.FileProvider.myInputStream from class
org.jboss.net.axis.XMLResourceProvider)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827)
I'll take a look at 3.2RC1 and see if it fixes the problem...
Kev
-Original Message-
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]]
Sent: 17 January 2003 10:34
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle
XDK9?
The axis version in the 3.0 branch is a beta.
From 3.2 on, we have axis release 1 (it is no more located in the system lib
directory, but an integral part of the jboss.net sar)
In head, we have axis 1.1beta integrated.
Since you seem not to use jboss.net, why don´t you simply update the jar in
your 3.0 distro?
If you want the nice deployment/security features of jboss.net, however, I
recommend obtaining 3.2RCwhatever.
CGJ
-Ursprüngliche Nachricht-
Von: Kevin Roast [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 17. Januar 2003 10:55
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Axis/Jboss bug parsing soap calls using Oracle XDK9?
Hi,
I am interested to know if the following is a known Jboss+AXIS bug:
We are testing a system using Jboss3.0.4 using the standard embedded version
of AXIS. We are using SOAP calls for our web services which AXIS is parsing
using the system XML parser. By default this is Xerces which is fine.
However, if I change the parser factory to use Oracle XDK 9 parser then I
receive an error from the AXIS SAX parsing thus:
java.lang.StringIndexOutOfBoundsException: String index out of range: 323
at java.lang.String.init(String.java:245)
at
org.apache.axis.message.SymbolTable.addSymbol(SymbolTable.java:121)
at
org.apache.axis.message.SAX2EventRecorder.characters(SAX2EventRecorder.j
ava:137)
at
org.apache.axis.encoding.DeserializationContextImpl.characters(Deseriali
zationContextImpl.java:771)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
213)
at
org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:578)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParams(RPCElement.java:231)
at org.apache.axis.client.Call.invoke(Call.java:1605)
I have inspected the SOAP being parsed and SAX parsed it myself using both
Xerces and Oracle XDK and it parses fine. This leads me to believe that AXIS
is doing something naughty in the SAX characters() event method i.e. maybe
not respecting the start/len parameters? (I'm guessing here from the error)
Anyone have any thoughts on this, or I am in completely the wrong ball park?
Also - can anyone confirm which version of AXIS is built into Jboss
AW: AW: [JBoss-dev] Updating to use Axis 1.1 beta
They have also changed the signature of the serializer´s xsd-emitter methods. It´s in now. CGJ -Ursprüngliche Nachricht- Von: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 8. Januar 2003 08:26 An: '[EMAIL PROTECTED]' Betreff: AW: AW: [JBoss-dev] Updating to use Axis 1.1 beta Never mind. Once we are through this, we have a common denominator to work on ;-) CGJ -Ursprüngliche Nachricht- Von: Tom Elrod [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 7. Januar 2003 23:48 An: [EMAIL PROTECTED] Betreff: Re: AW: [JBoss-dev] Updating to use Axis 1.1 beta I was the one the broke the build. I have updated the following files within jboss.net package: org.jboss.net.jmx.adaptor.AttributeSerializer org.jboss.net.jmx.adaptor.ObjectSerializer to fix the build. You can find the changes made by searching for 'implemented to comply with Axis 1.1beta'. I certainly should have done a clean build before the update and apologize. I also am sorry that I misunderstood I would also give my ok for putting the 1.1 binaries into head as meaning that it would be ok for me to update the binaries into head. -Tom. Jung , Dr. Christoph wrote: You should have tried to build/build most before submitting then you would have noticed that the axis-beta patch has not yet been applied to jboss.net and broke the build. Grrmpf. This leaves it to me to repair it. How I love that. CGJ -Ursprüngliche Nachricht- Von: Tom Elrod [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 7. Januar 2003 08:58 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] Updating to use Axis 1.1 beta I have updated the following in thirdparty to support Axis 1.1 beta (which I needed for JMX SOAP Connector). The update was done to HEAD in CVS. thirdparty/apache-axis/README thirdparty/apache-axis/release-notes.html thirdparty/apache-axis/lib/axis.jar thirdparty/apache-axis/lib/jaxrpc.jar thirdparty/apache-axis/lib/saaj.jar thirdparty/apache-commons/lib/commons-discovery.jar I was unable to verify any affect this might have had on the other jboss projects (other than the e-mail sent out previously), so if you are using any of these, please verify it does not break any of your code. Thanks. -Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jung , Dr. Christoph Sent: Thursday, January 02, 2003 3:42 AM To: '[EMAIL PROTECTED]' Subject: AW: [JBoss-dev] Updating to use Axis 1.1 beta Tom, There is already a patch for jboss.net submitted which addresses some additional exceptions raised in the Axis1.1 beta. I think that I will be able to apply it such that jboss.net will cope with both 1.0 and 1.1 ... I would also give my ok for putting the 1.1 binaries into head, but I would hesitate going for beta in the 3.2 branch. CGJ -Ursprüngliche Nachricht- Von: Tom Elrod [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 31. Dezember 2002 06:28 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Updating to use Axis 1.1 beta I have written a SOAP connector to be used within the JBoss-MX project which uses Axis 1.1 beta. I know that Axis 1.0 is being used in the root thirdparty for jboss.net and was wondering if someone could tell me if there would be a problem upgrading it to 1.1 beta so both sub-projects (jboss-mx and jboss.net) could use the same libraries? Thanks. -Tom --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: 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 message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM
AW: [JBoss-dev] patch for axis1.1beta upgrade
John,
Thanks. Just applied them (semantically).
CGJ
-Ursprüngliche Nachricht-
Von: John Fawcett [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 8. Januar 2003 02:22
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] patch for axis1.1beta upgrade
Hi,
Below is a patch to upgrade the jboss sources to use axis1.1beta.
The files modified are:
jboss.net/src/main/org/jboss/net/axis/server/AxisService.java
jboss.net/src/main/org/jboss/net/jmx/adaptor/AttributeSerializer.java
jboss.net/src/main/org/jboss/net/jmx/adaptor/ObjectNameSerializer.java
I've been using this modified source to run sessionbean-based web-services,
and it seems to be working fine for me.
hope this is useful,
fawce
---
/../../../jboss-head/jboss.net/src/main/org/jboss/net/axis/server/Axis
Service.java2003-01-07 12:30:37.0 -0500
+++
/../../../tamale_jboss4/jboss.net/src/main/org/jboss/net/axis/server/A
xisService.java 2002-12-15 10:37:09.0 -0500
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: AxisService.java,v 1.32 2003/01/07 17:30:37 cgjung Exp $
+// $Id: AxisService.java,v 1.2 2002/12/15 15:37:09 jfawcett Exp $
package org.jboss.net.axis.server;
@@ -58,6 +58,7 @@
import javax.naming.LinkRef;
import javax.naming.Context;
import javax.naming.NamingException;
+import javax.xml.parsers.ParserConfigurationException;
import java.io.FilenameFilter;
import java.io.File;
@@ -82,7 +83,7 @@
* within JMX.
* @created 27. September 2001
* @author a href=mailto:[EMAIL PROTECTED];Christoph G. Jung/a
- * @version $Revision: 1.32 $
+ * @version $Revision: 1.2 $
*/
public class AxisService
@@ -409,52 +410,57 @@
Document doc= (Document) sdi.metaData;
// the original command
Element root= doc.getDocumentElement();
+ // the deployment command document
+ Document deployDoc = null;
+ Document deployClientDoc = null;
try{
-
-// the deployment command document
-Document deployDoc= XMLUtils.newDocument();
-// the client deployment command document
-Document deployClientDoc= XMLUtils.newDocument();
-// create command
-Element deploy=
- deployDoc.createElementNS(root.getNamespaceURI(),
deployment);
-// create command
-Element deployClient=
- deployClientDoc.createElementNS(
- root.getNamespaceURI(),
- deployment);
-
-NamedNodeMap attributes= root.getAttributes();
-for (int count= 0; count attributes.getLength(); count++)
{
- Attr attribute= (Attr) attributes.item(count);
- deploy.setAttributeNodeNS(
- (Attr) deployDoc.importNode(attribute, true));
- deployClient.setAttributeNodeNS(
- (Attr) deployClientDoc.importNode(attribute, true));
-}
+ deployDoc= XMLUtils.newDocument();
+ // the client deployment command document
+ deployClientDoc= XMLUtils.newDocument();
+ } catch (ParserConfigurationException e){
+ e.printStackTrace();
+ }
+
+ // create command
+ Element deploy=
+deployDoc.createElementNS(root.getNamespaceURI(),
deployment);
+ // create command
+ Element deployClient=
+deployClientDoc.createElementNS(
+ root.getNamespaceURI(),
+ deployment);
-// and insert the nodes from the original document
-// and sort out the ejb-ref extensions
-NodeList children= root.getChildNodes();
-for (int count= 0; count children.getLength(); count++) {
- Node actNode= children.item(count);
- if (actNode instanceof Element) {
- Element actElement= (Element) actNode;
-
- if (actElement.getTagName().equals(ejb-ref)) {
-
- String refName=
-MetaData.getElementContent(
- MetaData.getUniqueChild(
- (Element) actNode,
- ejb-ref-name));
- String linkName=
-MetaData.getElementContent(
- MetaData.getUniqueChild((Element) actNode,
ejb-link));
+ NamedNodeMap attributes= root.getAttributes();
+ for (int count= 0; count attributes.getLength(); count++) {
+Attr attribute= (Attr) attributes.item(count);
+deploy.setAttributeNodeNS(
+ (Attr) deployDoc.importNode(attribute, true));
+deployClient.setAttributeNodeNS(
+ (Attr) deployClientDoc.importNode(attribute, true));
+ }
- log.warn(
-Web Service Deployment
+ // and insert the nodes from the original document
+ //
AW: [JBoss-dev] Updating to use Axis 1.1 beta
You should have tried to build/build most before submitting then you would have noticed that the axis-beta patch has not yet been applied to jboss.net and broke the build. Grrmpf. This leaves it to me to repair it. How I love that. CGJ -Ursprüngliche Nachricht- Von: Tom Elrod [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 7. Januar 2003 08:58 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] Updating to use Axis 1.1 beta I have updated the following in thirdparty to support Axis 1.1 beta (which I needed for JMX SOAP Connector). The update was done to HEAD in CVS. thirdparty/apache-axis/README thirdparty/apache-axis/release-notes.html thirdparty/apache-axis/lib/axis.jar thirdparty/apache-axis/lib/jaxrpc.jar thirdparty/apache-axis/lib/saaj.jar thirdparty/apache-commons/lib/commons-discovery.jar I was unable to verify any affect this might have had on the other jboss projects (other than the e-mail sent out previously), so if you are using any of these, please verify it does not break any of your code. Thanks. -Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jung , Dr. Christoph Sent: Thursday, January 02, 2003 3:42 AM To: '[EMAIL PROTECTED]' Subject: AW: [JBoss-dev] Updating to use Axis 1.1 beta Tom, There is already a patch for jboss.net submitted which addresses some additional exceptions raised in the Axis1.1 beta. I think that I will be able to apply it such that jboss.net will cope with both 1.0 and 1.1 ... I would also give my ok for putting the 1.1 binaries into head, but I would hesitate going for beta in the 3.2 branch. CGJ -Ursprüngliche Nachricht- Von: Tom Elrod [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 31. Dezember 2002 06:28 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Updating to use Axis 1.1 beta I have written a SOAP connector to be used within the JBoss-MX project which uses Axis 1.1 beta. I know that Axis 1.0 is being used in the root thirdparty for jboss.net and was wondering if someone could tell me if there would be a problem upgrading it to 1.1 beta so both sub-projects (jboss-mx and jboss.net) could use the same libraries? Thanks. -Tom --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: 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 message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.NET email is sponsored by: 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
AW: AW: [JBoss-dev] Updating to use Axis 1.1 beta
Never mind. Once we are through this, we have a common denominator to work on ;-) CGJ -Ursprüngliche Nachricht- Von: Tom Elrod [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 7. Januar 2003 23:48 An: [EMAIL PROTECTED] Betreff: Re: AW: [JBoss-dev] Updating to use Axis 1.1 beta I was the one the broke the build. I have updated the following files within jboss.net package: org.jboss.net.jmx.adaptor.AttributeSerializer org.jboss.net.jmx.adaptor.ObjectSerializer to fix the build. You can find the changes made by searching for 'implemented to comply with Axis 1.1beta'. I certainly should have done a clean build before the update and apologize. I also am sorry that I misunderstood I would also give my ok for putting the 1.1 binaries into head as meaning that it would be ok for me to update the binaries into head. -Tom. Jung , Dr. Christoph wrote: You should have tried to build/build most before submitting then you would have noticed that the axis-beta patch has not yet been applied to jboss.net and broke the build. Grrmpf. This leaves it to me to repair it. How I love that. CGJ -Ursprüngliche Nachricht- Von: Tom Elrod [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 7. Januar 2003 08:58 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] Updating to use Axis 1.1 beta I have updated the following in thirdparty to support Axis 1.1 beta (which I needed for JMX SOAP Connector). The update was done to HEAD in CVS. thirdparty/apache-axis/README thirdparty/apache-axis/release-notes.html thirdparty/apache-axis/lib/axis.jar thirdparty/apache-axis/lib/jaxrpc.jar thirdparty/apache-axis/lib/saaj.jar thirdparty/apache-commons/lib/commons-discovery.jar I was unable to verify any affect this might have had on the other jboss projects (other than the e-mail sent out previously), so if you are using any of these, please verify it does not break any of your code. Thanks. -Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jung , Dr. Christoph Sent: Thursday, January 02, 2003 3:42 AM To: '[EMAIL PROTECTED]' Subject: AW: [JBoss-dev] Updating to use Axis 1.1 beta Tom, There is already a patch for jboss.net submitted which addresses some additional exceptions raised in the Axis1.1 beta. I think that I will be able to apply it such that jboss.net will cope with both 1.0 and 1.1 ... I would also give my ok for putting the 1.1 binaries into head, but I would hesitate going for beta in the 3.2 branch. CGJ -Ursprüngliche Nachricht- Von: Tom Elrod [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 31. Dezember 2002 06:28 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Updating to use Axis 1.1 beta I have written a SOAP connector to be used within the JBoss-MX project which uses Axis 1.1 beta. I know that Axis 1.0 is being used in the root thirdparty for jboss.net and was wondering if someone could tell me if there would be a problem upgrading it to 1.1 beta so both sub-projects (jboss-mx and jboss.net) could use the same libraries? Thanks. -Tom --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: 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 message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.NET email is sponsored by: 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
AW: [JBoss-dev] Updating to use Axis 1.1 beta
Tom, There is already a patch for jboss.net submitted which addresses some additional exceptions raised in the Axis1.1 beta. I think that I will be able to apply it such that jboss.net will cope with both 1.0 and 1.1 ... I would also give my ok for putting the 1.1 binaries into head, but I would hesitate going for beta in the 3.2 branch. CGJ -Ursprüngliche Nachricht- Von: Tom Elrod [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 31. Dezember 2002 06:28 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Updating to use Axis 1.1 beta I have written a SOAP connector to be used within the JBoss-MX project which uses Axis 1.1 beta. I know that Axis 1.0 is being used in the root thirdparty for jboss.net and was wondering if someone could tell me if there would be a problem upgrading it to 1.1 beta so both sub-projects (jboss-mx and jboss.net) could use the same libraries? Thanks. -Tom --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] jbossnet ant task
Not yet. I tweaked it ~3 weeks ago to somehow run through, but there may have been changes such that I should change it. CGJ -Ursprüngliche Nachricht- Von: John Fawcett [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 11. Dezember 2002 22:21 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] jbossnet ant task Does the jboss.net testsuite currently build and run? Looks to me like the build.xml is a generation behind, since it isn't using the new buildmagic stuff in JBOSS_HOME/tools/lib/etc Anyone have an updated version? Thanks, fawce -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Essington Sent: Wednesday, December 11, 2002 2:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] jbossnet ant task or you could just skip the whole pain in the ass I just described and use that jar :-) -jason On Wednesday, December 11, 2002, at 11:57 AM, John Fawcett wrote: Pardon my stupidity. The appropriate jar built in the jboss.net module and after a build is located at: /jboss-head/jboss.net/output/lib/xdoclet-module-jboss-net.jar Sorry for the remedial posts. Later, fawce -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Fawcett Sent: Wednesday, December 11, 2002 1:24 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] jbossnet ant task Hi, This has been discussed before, but does anyone know that status/location of the jbossnet ant task? I can't seem to find it in jboss-head/thirdparty/xdoclet-xdoclet/lib Thanks, fawce --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -jason --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Ann] [JBoss.Net] Axis Release 1 + SOAP over SMTP support in *Head*
Title: Nachricht Fellow Web-Service-Geeks, as always beforetaking 3 weeks off, I tried to break thebuild ;-) no, just kidding. I just managed to integrate into head (finally!) the 1.0 release of Axisincluding some jboss.net extensions wrt e-mail transport of soap messages as contributed by Jason Essington (applause, welcome aboard). The bug wrt double appearances of the jaxp-QName classhas also been resolved as a by-product. Now being a commiter, I hope that Jason could soonprovide some sample mbean-configuration for the javamail-listener and some test code to demonstrate thenew (quite transparent) transports/handlersto the public ;-) Anyway, the final release of Axis now being landed, I now plan to start a consolidation phase for jboss.net when I come back until the end of the year focussing on porting the stuff to 3.2 and, ta ta, documentation ...Would be cool if we could find a few volunteers (Matt?, Bruce?) to help out with language problems, performanceanalysis and Tomcatknowledge Since my thirdparty cvs-workspace was not completely clean and I tried to remove some redundant apache-commons things, I hope that my changes to library.ent where not devastating ... CU in three weeks, CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
AW: [JBoss-dev] JBoss.net and performance tuning
Matt,
Currently we just do prototyping with the stuff, no profiling at all. I´m
away three weeks for holiday. Let us
Discuss this when I come back, ok? It´s crucial and your measures should
help a lot in that respect.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:mmunz;apelon.com]
Gesendet: Freitag, 1. November 2002 18:14
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] JBoss.net and performance tuning
hi again,
Anybody out there working on or using JBoss.net?
Attached are some files I'm using to test, in a very simplistic way, the
performance of jmx.net.
My current timing so far is on average .3 seconds to complete the simplest
possible transaction (as far as I can tell) -- returning a very short string
object.
Does this number sound reasonable? If so, what are you using JBoss.Net
for? Perhaps I have the wrong idea...
Not included in the archive is the class JmxNetProxy, which is a delegate
for the mechanism used in the JBoss.Net test cases. Here's the relevant
method from that class.
public Object invoke(String webServiceName, String mbeanServiceName,
String methodName,
Object[] arguments, Class[] classes)
throws Exception
{
...
MBeanInvocationHandler handler;
handler = createMBeanInvocationHandler(target);
return handler.invoke(mbeanServiceName,
methodName,
arguments,
classes); // classes
}
Any comment would be greatly appreciated.
- Matt ([EMAIL PROTECTED])
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz
Sent: Thursday, October 31, 2002 11:17 AM
To: JBoss Developers Group
Subject: [JBoss-dev] JBoss.net and performance tuning
CGJ and JBoss.net guys,
My fledgeling JBoss.net enabled application is growing up and it needs
some performance enhancements. Particularly, Marshalling/Unmarshalling
appears to take significantly longer than expected.
Here's my setup.
1) I'm using the JMX.net proxy classes used in the test cases.
2) I am working with short, frequent transactions.
3) I am using the bean serializer to send simple custom objects across the
wire.
4) On the server side, an MBean is the recipient of the request.
RE: #1 -- Would WSDL2Java be any faster? Is MBean to wsdl generation
working yet?
RE: #2 -- I know, course-grained transactions are preferred, but are they
required? My objects are small, almost tiny. How fast can a transaction
be? If I can get it under .05 seconds, this should suffice for the moment.
RE: #3 -- Any tips / tricks here? Would switiching to primitives and
Strings be markedly faster?
Any help would be greatly appreciated. Links to benchmarks / performance
tests would help too.
- Matt
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] jboss.net status
Title: Nachricht 3.0 is still a beta version 3.2 should be rc1 head will be release 1 when I manage to checkin the stuff over the weekend. I´m going on holidays for the next three weeks, so no promise on that. But I´ll try. CGJ -Ursprüngliche Nachricht-Von: Finn, Michael [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 31. Oktober 2002 15:55An: Jboss-Development-List (E-mail)Betreff: [JBoss-dev] jboss.net status Guys, Quick question - what is the status of jboss.net WRT Axis 1.0 in: - 3.0 branch? - 3.2 branch? - HEAD? Is Axis 1.0 GA supported anywhere yet? TIA, Mike ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
[JBoss-dev] [Ann] [JBoss.Net] Axis RC2 + Extended Jboss-Net-Xdoclet-Module now in head
Title: Nachricht Hi, Axis RC2has just been successfully integrated into Jboss.Net@cvs-head.The testsuite has been added a chapter for the different ways of dealingwith stateful services through the web-service scope (thanks Kevin Connor for the inspiration).Thatpart of the testsuite now runssuccessfullywith the help of the unified xdoclet-module-jboss-net.jar (Xdoclet 1.2 and JBoss-Xdoclet-1.2compat) - thanks Jason Essington for patching the template with scopes. Web-Service security test chapterand backport to 3.2 will follow next week. CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
AW: [JBoss-dev] writing a jboss.net (jmx.net?) client
Matt,
MBeanProvider should normally reflect over the JMX-Metadata (hence also the
mbean methods) to
Build the wsdl. But I havn´t looked at the code for a while. Let met check
this.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 25. September 2002 17:08
An: Matt Munz; [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ JBoss.Net developers,
After working with wsdl2Java, I have come to the conclusion that the wsdl
being generated by org.jboss.net.jmx.server.MBeanProvider is not accurate. I
have included both the WSDL and the interface generated by wsdl2Java. Any
ideas? It seems to me that the method signatures of my MBean should show up
in the wsdl. Is this an accurate assumption? If so, what might be
preventing accurate wsdl generation in this case?
- Matt
?xml version=1.0 encoding=UTF-8?
wsdl:definitions
targetNamespace=http://localhost:8080/jboss-net/services/CustomTerminologyM
anagementService xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:apachesoap=http://xml.apache.org/xml-soap;
xmlns:impl=http://localhost:8080/jboss-net/services/CustomTerminologyManage
mentService
xmlns:intf=http://localhost:8080/jboss-net/services/CustomTerminologyManage
mentService xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
wsdl:portType name=XMBean
/wsdl:portType
wsdl:binding name=CustomTerminologyManagementServiceSoapBinding
type=impl:XMBean
wsdlsoap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http/
/wsdl:binding
wsdl:service name=XMBeanService
wsdl:port binding=impl:CustomTerminologyManagementServiceSoapBinding
name=CustomTerminologyManagementService
wsdlsoap:address
location=http://localhost:8080/jboss-net/services/CustomTerminologyManageme
ntService/
/wsdl:port
/wsdl:service
/wsdl:definitions
/**
* XMBean.java
*
* This file was auto-generated from WSDL
* by the Apache Axis WSDL2Java emitter.
*/
package localhost;
public interface XMBean extends java.rmi.Remote {
}
-Original Message-
From: Matt Munz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 24, 2002 10:49 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ,
Thanks for your response.
A) generate wsdl from the deployed web services.
B) generate stub classes from the wsdl using wsdl2java.
This is the first thing that I tried and it did not work. I didn't take a
lot of time to firgure out why this is the case, since the jboss.net
testcase code was easy to understand, so I may have missed something
simple...
This may work for simple cases, but once you declare additional data
structures and serializers, it becomes very hairy on the client side,
otherwise.
Well, for my purposes, I don't intend on sending complex Object graphs
over the wire. I also think that the Bean Serializer should be sufficient
for my purposes. By may work, do you mean will work without errors for
simple cases, or probably won't work for any case, so don't even try it?
Is there a test case that demonstrates the technique (A B above) that
you reccommend? I would find this quite useful. If I have time, I'll try
to write one myself, if it doesn't already exist.
On code generation in general, I must admit that I have a bit of healthy
skepticism on the matter. In this example, the amount of client side code
required to use the deprecated technique totals no more than a few lines,
while the output of wsdl2java comprises multiple full-fledged classes. It
seems to me that, auto-generated or not, this compromises a significant
ramp-up in code maitennance costs.
Based on your experience, what makes code generation the way to go in this
case? Do you find the generated code reasonable, easy to maintain,
scalable, reliable, etc.?
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jung ,
Dr. Christoph
Sent: Tuesday, September 24, 2002 10:06 AM
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] writing a jboss.net (jmx.net?) client
Matt,
For getting the client-side invocations and stub classes right, we recommend
The following steps:
A) generate wsdl from the deployed web services.
B) generate stub classes from the wsdl using wsdl2java.
Using Axis/MbeanInvocationHandler lacks a lot of deployment information
(basically, The client-side of the web-service.xml) that we try to default
from java reflection.
This may work for simple cases, but once you declare additional data
structures and serializers, it becomes very hairy on the client side,
otherwise.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 20. September 2002 17:41
An: JBoss Developers Group
Betreff: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ
AW: [JBoss-dev] writing a jboss.net (jmx.net?) client
Matt, For getting the client-side invocations and stub classes right, we recommend The following steps: A) generate wsdl from the deployed web services. B) generate stub classes from the wsdl using wsdl2java. Using Axis/MbeanInvocationHandler lacks a lot of deployment information (basically, The client-side of the web-service.xml) that we try to default from java reflection. This may work for simple cases, but once you declare additional data structures and serializers, it becomes very hairy on the client side, otherwise. CGJ -Ursprüngliche Nachricht- Von: Matt Munz [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 20. September 2002 17:41 An: JBoss Developers Group Betreff: [JBoss-dev] writing a jboss.net (jmx.net?) client CGJ JBoss.Net Developers, First, let me say Thank you. I now have MBeans in the server exposed as web services. Although it took a bit of research to figure out how to do this, the minimal amount of (xml) code required to expose MBeans as webservices (should I call this JMX.Net?) speaks for itself. I was again pleased to see that the client side is also straightforward, once I knew what to do. Basically, I emulated the code in the testsuite for JBoss.Net. This works with the following caveat. The org.jboss.net.axis.AxisInvocationHandler class is deprecated. MBeanInvocationHandler, the class I am using on the client side, extends AxisInvocationHandler. What should I do instead of using this class (which seems to work perfectly well)? I found the following in AxisInvocationHandler. Could anyone explain this further? Due to the inherent deficiencies in using pure reflection meat-data to access web services, we recommend using the axis stub way of creating web service references Thanks again. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] jboss.net and catalina
Bruce, which jboss version do you refer to. It works for me from 3.2Beta on even in an exploded fashion. CGJ -Ursprüngliche Nachricht- Von: Bruce Scharlau [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 18. September 2002 11:31 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] jboss.net and catalina Hello all, jboss.net with axis rc1 now seems to work with jboss and tomcat (catalina 4.0.4) Thanks Scott for catching the error with EmbeddedCatalinaSX! IF (and it seem only IF) you wrap the jboss-net.sar in an exploded ear file. Do this: 1. create unpacked jboss-net.ear 2. put jboss-net.sar into this 3. move jboss-net.war and jboss-net.wsr from under jboss-net.sar up a directory to be under jboss-net.ear 4. under jboss-net.ear create a META-INF directory with application.xml that contains this: ?xml version=1.0 encoding=ISO-8859-1? application display-nameJBoss-Example WebService/display-name module javajboss-net.sar/java /module module web web-urijboss-net.war/web-uri context-root/jboss-net/context-root jboss-net.wsr /web /module /application As soon as I get a chance I'll update the jboss-net howto page at: http://www.csd.abdn.ac.uk/%7Ebscharla/soap.html and the accompanying example pages. cheers, Bruce Dr. Bruce Scharlau Dept. of Computing Science University of Aberdeen Aberdeen AB24 3UE 01224 272193 http://www.csd.abdn.ac.uk/~bscharla mailto:[EMAIL PROTECTED] --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: AW: [JBoss-dev] jboss.net and catalina
If I´m not totally out of mind, yes. CGJ -Ursprüngliche Nachricht- Von: Bruce Scharlau [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 18. September 2002 12:17 An: [EMAIL PROTECTED] Betreff: Re: AW: [JBoss-dev] jboss.net and catalina At 11:58 18/09/2002 +0200, you wrote: Bruce, which jboss version do you refer to. It works for me from 3.2Beta on even in an exploded fashion. CGJ I'm building it all from jboss-all in cvs, ie jboss4.0.x So you got it going ok with the jboss-tomcat in 3.2 then? cheers, Bruce Dr. Bruce Scharlau Dept. of Computing Science University of Aberdeen Aberdeen AB24 3UE 01224 272193 http://www.csd.abdn.ac.uk/~bscharla mailto:[EMAIL PROTECTED] --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBoss.net now supports Axis RC1
Thanks scott, That saves me a lot of headaches ;-) CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 12. September 2002 11:36 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] JBoss.net now supports Axis RC1 I saw the NPE while testing the 3.0.2 bundle. It was caused by the EmbeddedCatalinaServiceSX registering as a war deployer before it was fully started. This has been fixed in all branches. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bruce Scharlau [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 09, 2002 7:40 AM Subject: Re: [JBoss-dev] JBoss.net now supports Axis RC1 At 18:49 06/09/2002 +0200, you wrote: One of the most requested features is now in head (along with some bugfixes and some nice deployment structure changes that remove the dependency of AxisService to the WebContainer). Axis will go 1.0 in a week or so which should be trivial to incorporate then. Are there any special backport requirements? Otherwise, I would go reintegrating it into 3.2, then. Best, CGJ ### Christoph and Friederich, thanks for getting this out guys! I tried it in jetty, and it looked nice. I tried it in tomcat and it crashed here: 2002-09-09 15:33:55,674 INFO [org.jboss.web.catalina.EmbeddedCatalinaServiceSX] deploy, ctxPath=/jboss-net, warUrl=file:/D:/jboss-src/jboss-all/build/output/jboss-4.0.0alpha/server/def ault/deploy/jboss-net.sar/jboss-net.war/ 2002-09-09 15:33:55,684 ERROR [org.jboss.web.catalina.EmbeddedCatalinaServiceSX] Error during deploy java.lang.NullPointerException at org.jboss.web.catalina.EmbeddedCatalinaServiceSX.createWebContext(EmbeddedCa talinaServiceSX.java:389) at org.jboss.web.catalina.EmbeddedCatalinaServiceSX.performDeploy(EmbeddedCatal inaServiceSX.java:331) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:468) I don't have time to look at this any more today, but wanted any initial thoughts you might have, and I can hopefully get it sorted tomorrow. cheers, Bruce Dr. Bruce Scharlau Dept. of Computing Science University of Aberdeen Aberdeen AB24 3UE 01224 272193 http://www.csd.abdn.ac.uk/~bscharla mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] AW: jboss 4 build system changes, possible jboss.net and catalinaimpact.
David, Thanks for the notice. Unfortunately, I have no exact idea about the differences of the jboss-xdoclet and the version that Frederick was getting by the xdoclet guys (must have been something between 1.1 and 1.2 with some bugs fixed?). Frederick, could you please synchronize with David on the global xdoclet version? AFAIK, xdoclet only affects the flash sample and not the testsuite (which did run fine with Jetty on Monday, so I´ll test it again). I guess that we won´t backport the build changes to 3.2? I´m going to migrate the latest jboss.net status into 3.2 this week, so I´d have to be a bit careful about what to sync and what not ... Do you have any cvs tricks for back-integration? I´m very used to the comfortable perforce integration feature, but I guess that I need to compare the absolute branches with diff here, right? CGJ -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 11. September 2002 00:15 An: Jung Christoph; jboss-dev Cc: Bruce Scharlau Betreff: jboss 4 build system changes, possible jboss.net and catalina impact. I replaced many of the repetitive elements in the build.xml files with parameter entities, including the definition of xdoclet tasks. As far as I can tell this hasn't affected anything according to the testsuite. However, one effect is that xdoclet is now always the global xdoclet in thirdparty. Previously it looks like a local version was being used in jboss.net. I don't know if there are any tests of jboss.net: the module appears to compile fine. If this has broken something let me know. I'd prefer to fix it in xdoclet if possible since the xdoclet 1.2 release is imminent. I also don't know if the catalina module still works and don't know how to test it. I only partially converted that build.xml, leaving the previous definitions commented out. Again, info appreciated. thanks david jencks ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: AW: [JBoss-dev] JBoss.net now supports Axis RC1 - update
Bruce,
Thanks for the hint. IMHO, the whole stuff should deploy packed as well as
unpacked. I will have a look
at the Catalina/unpacked variant when I have some spare time this afternoon.
CGJ
-Ursprüngliche Nachricht-
Von: Bruce Scharlau [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 10. September 2002 17:37
An: [EMAIL PROTECTED]
Betreff: Re: AW: [JBoss-dev] JBoss.net now supports Axis RC1 - update
At 14:18 10/09/2002 +0200, you wrote:
Bruce,
That is strange. Could you please try to debug the exact Null variable
that causes the Exception. In EmbeddedCatalinaServiceSX, it says:
private void createWebContext(final WebApplication appInfo, URL warUrl,
final WebDescriptorParser webAppParser) throws Exception
{
ClassLoader loader = Thread.currentThread().getContextClassLoader();
WebMetaData metaData = appInfo.getMetaData();
String ctxPath = metaData.getContextRoot();
appInfo.setName(warUrl.getPath());
appInfo.setClassLoader(loader);
appInfo.setURL(warUrl);
final StandardContext context = (StandardContext)
catalina.createContext(ctxPath, warUrl.getFile());
The last line being the exception-raising 354 one after my count. If
warUrl would be null, then it should already crash at 351, shouldn´t
it? If catalina would be null, my guess is that the whole service would
be flawed ... Can you get any other web application to run under
catalina? What about the management-console?
It would be a tremendous help if you could find out what jboss-net.war
in sar makes different to other services (and IMHO it should work with
the compressed version, too, maybe you need to compress both the
war/wsr ingredients and the jboss-net.sar?
Puzzled,
CGJ
Christoph,
just tried the jboss-net.ear deployed in jboss-jetty and it works fine. I
can get the adminService wsdl file no problem, and noted a typo in the
web.xml file. You have
servlet-mapping
servlet-nameJBossAxisAdminServlet/servlet-name
url-pattern/servlet/AxisAdminServlet/url-pattern
/servlet-mapping
but the index.hmtl page for the admin looks to: servlet/AdminServlet
Anyways, this works under jetty, but NOT tomcat/catalina
I gotta go now, but will pursue this some more tomorrow.
cheers,
Bruce
Dr. Bruce Scharlau
Dept. of Computing Science
University of Aberdeen
Aberdeen AB24 3UE
01224 272193
http://www.csd.abdn.ac.uk/~bscharla
mailto:[EMAIL PROTECTED]
---
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone?
Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] WG: thirdParty mess at head? *Was* AW: JBoss.net compilation fails on HEAD
-Ursprüngliche Nachricht-
Von: Jung , Dr. Christoph
Gesendet: Mittwoch, 11. September 2002 09:49
An: 'Juha-P Lindfors'
Cc: '[EMAIL PROTECTED]'
Betreff: thirdParty mess at head? *Was* AW: JBoss.net compilation fails on
HEAD
Juha, others
I cannot get head to compile at various points: management, jetty, ...
Maybe we should try a complete checkout again?
Most modules seem to have problem with thirdparty references, methinks? I
have no idea what would be the best order to resolve that mess.
Btw. Why are there two crimson.jar (one in apache, one in sun/jaxp, the
latter being the one that is more complete IMHO) in thirdparty?
CGJ
-Ursprüngliche Nachricht-
Von: Juha-P Lindfors [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 11. September 2002 09:00
An: Jung , Dr. Christoph
Betreff: JBoss.net compilation fails on HEAD
Just tried to pull and compile CVS head but it fails for me.
Are you working on something, did I just get a bad checkout?
compile-classes:
[mkdir] Created dir: D:\jboss-all\jboss.net\output\classes\main
[javac] Compiling 56 source files to
D:\jboss-all\jboss.net\output\classes\main
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\AxisAdminServlet.j
ava:23:
cannot
access javax.servlet.http.HttpServlet
file javax\servlet\http\HttpServlet.class not found
protected AxisServer server=null;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:12:
package javax.servlet does not exist
import javax.servlet.ServletException;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:13:
package javax.servlet.http does not exist
import javax.servlet.http.HttpServletRequest;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:14:
package javax.servlet.http does not exist
import javax.servlet.http.HttpServletResponse;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:15:
package javax.servlet.http does not exist
import javax.servlet.http.HttpServletRequestWrapper;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:152
: cannot resolve symbol
symbol : class HttpServletRequest
location: class org.jboss.net.axis.server.FlashAxisServiceServlet
public void doPost(HttpServletRequest req, HttpServletResponse
res)
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:152
: cannot resolve symbol
symbol : class HttpServletResponse
location: class org.jboss.net.axis.server.FlashAxisServiceServlet
public void doPost(HttpServletRequest req, HttpServletResponse
res)
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:153
: cannot resolve symbol
symbol : class ServletException
location: class org.jboss.net.axis.server.FlashAxisServiceServlet
throws ServletException, IOException {
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:58:
cannot resolve symbol
symbol : class HttpServletRequestWrapper
location: class
org.jboss.net.axis.server.FlashAxisServiceServlet.FilteredHttpServletReque
st
public class FilteredHttpServletRequest extends
HttpServletRequestWrapper {
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:70:
cannot resolve symbol
symbol : class HttpServletRequest
location: class
org.jboss.net.axis.server.FlashAxisServiceServlet.FilteredHttpServletReque
st
public FilteredHttpServletRequest(HttpServletRequest req)
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\ServiceFactory.java:15:
warning: org.ap ache.axis.configuration.DefaultEngineConfigurationFactory in
org.apache.axis.configuration has been deprecated import
org.apache.axis.configuration.DefaultEngineConfigurationFactory;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\taglib\FlashParametersTag.java
:18:
package j
avax.servlet.jsp.tagext does not exist
import javax.servlet.jsp.tagext.TagSupport;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\taglib\FlashParametersTag.java
:19:
package j
avax.servlet.jsp does not exist
import javax.servlet.jsp.JspTagException;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\taglib\FlashParametersTag.java
:20:
package j
avax.servlet.jsp does not exist
import javax.servlet.jsp.JspWriter;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\taglib\FlashParametersTag.java
:64:
cannot re
solve symbol
symbol : class TagSupport
location: class
AW: [JBoss-dev] JBoss.net now supports Axis RC1
Bruce,
That is strange. Could you please try to debug the exact Null variable that
causes the Exception. In EmbeddedCatalinaServiceSX, it says:
private void createWebContext(final WebApplication appInfo, URL warUrl,
final WebDescriptorParser webAppParser) throws Exception
{
ClassLoader loader = Thread.currentThread().getContextClassLoader();
WebMetaData metaData = appInfo.getMetaData();
String ctxPath = metaData.getContextRoot();
appInfo.setName(warUrl.getPath());
appInfo.setClassLoader(loader);
appInfo.setURL(warUrl);
final StandardContext context = (StandardContext)
catalina.createContext(ctxPath, warUrl.getFile());
The last line being the exception-raising 354 one after my count. If warUrl
would be null, then it should already crash at 351, shouldn´t it? If
catalina would be null, my guess is that the whole service would be flawed
... Can you get any other web application to run under catalina? What about
the management-console?
It would be a tremendous help if you could find out what jboss-net.war in
sar makes different to other services (and IMHO it should work with the
compressed version, too, maybe you need to compress both the war/wsr
ingredients and the jboss-net.sar?
Puzzled,
CGJ
-Ursprüngliche Nachricht-
Von: Bruce Scharlau [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 10. September 2002 13:51
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-dev] JBoss.net now supports Axis RC1
At 18:49 06/09/2002 +0200, you wrote:
One of the most requested features is now in head (along with some
bugfixes and some nice deployment structure changes that remove the
dependency of
AxisService to the WebContainer).
Axis will go 1.0 in a week or so which should be trivial to incorporate
then.
Are there any special backport requirements? Otherwise, I would go
reintegrating it into 3.2, then.
Best,
CGJ
###
Christoph,
I've now spent the morning trying to get the new jboss.net working with
tomcat/catalina, and no luck.
I tried archiving the jboss.net.sar (instead of its new unpacked
deployment), but this meant that jboss didn't see the jboss.net.war
directory. I tried archiving the jboss.net.war directory, and that didn't
work either. I tried amending the jboss-web.xml file to take in
context-rootjboss-net/context-root but that didn't help either.
The problem seems to come from catalina not finding the context as per the
stack trace:
2002-09-10 12:44:27,953 DEBUG
[org.jboss.web.catalina.EmbeddedCatalinaServiceSX] webContext: null
2002-09-10 12:44:27,953 DEBUG
[org.jboss.web.catalina.EmbeddedCatalinaServiceSX] warURL:
file:/D:/jboss-src/jboss-all/build/output/jboss-4.0.0alpha/server/default/de
ploy/jboss-net.sar/jboss-net.war/
2002-09-10 12:44:27,953 DEBUG
[org.jboss.web.catalina.EmbeddedCatalinaServiceSX] webAppParser:
org.jboss.web.AbstractWebContainer$DescriptorParser@b5c22f
2002-09-10 12:44:28,113
INFO [org.jboss.web.catalina.EmbeddedCatalinaServiceSX] deploy,
ctxPath=/jboss-net,
warUrl=file:/D:/jboss-src/jboss-all/build/output/jboss-4.0.0alpha/server/def
ault/deploy/jboss-net.sar/jboss-net.war/
2002-09-10 12:44:28,123 ERROR
[org.jboss.web.catalina.EmbeddedCatalinaServiceSX] Error during deploy
java.lang.NullPointerException
at
org.jboss.web.catalina.EmbeddedCatalinaServiceSX.createWebContext(EmbeddedCa
talinaServiceSX.java:354)
at
org.jboss.web.catalina.EmbeddedCatalinaServiceSX.performDeploy(EmbeddedCatal
inaServiceSX.java:296)
Any clues/hints on how to resolve this greatly appreciated as always.
BTW the readme.html under the cvs will also need updating, as its
suggestions on integrating tomcat/catalina are now out of date.
cheers,
Bruce
Dr. Bruce Scharlau
Dept. of Computing Science
University of Aberdeen
Aberdeen AB24 3UE
01224 272193
http://www.csd.abdn.ac.uk/~bscharla
mailto:[EMAIL PROTECTED]
---
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone?
Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Another CVS tagging question
Frederick, I´m not sure, but I guess you need to integrate your changes manually against Branch_3_2 ? I hope we didn´t collide wrt. to the AxisRC1 migration I checked into head on Friday? I´d like to backport the changes to 3_2 this week. Btw: The web application part of jboss.net is now deployed as a war-in-sar which will allow several servlets running against a single AxisService/AxisEngine. I would be good, if we could find a way to put your server-side flash code into the AxisServlet/AxisService (by a flag set in the httprequest that could be evaluated by the namespace handler?) such that a single configuration can serve Flash and other clients at the same time. What do you think? CGJ -Ursprüngliche Nachricht- Von: Frederick N. Brier [mailto:[EMAIL PROTECTED]] Gesendet: Samstag, 7. September 2002 19:59 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Another CVS tagging question I had made some changes to the 3.1 Alpha code base. I was about to check them in, but had for another reason, checked out a fresh version of head to another location. It was 4.0 alpha. Now it was my understanding that 4.0 was going to be another leap in design, and 3.2 hasn't been released yet. So if I want to check my changes in, but would also like them placed against the latest 3.2 branch (are we calling that 3.0 even if it is post 3.1?), what tags do I use? What is the process for creating a patch and which direction is best to go? I've not done this before and would appreciate any hand holding. Thank you. Frederick N. Brier Sr. Software Engineer Multideck Corporation --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBoss.net now supports Axis RC1
I just sent a reply to your bug-report that it is IMHO not a jboss.net bug. CGJ -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Gesendet: Samstag, 7. September 2002 10:21 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] JBoss.net now supports Axis RC1 Is the problem with empty soapaction fixed (see buglist under jboss.net-category). On Fri, Sep 06, 2002 at 06:49:35PM +0200, Jung , Dr. Christoph wrote: One of the most requested features is now in head (along with some bugfixes and some nice deployment structure changes that remove the dependency of AxisService to the WebContainer). Axis will go 1.0 in a week or so which should be trivial to incorporate then. Are there any special backport requirements? Otherwise, I would go reintegrating it into 3.2, then. Best, CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ -- MVH Marius Kotsbak Boost communications AS --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss.net now supports Axis RC1
Title: Nachricht One of the most requested features is now in "head" (along with some bugfixes and some nice deployment structure changes that remove the dependency of AxisService to the WebContainer). Axis will go 1.0 in a week or so which should be trivial to incorporate then. Are there any special backport requirements? Otherwise, I would go reintegrating it into 3.2, then. Best, CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
AW: AW: [JBoss-dev] Just how hard is polymorphic cmp?
Title: Nachricht Hi Victor, good to see that we are not alone ;-) -Ursprüngliche Nachricht-Von: Victor Langelo [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 27. August 2002 21:13An: [EMAIL PROTECTED]Betreff: Re: AW: [JBoss-dev] Just how hard is polymorphic cmp? The VBSF kernel maintains an extends relationship for every class. It also builds various mappings which provide base class to derived class lookup when needed. This provides the ability to reference a base class and actually retrieve instances of sub classes. Yes, I forgot to mention that. But IMHO this does not add anything "new" to the kernel, becausethis information could be looked up by reflection at deployment time and is there for convenience purposes. When building polymorphic structures in Queries and Relationsships as the default,with noneed to look at the same entity from differently abstract "views", i.e., nodes in the class hierarchy,programmatic conversion would IMHO not be necessary (e.g., we make no use of it), but that´s certainly not generalizable. There is a performance problem with the queries on base classes. The brute force approach of firing tables x filters queries can kill performance with as little as three sub classes. This occurs mostly with queries involving non trivial joins. I don't have a general solution, but it's something to keep in mind. We havn´t yet had any serious performance problem maybe because we did not have these non-trivial joins? Could you give me an example of such a three-class constellation, please?My small mindcan only think of issues where trying to be smarter than brute force, hencecombining the queries for several class structures into one would result innon-trivial statements that confuse the database ...Firing a set of queries instead should give you just aconstant overhead, shouldn´t it? The real issuecould IMHO come due to a lacking indexing of the FILTER, because this attributewill be used quitefrequently toclearly discriminate the separate result sets in this approach ... Dr. Jung alluded to mappings of a single object to multiple tables. I agree that these are not difficult to implement. The join conditions need to be added to any queries involving the class. The question of how hard it would be is dependent on exactly what features are required. To implement all the features of a product like VBSF would be hard. If we limit it to just allowing inheritance, it would be manageable. I haven't studied the existing cmp code yet, so I probably cannot answer David's original question.So my conclusion was that given the last point of single-object to multiple tables (which also solves the inheritance mapping), the brute-force method which I do not find too bad as a starting point, and some restrictions on mappings for referred classes, it should not be too hard to extend an existing non-polymorphic engine without performance drawbacksfor the standard mappings (without having completely looked through the cmp code in detail). Jung , Dr. Christoph wrote: [EMAIL PROTECTED] type="cite">David, Dain, othersCurrently, we use a JCA/JDO adapter built around the OR-mapper VBSF(http://www.objectmatter.com) that supports such a thing. I must admit that our application programmers make extensiv use ofpolymorphism at this level. They do it not for accident, but for realmodelling advantages which will give us a lot of headaches when doing theplanned transition to EJB2.0. Hence before I say something technically, Ithink we would be willing of dedicating resources to help with this feature... Interestingly, VBSF´s kernel representations (we bought the source, too;-)are not polymorphism- or subclassing-aware. The only "advanced" things thatthe kernel is able to do is to A) spread the attributes of a class into several (id-linked) tables and jointhem correctly together andB) manage a "FILTER" attribute that fo r each entity determines the mostspecific java class that the entity is an instance of (via hashcode, plaintext, or other things).The polymorphism feature can then be added quite like decorators (orproxies, pattern terminology is hard these days) around the "monomorphism"implementation: 1) extent queries. Instead of querying a single "table", you want to queryall (tables x FILTER) combinations of the given class and the subclasses.Not hard to implement when doing it over separate statements except when itcomes to ordering (which must now be done partially in-memory andconsistently with the db ordering).2) relationships. Requires that the referenced super class has a dedicatedtable (hence is not "abstract" in the db sense). When navigating, firstcollect the (id´s x FILTER) of the referenced objects, then batch read thevalues for each class whose
[JBoss-dev] Java is not dead! *was* AW: [jboss-group] Bug 4670071 Updated: java.lang.ClassLoader.loadClassInternal(String) is too restrictive
Juha, This is extremely good news as SUN seems to have accepted two bug-requests at the same time. Let´s see how they resolve it ... CGJ -Ursprüngliche Nachricht- Von: Juha-P Lindfors [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 21. Juni 2002 13:50 An: [EMAIL PROTECTED] Betreff: [jboss-group] Bug 4670071 Updated: java.lang.ClassLoader.loadClassInternal(String) is too restrictive x@x 2002-06-20 This needs to be considered a valid bug - the classloader objects cannot remain locked, as demonstrated in bug 4699981, where a ClassCircularityError is thrown. This is due to the VM being confused about which thread is loading which class when the classloader lock got given up by a user classloader. Since the user can give up the classloader lock, we can't guarantee that the lock holds, we should not depend on the lock. The test case in 4699981 should be used here. ___ jboss-group mailing list [EMAIL PROTECTED] https://secure.jboss.org/mailman/listinfo/jboss-group ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] AxisService behavior is questionable
Hi Scott, The reason was that I wanted the security context under which the transport servlet is deployed (and I suspect there will be further such issue in the future) to be a configurable parameter of the AxisService. Hence, I must generate the jboss-web.xml at runtime. I could easily populate the ucl in the deploymentinfo as it should be the classloader of the AxisService itself. Or is there another way of doing it? Thanks, CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 31. Mai 2002 07:07 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] AxisService behavior is questionable The mechanism by which the AxisService registers its service is questionable as instead of including a war with the required config it is explictly creating a DeploymentInfo object for the war and calling the web deployer. This broke when I made a change to use the DeploymentInfo.ucl as the web context parent class loader because the AxisService was not populating this. What is the reason for not bundling a war in the jboss-net.sar instead of the current behavior? Scott Stark Chief Technology Officer JBoss Group, LLC ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] AxisService behavior is questionable
That is a cool tip. I will do that as soon as I do my next commits. CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 31. Mai 2002 17:25 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] AxisService behavior is questionable I have already updated the AxisService to populate the deployment ucl value so its working for now. I think a better way to handle a dynamic security domain would be to create a war with a security-domain like security-domainjava:/axis/securityDomainFactory/security-domain and have the AxisService bind a LinkRef from java:/axis/securityDomainFactory to the name of the configured security domain. I think we will continue to have issues keeping the building of a war DeploymentInfo in synch with what happens in the other deployers. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jung , Dr. Christoph [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 31, 2002 1:00 AM Subject: AW: [JBoss-dev] AxisService behavior is questionable Hi Scott, The reason was that I wanted the security context under which the transport servlet is deployed (and I suspect there will be further such issue in the future) to be a configurable parameter of the AxisService. Hence, I must generate the jboss-web.xml at runtime. I could easily populate the ucl in the deploymentinfo as it should be the classloader of the AxisService itself. Or is there another way of doing it? Thanks, CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 31. Mai 2002 07:07 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] AxisService behavior is questionable The mechanism by which the AxisService registers its service is questionable as instead of including a war with the required config it is explictly creating a DeploymentInfo object for the war and calling the web deployer. This broke when I made a change to use the DeploymentInfo.ucl as the web context parent class loader because the AxisService was not populating this. What is the reason for not bundling a war in the jboss-net.sar instead of the current behavior? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Sun has just reacted to our RFE-4670071 ...
Title: Nachricht ... ok, they sort of reacted ... Evaluation x@x 2002-05-28 We will revisit this decision (from bug 4406709). 563 votes is not enough! Let them state Evaluation x@x 2002-05-28 We will revisit this decision (from bug 4406709). x@x 2002-06-01 You are sooo right. We will remove the method altogether and call the synchronized loadClass from the VM immediately. And by the way, JBoss rocks ! http://developer.java.sun.com/developer/bugParade/bugs/4670071.html Thanks Juha for pointing to this! CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
AW: [JBoss-dev] Anyone doing https in JBoss using jsse ?
Great, Thanks scott. F*ck Class.forName()! CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 8. Mai 2002 08:49 An: 'Jboss-Development' Betreff: Re: [JBoss-dev] Anyone doing https in JBoss using jsse ? This is done in now in the 3.0 and head branches. The URLStreamHandlerFactory completely overrides the URL class protocol handler mechanism since it now handles the package prefixes specified via the java.protocol.handler.pkgs system property. There is a testcase service that demonstrates the use of the https url using the jsse classes as loaded from the JBoss lib directory. Scott Stark Chief Technology Officer JBoss Group, LLC snip However, the JBossURLStreamHandlerFactory currently expects all protocols to be implemented under org.jboss.net.protocol.xxx and we would need to extend that access with reading the System.getProperty(java.protocol.whatever.)+|org.jboss.net.protocol, parsing the string and trying to find the first class matching packagePrefix+.protocol+.+Handler /snip ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] getContextClassLoader() vs. Class.forName(x,y,z)
That is true, arrays are not constructed by loadClass() calls.
Class.forName() does
it, but has this ugly and uneblievably stupid in-VM cache.
Maybe a solution would be to have a surrogate method that does array
construction but does not rely
on Class.forName, like this
not at all tested, rapidly hacked and not checked for performance piece of
code
package org.jboss.util;
public class Clazz {
public static Class forName(String bla) throws WhateverException {
if(bla.endsWith([];)) {
Class
componentClass=forName(bla.substring(0,bla.length()-3));
return
java.lang.reflect.Array.newInstance(componentClass,0).getClass();
} else {
return
Thread.currentThread().getContextClassLoader().loadClass(bla);
}
}
CGJ
-Ursprüngliche Nachricht-
Von: marc fleury [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 3. Mai 2002 05:00
An: Hiram Chirino; [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] getContextClassLoader() vs. Class.forName(x,y,z)
makes no sense to me, ask for clarification and example
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Hiram Chirino
|Sent: Thursday, May 02, 2002 7:30 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] getContextClassLoader() vs. Class.forName(x,y,z)
|
|
|Question for you classloading feaks out there, what is the difference
|between:
|
|x = some.class.name;
|Thread.currentThread().getContextClassLoader().loadClass(x);
|
|and
|
|x = some.class.name;
|Class.forName(x, false,
| Thread.currentThread().getContextClassLoader());
|
|Peter Levart, submitted a patch that replaces a statment like the
|first with
|a statment like the seconds. It's supposed to allow loading
|array class for a base class that hasn't been loaded yet.
|
|My thing is, it seems like they do the same thing. What's the
|difference?
|
|Regards,
|Hiram
|
|_
|Chat with friends online, try MSN Messenger: http://messenger.msn.com
|
|
|___
|
|Have big pipes? SourceForge.net is looking for download mirrors. We
|supply the hardware. You get the recognition. Email Us:
|[EMAIL PROTECTED]
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Anyone doing https in JBoss using jsse ?
Peter, The static java.net.URL.setURLStreamHandlerFactory() should be called only once throughout the whole lifecycle of the VM to register the factory for ALL urls. As I suppose from the code, this is already done ... So your URL constructor in UDDI4J already uses it! However, the JBossURLStreamHandlerFactory currently expects all protocols to be implemented under org.jboss.net.protocol.xxx and we would need to extend that access with reading the System.getProperty(java.protocol.whatever.)+|org.jboss.net.protocol, parsing the string and trying to find the first class matching packagePrefix+.protocol+.+Handler It´s still early and the lingual part of brain is still sleeping. Does this make sense? CGJ -Ursprüngliche Nachricht- Von: Peter Braswell [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 3. Mai 2002 02:43 An: Jung , Dr. Christoph; 'David Jencks' Cc: 'Jboss-Development' Betreff: RE: [JBoss-dev] Anyone doing https in JBoss using jsse ? BoyZ, This sounds good to me. UDDI4J creates a URL() object inside the constructor. The below Handler factory sounds like the ticket, however it doesn't work around the problem that the URL object is created inside the constructor of the UDDIProxy() object. My thougts: extend the proxy jimmie (JBossUDDIProxy():?) which uses the new-fangled Hander factory... blah, blah, blah. So... NOT rewrite of UDDI4J, just using a little crowbar to coax in some new behavior... cheers, peter -Original Message- From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 12:25 PM To: 'David Jencks'; '[EMAIL PROTECTED]' Cc: 'Jboss-Development' Subject: AW: [JBoss-dev] Anyone doing https in JBoss using jsse ? Yak, I knew there would be such a beast ;-) Do you or Jason or anyone mind not using the f**cked up Class.forName() in there? It´s really f*cked up ... there must be a cache inside the VM doing weird things to break hot-deploying of such loaded classes, I have a few examples to prove it. Could we add the java.protocol.bla property parsing in there, please? Then jsse handlers could be easily created through it, too. Peter, you could have a look at that promising approach instead of having to rewrite UDDI4J for fitting into JBoss ;-) Thx guys, CGJ -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 2. Mai 2002 18:03 An: Dan Christopherson Cc: Jung , Dr. Christoph; 'Jboss-Development' Betreff: Re: [JBoss-dev] Anyone doing https in JBoss using jsse ? How about the existing org.jboss.net.protocol.URLStreamHandlerFactory david jencks On 2002.05.02 11:12:55 -0400 Dan Christopherson wrote: Jung , Dr. Christoph wrote: Hi there, snip / *Bummer* I´m thinking about that classloading stuff ALL THE TIME. There must be something else in Java than classloading. *Sigh* I have faith that once enough of the JDK has been rewritten for classloading to actually work right, we'll find something else ;^}) Now we have a workaround, but we do not want to type new URL(https,localhost,42,myFile,new com.sun.net.ssl.internal.www.protocol.https.Handler()) and right. gack. depending our code agains jsse.jar instead of simply writing new URL(https://localhost:42/myFile;). Has anyone already seen this problem and knows how to resolve it? Should we write and install a JBoss-specific URLStreamHandlerFactory in the spine such that we can do the protocol extensions by ourselves and using Thread.currentThread().getContextClassLoader().loadClass() approach once for all modules? org.jboss.util.URLStreamHandlerFactoryThatLoadsTheDamnClassesRight ? I'd imagine it'll be needed in other places, too. -danch ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Anyone doing https in JBoss using jsse ?
Title: Nachricht
Hi
there,
in the jboss.net
module, wecurrently play around with establishing secure https access to
remote UDDI registries.
Unfortunately, we
seem to have problems installing the https handlers inside the jsse.jar in
the default URL.getStreamHandler(String protocol) logic.
We do
-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocolat
startup, but we get a no such protocol inside our jboss-.net.sar each
time
which I contribute
to a f**cked up Class.forName() call in the getStreamHandler() method seeking
for the damned classes just inside the rt.jar.
*Bummer* I´m
thinking about that classloading stuff ALL THE TIME. There must be something
else in Java than classloading. *Sigh*
Now we have a
workaround, but we do not want totype new
URL("https","localhost",42,"myFile",new
com.sun.net.ssl.internal.www.protocol.https.Handler()) and
depending our code
agains jsse.jar instead of simply writing new URL("https://localhost:42/myFile").
Has anyone
alreadyseen this problem and knows how to resolve it?
Should we
write and install a JBoss-specific URLStreamHandlerFactory in the spine such
that we can do the protocol extensions by ourselves and using
Thread.currentThread().getContextClassLoader().loadClass() approach once for all
modules?
CGJ
AW: [JBoss-dev] Anyone doing https in JBoss using jsse ?
Yak, I knew there would be such a beast ;-) Do you or Jason or anyone mind not using the f**cked up Class.forName() in there? It´s really f*cked up ... there must be a cache inside the VM doing weird things to break hot-deploying of such loaded classes, I have a few examples to prove it. Could we add the java.protocol.bla property parsing in there, please? Then jsse handlers could be easily created through it, too. Peter, you could have a look at that promising approach instead of having to rewrite UDDI4J for fitting into JBoss ;-) Thx guys, CGJ -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 2. Mai 2002 18:03 An: Dan Christopherson Cc: Jung , Dr. Christoph; 'Jboss-Development' Betreff: Re: [JBoss-dev] Anyone doing https in JBoss using jsse ? How about the existing org.jboss.net.protocol.URLStreamHandlerFactory david jencks On 2002.05.02 11:12:55 -0400 Dan Christopherson wrote: Jung , Dr. Christoph wrote: Hi there, snip / *Bummer* I´m thinking about that classloading stuff ALL THE TIME. There must be something else in Java than classloading. *Sigh* I have faith that once enough of the JDK has been rewritten for classloading to actually work right, we'll find something else ;^}) Now we have a workaround, but we do not want to type new URL(https,localhost,42,myFile,new com.sun.net.ssl.internal.www.protocol.https.Handler()) and right. gack. depending our code agains jsse.jar instead of simply writing new URL(https://localhost:42/myFile;). Has anyone already seen this problem and knows how to resolve it? Should we write and install a JBoss-specific URLStreamHandlerFactory in the spine such that we can do the protocol extensions by ourselves and using Thread.currentThread().getContextClassLoader().loadClass() approach once for all modules? org.jboss.util.URLStreamHandlerFactoryThatLoadsTheDamnClassesRight ? I'd imagine it'll be needed in other places, too. -danch ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] [JL] Is it time for a new enterprise solution?
He, he. Volunteers? In the meantime, I heard from my colleagues who had actually done some MMC programming that it would be a real nightmare indeed :-( So much for expectations. Wonder if VS.net makes it more handy ... CGJ -Ursprüngliche Nachricht- Von: marc fleury [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 26. April 2002 16:53 An: Christian Riege Cc: Sacha Labourey; Juha-P Lindfors; JBoss Dev list Betreff: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? interesting, let's see what becomes real. I like the idea of the MS console plugin marcf |-Original Message- |From: Christian Riege [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 7:43 AM |To: marc fleury |Cc: Sacha Labourey; Juha-P Lindfors; JBoss Dev list |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |hi, | | 5- gui? pf it would need to be a JMX gui in our case, why not, | but everybody talks about these and no-one does jack. | |i think what Dr. Jung mentioned @ JBossOne would be a killer: expose |the MBeans via SOAP and construct a Microsoft Management Console Plugin |to configure/maintain JBoss from that beast. | |other than that, my 2 (albeit euro) cents on the subject of the config |files: | |i don't give one cent on how the config file looks like (i.e. XML, |key=value, ...) AS LONG AS I CAN EDIT IT WITH MY TEXT-EDITOR OF CHOICE. | |consolidation/deconsolidation of the configuration has its own pros and |cons. personally i would like to have both available: small files for |development/testing purposes (un-deploy of an MBean by simply issuing |'mv mbean.jar ../nodepoy') and one huge file for locking down my |production servers. | |i *think* you can achieve both by using several XML files which can be |merged (at the users option, with a *simple* command) into one big XML |file: develop/test with the small ones until you're happy. hit the |lockdown config button. get a large file which is the sum of the |small ones. xml namespaces might come in handy here?! | |rgds, | christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 528 votes and 4th place in the TOP25!
Title: Nachricht This is theregular, non-automizedbug-voting reminder for those of you who haven´t pulled up their asses yet to visit JDC at: http://developer.java.sun.com/developer/bugParade/bugs/4670071.html (all others, great effort, we will make it number #1). FYI: ThisRFE tries to convince SUN to take one of these nasty modifiers fromthe java.lang.ClassLoader.loadClassInternal(String) method which would allow us to remove a whole lot of ugly and imperformant (though, I must say, genius!) deadlock-avoiding code fromsome of the core classes of JBoss3.x (and think about even more evil classloading models for JBoss4 ;-) CGJ
AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Strike!
CGJ
-Ursprüngliche Nachricht-
Von: Alarik Myrin [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 25. April 2002 06:24
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
WAIT! EVERYTHING WORKS FINE!
Don't i feel like a dumb ass. Although I got the new code and built it,
when I went to copy the jars to the directory that I usually run out of
(don't ask...bad habits are hard to break), somehow the jboss-jmx-core.jar
and jboss-jmx-services.jar were still in the directory from when i built the
3.0.0RC1 release (they don't seem to get built with the MAIN branch of the
code). So the wrong version of the classes were being loaded in (ironic,
don't you think?) The line numbers in the stack traces should have given it
away hours ago. well, at least it's given me a chance to review the fix,
and i have to say: very nice. if i had to spend all night chasing down a
bug that wasn't there, at least i learned something.
Sorry if I scared anybody, or wasted anybody's time...
alarik
-Original Message-
From: Alarik Myrin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 8:22 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Alas, I am getting a little further, but still getting a deadlock.
Below please find the relavent stack traces. Here is my take on what
they might mean, in case it is interesting to you:
There are two relavent threads. One (the first stack trace) is trying
to load a class needed by a stateless session bean in an effor to
deploy the bean. The class does not exist in the bean's jar file,
instead it exists in a another archive called picasso.zip. The other
(the second stack trace), was spawned by a class found in picasso.zip.
It is trying to load a class from (I suspect) a third party jar file
called osji.jar. Because there is a seperate class loader for each
archive, the deadlock becomes possible. Does this sound right? (I am
not really an expert at class loading, but learning as I go :).
What makes this problem quite tricky (it seems to me) is that in both
threads the UnifiedClassLoader instance is _already locked_ by the
time _any_ of its methods are even executed.
What about this: instead of
/**
* We intercept the load class to know exactly the dependencies
* of the underlying jar.
*
* pForwards request to {@link UnifiedLoaderRepository}.
*/
public Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized(this)
{
return repository.loadClass(name, resolve, this);
}
}
What if we did this:
/**
* We intercept the load class to know exactly the dependencies
* of the underlying jar.
*
* pForwards request to {@link UnifiedLoaderRepository}.
*/
public Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized(this.getClass())
{
return repository.loadClass(name, resolve, this);
}
}
Another observation: startup appears to be taking noticably longer
than it did with JBoss 2.4.x, even in parts of the startup process
where I suspect it is mostly just executing my code. The CPU just
spikes like crazy. Whenever I do a thread dump to check what it is up
to, it always appears to be trying to load a class. Startup time
isn't the most important thing in the world, but it does impact the
speed of development (although I suspect that if I really understood
the power of the deploy/undeploy functionality of JBoss 3, I wouldn't
need to restart the server nearly so often...).
Anyway, I hope all of this helps. I'll be available all week to run
any tests you'd like, but then I start traveling for almost a month...
Alarik
main prio=5 tid=0xc7d640 nid=0x157 waiting for monitor entry
[0x93fd000..0x93ffdc0]
at java.lang.ClassLoader.loadClass(ClassLoader.java:286)
- waiting to lock 3329c48 (a
org.jboss.mx.loading.UnifiedClassLoader)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCl
assLoader.java:180)
at
org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoad
erRepository.java:178)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoad
er.java:217)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
- locked 330edc0 (a org.jboss.mx.loading.UnifiedClassLoader)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:195)
at com.odi.ClassInfo.lookupClassInfoByName(ClassInfo.java:608)
at com.odi.ClassInfo.lookupClassInfoByName(ClassInfo.java:589)
at com.odi.ClassInfo.findAndRegister(ClassInfo.java:502)
at com.odi.ClassInfo.get(ClassInfo.java:483)
AW: [JBoss-dev] Re: [JBoss-user] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word!
Yes, that´s what the deadlock (hopefully) was about ... two threads loading classes simultaneously ... I think that Marc now has a promising (and ingenious, I didn´t think about the synchronized - synchronized() relation the whole time!) workaround. CGJ -Ursprüngliche Nachricht- Von: Alarik Myrin [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 23. April 2002 19:16 An: marc fleury; [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] Re: [JBoss-user] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word! Also (and I don't know what significance this might have), but if I DON'T spawn another thread I don't get the deadlock. If I DO spawn another thread, I get the deadlock consistently. Alarik ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
I hope this patch will also meet your scenario of having 2 threads coming through a single UnifiedClassLoader ... http://sourceforge.net/tracker/index.php?func=detailaid=548098group_id=228 66atid=376687 Weird, CGJ -Ursprüngliche Nachricht- Von: Dave Smith [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 24. April 2002 13:45 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock Well my simple test cases worked but I pulled out the heavy hitters and managed to get a dead lock. Stack traces follow ... Thread-23 prio=5 tid=0x81a4f60 nid=0x69cb waiting on monitor [0xbe7fe000..0xbe7ffad8] at java.lang.Object.wait(Native Method) - waiting on 43a28660 (a org.jboss.mx.loading.UnifiedLoaderRepository) at java.lang.Object.wait(Object.java:420) at org.jboss.mx.loading.UnifiedLoaderRepository.sync(UnifiedLoaderRepository.ja va:717) - locked 43a28660 (a org.jboss.mx.loading.UnifiedLoaderRepository) at org.jboss.mx.loading.UnifiedLoaderRepository.releaseLock(UnifiedLoaderReposi tory.java:313) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito ry.java:261) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:21 7) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) - locked 43f72c18 (a org.jboss.mx.loading.UnifiedClassLoader) at iaik.security.cipher.j.a(RawCipher.java) at iaik.security.cipher.n.a(RawBlockCipher64.java) at iaik.security.cipher.r.engineInit(BufferedCipher.java) at javax.crypto.Cipher.init(Cipher.java) at iaik.pkcs.pkcs7.SignerInfo.encodeCalled(SignerInfo.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.SET.encode(SET.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.CON_SPEC.encode(CON_SPEC.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.ConstructedType.encode(ConstructedType.java) at iaik.asn1.ASN1Object.encodeObject(ASN1Object.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.a(DerCoder.java) at iaik.asn1.DerCoder.encode(DerCoder.java) - locked 441342d0 (a iaik.asn1.SEQUENCE) at iaik.asn1.DerCoder.encodeTo(DerCoder.java) at iaik.asn1.DerCoder.encodeTo(DerCoder.java) at iaik.pkcs.pkcs7.ContentInfoStream.writeTo(ContentInfoStream.java) at com.entrust.toolkit.a.run(PKCS7EncodeStream.java) at java.lang.Thread.run(Thread.java:484) CCRAPoll prio=5 tid=0x81b3940 nid=0x69b4 waiting for monitor entry [0xbb5ff000..0xbb5ffad8] at org.jboss.mx.loading.UnifiedLoaderRepository.lock(UnifiedLoaderRepository.ja va:283) - waiting to lock 43f72c18 (a org.jboss.mx.loading.UnifiedClassLoader) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito ry.java:156) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:21 7) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.security.Security.getImpl(Security.java:815) at java.security.Signature.getInstance(Signature.java:172) at iaik.x509.X509CRL.verify(X509CRL.java) at iaik.x509.X509CRL.verify(X509CRL.java) at com.entrust.toolkit.x509.revocation.X509CRLRS.validateCRL(X509CRLRS.java) at com.entrust.toolkit.x509.revocation.CachedCRLRS.loadCRLs(CachedCRLRS.java) - locked 437fbb80 (a com.entrust.toolkit.x509.revocation.CachedCRLRS) at com.entrust.toolkit.x509.revocation.X509CRLRS.findCRL(X509CRLRS.java) - locked 437fbb80 (a com.entrust.toolkit.x509.revocation.CachedCRLRS) at com.entrust.toolkit.x509.revocation.X509CRLRS.check(X509CRLRS.java) at com.entrust.toolkit.x509.revocation.CollectionRS.check(CollectionRS.java) at com.entrust.toolkit.x509.revocation.CollectionRS.check(CollectionRS.java) at com.entrust.toolkit.x509.certstore.c.a(Node.java) at com.entrust.toolkit.x509.certstore.c.a(Node.java) at
AW: [JBoss-dev] Are these CVS modules still in use anywhere?
I would appreciate deletion of ZOAP as an evidence of my once evil programming skills ;-) CGJ -Ursprüngliche Nachricht- Von: Jason Dillon [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 23. April 2002 04:31 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Are these CVS modules still in use anywhere? Does anyone know if the 'zoap' and 'zola' modules are still in use anywhere? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] AW: Workaround for CL stuff
As a quick work-around while I´m busy today with doing business (buaaeeeh:-( Patch the java.lang.ClassLoader class ... Either remove the synchronized keyword from loadClassInternal (should be safe) or make it protected and remove the synchronized keyword in an overriding method of UnifiedClassLoader (makes the build Depending on that patch, not that nice). Put the patched class in a patch.jar and start jboss With the option -Xbootclasspath/a:patch.jar Viola, CGJ -Ursprüngliche Nachricht- Von: marc fleury [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 22. April 2002 20:04 An: Jboss-Development@Lists. Sourceforge. Net Cc: Christoph Jung; sacha labourey Betreff: Workaround for CL stuff Ok, I am sure we can find something. I would appreciate a brief description of a CL deadlock scenario due to the final loadClassInternal. Jung? Sacha? It's only software, software is dumb marcf x Marc Fleury, Ph.D President and CEO JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] AW: Workaround for CL stuff
Of course, it must prepend the JDK-shit, sorry did cutpaste from the Tool-Doc ... CGJ -Ursprüngliche Nachricht- Von: Holger Engels [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 23. April 2002 11:09 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] AW: Workaround for CL stuff On Tue, 23 Apr 2002, Jung , Dr. Christoph wrote: As a quick work-around while I´m busy today with doing business (buaaeeeh:-( Patch the java.lang.ClassLoader class ... Either remove the synchronized keyword from loadClassInternal (should be safe) or make it protected and remove the synchronized keyword in an overriding method of UnifiedClassLoader (makes the build Depending on that patch, not that nice). Put the patched class in a patch.jar and start jboss With the option -Xbootclasspath/a:patch.jar did you mean -Xbootclasspath/p:patch.jar ? Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Workaround for CL stuff
Actually, it´s more complicated: Thread 1: VM detects that it needs bar, calls UCL A.loadClassInternal() and hence synchronizes on A Thread 2: VM detects that it needs foo, calls UCL B.loadClassInternal() and hence synchronizes on B Thread 1: UCL A delegates to Repository delegates to UCL B, LOCKED Thread 2: UCL B delegates to Repository delegates to UCL A, LOCKED CGJ -Ursprüngliche Nachricht- Von: lsanders [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 22. April 2002 20:29 An: Jboss-Development@Lists. Sourceforge. Net Betreff: Re: [JBoss-dev] Workaround for CL stuff Though I've never experienced this, I think this is the problem scenario: The players: UnifiedClassLoader A (can load directly class foo) UnifiedClassLoader B (can load directly class bar) Thread 1 (context loader is A): Load new class bar: - synchronize on UCL A - Search UCL B - Attempt to synchronize on UCL B Thread 2 (contect loader is B): Load new class foo: - synchronize on UCL B - Search UCL A - Attempt to synchronize on UCL A Can someone verify if this is accurate? -Larry Ok, I am sure we can find something. I would appreciate a brief description of a CL deadlock scenario due to the final loadClassInternal. Jung? Sacha? It's only software, software is dumb marcf x Marc Fleury, Ph.D President and CEO JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Workaround for CL stuff
AFAIK, a thread will only release the lock in the closest synchronization scope. If you can make sure that the UCL itself is the last lock before entering ULR, then it should IMHO work. Since we are not in control of loadClassInternal, but of loadClass, there is the chance that this will do as wished. CGJ -Ursprüngliche Nachricht- Von: marc fleury [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 23. April 2002 03:07 An: Dave Smith Cc: lsanders; Jboss-Development@Lists. Sourceforge. Net Betreff: RE: [JBoss-dev] Workaround for CL stuff Solution: When a thread goes through loadClass, in the ULR we lock with a field that tracks the thread. Another thread comes in, reaches ULR, we sync on the calling CL (we know it) we wait, this releases the lock, we keep track of the CL as part of this load. The first thread will always find a CL as no CL can be locked for ever, since the thread that would reach the ULR would wait. First thread always finishes (with reentrancy so the count must go on and we track the fact that it is the same thread). When count reaches 0 we get the set of CL that were touched by this thread (i.e. the set of CLs that had threads in it) and we notifyAll on each element of the set, start this again. Done (afaict), I will try to apply it to the stack trace below. |I brought this thing back to life and passed the URL of the orginal sun |bug that they rejected. Here is a quick stack trace of the deadlock. |Note that you should start jboss with the -Xdebug options so it shows |you what objects that it is trying to lock. See below for my orginal |post | | |CCRAPoll prio=5 tid=0x8184f58 nid=0x64ec waiting for monitor entry |[0xbb7fe000..0xbb7ffad8] |at java.lang.ClassLoader.loadClass(ClassLoader.java:288) |- waiting to lock 43a2c508 (a |org.jboss.mx.loading.UnifiedClassLoader) |at |org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla ssLoader.java:180) |at |org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade rRepository.java:178) This one would reach ULR and lock the ULR, see below for lock 43a2c508 NOT being locked. |at |org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade |r.java:217) |at java.lang.ClassLoader.loadClass(ClassLoader.java:255) |at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) |- locked 43eefa48 (a org.jboss.mx.loading.UnifiedClassLoader) |at |com.entrust.toolkit.PKCS7EncodeStream.e(PKCS7EncodeStream.java) |at |com.entrust.toolkit.PKCS7EncodeStream.f(PKCS7EncodeStream.java) |at |com.entrust.toolkit.PKCS7EncodeStream.write(PKCS7EncodeStream.java) |at com.candata.gateway.Encryption.Sign(Unknown Source) |- locked 43f0c6a0 (a com.candata.gateway.Encryption) |at com.candata.gateway.Encryption.createMsg(Unknown Source) |at com.candata.gateway.CCRAAbstract.postMsg(Unknown Source) |at com.candata.gateway.CCRAAbstract.recvMsg(Unknown Source) |at com.candata.gateway.CCRAPoll.run(Unknown Source) |at java.lang.Thread.run(Thread.java:484) | | |Thread-20 prio=5 tid=0x81821a8 nid=0x64f9 waiting for monitor entry |[0xbe7fe000..0xbe7ffad8] |at java.lang.ClassLoader.loadClass(ClassLoader.java:288) |- waiting to lock 43eefa48 (a |org.jboss.mx.loading.UnifiedClassLoader) |at |org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla ssLoader.java:180) |at |org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade rRepository.java:178) thread 2 reaches here and sees a ULR under usage. It waits on the calling UCL (which we know it is passed) and THEREFORE UNLOCKS 43a2c508. Done marcf |at |org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade |r.java:217) |at java.lang.ClassLoader.loadClass(ClassLoader.java:255) |at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) |- locked 43a2c508 (a org.jboss.mx.loading.UnifiedClassLoader) |at java.lang.Class.forName0(Native Method) |at java.lang.Class.forName(Class.java:195) |at |javax.security.auth.login.LoginContext.invoke(LoginContext.java:626) |at |javax.security.auth.login.LoginContext.access$000(LoginContext.java:129) |at |javax.security.auth.login.LoginContext$4.run(LoginContext.java:599) |at java.security.AccessController.doPrivileged(Native Method) |at |javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:596) |at |javax.security.auth.login.LoginContext.login(LoginContext.java:523) |at com.candata.util.beans.CandataClientLogin.login(Unknown |Source) |at com.candata.bbxinterface.BbxJavaInvoker.login(Unknown Source) |at com.candata.bbxinterface.BbxWrapper.run(Unknown Source) |at java.lang.Thread.run(Thread.java:484) marcf ___ Jboss-development mailing
[JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ahead ...
Title: Nachricht Ilet it be recatecorizedunder RFE. Now we are in the Top25! The shown ranking is slightly behind the actual votes (414!). We should be 6th place now. http://developer.java.sun.com/developer/bugParade/top25rfes.html You are a great bunch of Java connaisseurs ;-) Go ahead, tell your grandma to give her three votes! http://developer.java.sun.com/developer/bugParade/bugs/4670071.html CGJ
[JBoss-dev] We got now 183 votes for Bug/Eou 4670071 ... But you can surely do better!
Title: Nachricht Thanks for the massive support of this IMPORTANT, IMPORTANT issue...IfSun(TM) would count the Eou section in their TOP-Bug list, we would be IMHO already in the upper half. But let´s be sure about this! Don´t let them assign some freshman on this bug! Make it a prime matter to them! If you or your Mum or your sisterhave not yet voted, this is a reminder to do so! This is similar to not going tothe elections. It´s not your right ... it´s your duty as a responsible Java geek! Vote now! http://developer.java.sun.com/developer/bugParade/bugs/4670071.html CGJ
AW: [JBoss-dev] jboss.net tests
Hmm, well ... Problem is that we introduce a lot of additional dependencies (Axis, wsdl4j, commons-logging, tt-bytecode, etc.) on the testsuite then. Problem is that we would have to make jboss.net a standard-module, but honestly we are behind the main release cycle: If everything goes ok, we will be alpha in a few weeks because we still need to write a decent docu ... Currently, there are a few users out there and two main people (peter braswell and me) doing the tests on a regular basis and before each checkin. The tests do IMHO not really test critical things inside the core, but just for our module. They need to have the core to be stable, of course and that was quite problematic over the recent two or three month ... but improved drastically during the recent consolidation period. If you want to remodularize the testsuite anyway, then maybe it would be too much effort to get the whole stuff integrated now ... I really hope to get that alpha out ASAP to get the awareness for the module growing. If you decide to have it integrated, though, please count me in to help out. CGJ -Ursprüngliche Nachricht- Von: Jason Dillon [mailto:[EMAIL PROTECTED]] Gesendet: Samstag, 20. April 2002 03:28 An: David Jencks Cc: jboss-dev Betreff: Re: [JBoss-dev] jboss.net tests I would lean twords moving them into jboss/testsuite for now (even though we might move some back into per module testsuites once I get that figured out). --jason David Jencks wrote: I see there are some jboss.net tests in the jboss.net module, but none in the testsuite that I can find. If these compile, can we add them to the testsuite? If they break, maybe lots of people will see this and fix them and jboss.net. I think testing will significantly improve the visibility of this project. thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Re: [JBoss-user] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word!
I just asked the responsible guy at SUN why it doesn´t show up on any of the TOP lists ... In case that EOU´s are not RFE´s, I asked him to change the status such that we will show up. Let´s see. Continue voting! Hi,Hi CGJ -Ursprüngliche Nachricht- Von: Randall Parker [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 22. April 2002 08:14 An: Corby; [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] Re: [JBoss-user] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word! No, it would show up on the RFE list, not the bug list. Sun classified it as: State In progress, ease-of-use enhancement Doesn't that mean it shows on the RFE list? Then it would show at position 12 at the moment since I just gave it the 180th vote. Yes, Sun is very slow about updating that list. I've seen it not be updated for a week or two at a time. On Sun, 21 Apr 2002 17:57:50 -0500, Corby wrote: Hmmm... Sun claims that their Top 25 bugs page is updated daily, but our bug still hasn't cracked the top 25 today. As a matter of fact, if they updated now we would be up at #8... Corby * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13431 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-user] AW: [JBoss-dev] Save the Rabbit Hole UnifiedClassLoaders - Vote a nd Argue at the BugParade! - Spread the Word!
It´s a rt.jar problem that happens on all platforms, now, and spuriously (because it´s a threading issue and Depends on when which classes are loaded!). CGJ -Ursprüngliche Nachricht- Von: Marius Kotsbak [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 19. April 2002 14:13 An: Jung , Dr. Christoph Cc: [EMAIL PROTECTED]; JBoss-dev; infor:21 Betreff: Re: [JBoss-dev] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word! Is this a Win32/1.3.1 - problem only, or is it the same for linux? Is it something that jboss has a problem with now (how often does it happen?), or something that isn't implemented because of this. ( 1 voted 3 votes on this, I think :-) Marius On fre, 2002-04-19 at 12:41, Jung , Dr. Christoph wrote: Hi guys, as promised, I have refiled our spurious deadlock problem that comes from private synchronized Class java.lang.ClassLoader.loadClassInternal(String) in the Bug Parade under http://developer.java.sun.com/developer/bugParade/bugs/4670071.html http://developer.java.sun.com/developer/bugParade/bugs/4670071.html * If you feel you can add some explanations or code, please comment and convince them! * If you also think that this is an important change to make in the JDK (and you should when you are, as we, addicted to JBoss), please vote! * If you suspect that this topic is of relevance to other (Open Source) products, please forward this announcement to the relevant mailing lists such that we get the most pro-votes! * If you don´t care, SODs (suck our ... you know what I mean!). Maybe don´t be too harsh ;-) The only workaround is to violate the Byte-Code License with a patched class. This is really important! Let´s put the rule to the test! CGJ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Jar in sar policy; client deployment *was* AW: [JBoss-dev] Reason for castor?
I would highly appreciate that, we could have the upcoming jboss-net release in there two. While we are at it, I now put the axis.jar/wsdl4j.jar/tt-bytecode.jar/axis-config.xml into the jboss-net.sar not to potentially pollute the distro. However these libraries would also be needed by any Java-based client that likes to access Jboss via Jboss.net/SOAP ... Currently, they are not part of the jboss-net-client.jar and no more located under lib/ext. Is there any preferred place where to put them just for clients? Do we have any ideas about extended client deployment? Do we care at all? Thx CGJ -Ursprüngliche Nachricht- Von: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 17. April 2002 19:41 An: David Jencks Cc: JBoss-dev Betreff: Re: [JBoss-dev] Reason for castor? We should create an optional services directory in the download that could contain Castor, Tyrex, maybe Tomcat (then we get rid of the multiple download packages). -dain David Jencks wrote: On 2002.04.17 12:11:35 -0400 Dain Sundstrom wrote: Is there a reason why we ship with the castor jar in lib? Is it used internally by the server? definitely not. I removed it from the lib directory and everything seems to start correctly. If it's not required by the J2EE spec and is just an add-on, we should change it to an optional sar, or remove it entirely. The castor jar is over 1 MB in our 10 MB download. I strongly suspect the castor integration has to be completely rewritten for 3.0 We need a policy on stuff like this. Tyrex might be another example, although I think it is tested much more frequently. At least one person asked recently where the Castor integration stuff is. david jencks -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at theBugParade! - Spread the Word!
Title: Nachricht Hi guys, as promised, I have refiledour spurious deadlock problemthat comes fromprivate synchronized Class java.lang.ClassLoader.loadClassInternal(String) in the Bug Parade under http://developer.java.sun.com/developer/bugParade/bugs/4670071.html If you feel you can add some explanations or code, please comment and convince them! If you also think that this is an important change to make in the JDK (and you should when youare, as we,addicted to JBoss), please vote! If you suspect that this topic is of relevance to other (Open Source) products, please forward this announcement to the relevant mailing lists such that we get the most pro-votes! If you don´t care, SODs (suck our ... you know what I mean!). Maybe don´t be too harsh ;-) The only workaround is to violate the Byte-Code License with a patched class. This is really important! Let´s put the rule to the test! CGJ
AW: [JBoss-dev] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word!
It´s a rt.jar problem that happens on all platforms, now, and spuriously (because it´s a threading issue and Depends on when which classes are loaded!). CGJ -Ursprüngliche Nachricht- Von: Marius Kotsbak [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 19. April 2002 14:13 An: Jung , Dr. Christoph Cc: [EMAIL PROTECTED]; JBoss-dev; infor:21 Betreff: Re: [JBoss-dev] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word! Is this a Win32/1.3.1 - problem only, or is it the same for linux? Is it something that jboss has a problem with now (how often does it happen?), or something that isn't implemented because of this. ( 1 voted 3 votes on this, I think :-) Marius On fre, 2002-04-19 at 12:41, Jung , Dr. Christoph wrote: Hi guys, as promised, I have refiled our spurious deadlock problem that comes from private synchronized Class java.lang.ClassLoader.loadClassInternal(String) in the Bug Parade under http://developer.java.sun.com/developer/bugParade/bugs/4670071.html http://developer.java.sun.com/developer/bugParade/bugs/4670071.html * If you feel you can add some explanations or code, please comment and convince them! * If you also think that this is an important change to make in the JDK (and you should when you are, as we, addicted to JBoss), please vote! * If you suspect that this topic is of relevance to other (Open Source) products, please forward this announcement to the relevant mailing lists such that we get the most pro-votes! * If you don´t care, SODs (suck our ... you know what I mean!). Maybe don´t be too harsh ;-) The only workaround is to violate the Byte-Code License with a patched class. This is really important! Let´s put the rule to the test! CGJ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Old servlet.jar vs. jboss.net/jetty dependency?
Me too ;-) No objections against depending on jetty ;-) CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 18. April 2002 06:15 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] Old servlet.jar vs. jboss.net/jetty dependency? Yes. We shoould not even include the sun provided binary since we are building this from source. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Frederick N. Brier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 17, 2002 8:36 PM Subject: [JBoss-dev] Old servlet.jar vs. jboss.net/jetty dependency? I need to use the class javax.servlet.http.HttpServletRequestWrapper for the Flash/Axis servlet, but it can't be found in servlet.jar. Looking closer, I noticed that the build.xml for JBoss.net is referencing a servlet.jar in jboss-all/thirdparty/sun/servlet/lib. The files in the archive are dated 7/11/2000. The actual archive in the JBoss distribution is javax.servlet.jar which is a superset of the older archive, has the current build date, and the required file. The problem is that the javax.servlet.jar is built in the jboss-all/jetty/output/lib directory. So this would require modifying the root build.xml file to make the _module-jboss.net-most dependent on _module-jetty-most, and then modifying the build.xml [lines 91-94] in jboss-all/jboss.net to specify the javax.servlet.jar in the jetty output directory. Is this reasonable? Thank you. Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBoss.net idea for Macromedia Flash support
Frederik, Great vision, good analysis, nice solution. Think of animated puppet cartoons in Flash steered by a remote Jboss-story-server via SOAP ;-) I guess you proposed having a dedicated AxisService/PatchedAxisServlet for Flash (i.e. a customized jboss-net-service.xml that could be installed in addition to/alternatively the jboss-net.jar!META-INF/jboss-service.xml) ... This would finally justify the time I spent to allow several AxisEngines in jboss ;-) I have no objections putting another Servlet into the jboss-net.jar, because we could derive it from the existing one and redundancy should be minimal, right? Go ahead, post the stuff (maybe as a patch through sourceforge that is assigned to me such that I will be reminded ;-) and please report any success stories or problems that you encounter with jboss.net, such that we can ensure that the stuff is working for everyone! CGJ -Ursprüngliche Nachricht- Von: Frederick N. Brier [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 17. April 2002 09:26 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] JBoss.net idea for Macromedia Flash support Macromedia Flash 5 and Flash MX has XML support, but due to its limitations cannot generate the exact HTTP headers, specifically SOAPAction, required by SOAP. Flash is installed in over 98% of the browsers and provides a cross platform intelligent (Actionscript) client. In a user group presentation they alluded to a product that would be a Cold Fusion server to Flash client architecture with XML providing the glue. I think JBoss can beat them there with a few small mods to JBoss.net. The idea is to add a doPost() method to the JBoss.net AxisServiceServlet class. It would preprocess the HttpServletRequest headers using a massaging class specified via XML generating a HashMap. It would then wrap the original HttpServletRequest and the HashMap in a class derived from HttpServletRequestWrapper which overrides the getHeader methods. The new request object is passed to the parent's doPost() implementation - AxisServlet. Specifically for Flash, we could appear to move a SOAPAction and Content-Type parameters to the HTTP Header. I've already started writing this and would like to finish it and contribute it. I'm just not sure how to participate in the process, and need some feedback on whether this is desired, acceptable, and if so, where the massaging class should be specified. One issue is that we are violating the SOAP spec, but several products and work-a-rounds already exist, mostly for ASP. Specifying a massaging class allows us to support other hamstrung clients. We could also associate the massaging class with a url-pattern either in install-axis.xml, another extension to the Axis deployment descriptor in the application's web-service.xml file. The changes and additions are fairly small and I could just post them to the mailing list after I get some feedback and get it working. I think this is an important technology with which to interface. With the addition of Flash plug-in's encrypted sandbox, private keys can be stored on the client side and used for authentication in implementing security. Please let me know what you think. Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: AW: [JBoss-dev] Thread deadlock in class loader
Did you prepend the bootclasspath with the patched class using the Xbootclasspath/p:patch.jar option? CGJ -Ursprüngliche Nachricht- Von: Dave Smith [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 10. April 2002 23:22 An: Jung , Dr. Christoph Betreff: Re: AW: [JBoss-dev] Thread deadlock in class loader Seems like sun does not think it is a bug http://developer.java.sun.com/developer/bugParade/bugs/4406709.html Even if I patch the localClassInternal I still get an error. Looks like the class loader is internally locking the class loader because when I run with the -Xdebug option that shows be the locks, it is waiting for a lock that does not exsist in any of the threads. On Tue, 2002-04-09 at 03:35, Jung , Dr. Christoph wrote: Looks like you are a victim of the private synchronized localClassInternal-syndrom that is already known to us and that cannot be resolved except by SUN or by patching the JDK´s java.lang.ClassLoader (remove the synchronized at localClassInternal either by recompiling or by BCEL?) ... Happens very seldom, since most of the classloading happens in one thread at app-startup. Ok, maybe now I will file a bug at SUN ... CGJ -Ursprüngliche Nachricht- Von: Dave Smith [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 8. April 2002 17:43 An: Jboss-Development@Lists. Sourceforge. Net Betreff: [JBoss-dev] Thread deadlock in class loader I have a strange deadlock problem between two threads that are completely unrelated. Could some-one point me in the right direction to solve this problem. Here are the two threads in question .. The first one ins accessing thrid party jars and the second one is trying to look up an entity bean and is getting hung up in the jaas security. CCRAPoll prio=5 tid=0x87000d0 nid=0x943 waiting for monitor entry [0xbb7fe000..0xbb7ffad8] at java.lang.ClassLoader.loadClass(ClassLoader.java:288) at org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedClassLoade r.java :96) at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:403) at org.jboss.system.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at com.candata.gateway.Encryption.init(Unknown Source) at com.candata.gateway.CCRAAbstract.getEncryption(Unknown Source) at com.candata.gateway.CCRAAbstract.recvMsg(Unknown Source) at com.candata.gateway.CCRAPoll.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) and ... MessageListenerThread - CCRARecv prio=5 tid=0x8671b60 nid=0x946 waiting for monitor entry [0xbb1fd000..0xbb1ffad8] at java.lang.ClassLoader.loadClass(ClassLoader.java:288) at org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedClassLoade r.java :96) at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:403) at org.jboss.system.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:493) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.java :96) at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:403) at org.jboss.system.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:493) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:299
AW: AW: AW: [JBoss-dev] Thread deadlock in class loader
I will reissue the bug report immediately. The Jboss will hopefully back it up. Let´s see how this develops ;-) CGJ -Ursprüngliche Nachricht- Von: Dave Smith [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 11. April 2002 16:37 An: Jung , Dr. Christoph Betreff: Re: AW: AW: [JBoss-dev] Thread deadlock in class loader that's not what I did and when I followed your directions it worked perfectly. A FAQ item ? Should I write something? On Thu, 2002-04-11 at 05:46, Jung , Dr. Christoph wrote: Did you prepend the bootclasspath with the patched class using the Xbootclasspath/p:patch.jar option? CGJ -Ursprüngliche Nachricht- Von: Dave Smith [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 10. April 2002 23:22 An: Jung , Dr. Christoph Betreff: Re: AW: [JBoss-dev] Thread deadlock in class loader Seems like sun does not think it is a bug http://developer.java.sun.com/developer/bugParade/bugs/4406709.html Even if I patch the localClassInternal I still get an error. Looks like the class loader is internally locking the class loader because when I run with the -Xdebug option that shows be the locks, it is waiting for a lock that does not exsist in any of the threads. On Tue, 2002-04-09 at 03:35, Jung , Dr. Christoph wrote: Looks like you are a victim of the private synchronized localClassInternal-syndrom that is already known to us and that cannot be resolved except by SUN or by patching the JDK´s java.lang.ClassLoader (remove the synchronized at localClassInternal either by recompiling or by BCEL?) ... Happens very seldom, since most of the classloading happens in one thread at app-startup. Ok, maybe now I will file a bug at SUN ... CGJ -Ursprüngliche Nachricht- Von: Dave Smith [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 8. April 2002 17:43 An: Jboss-Development@Lists. Sourceforge. Net Betreff: [JBoss-dev] Thread deadlock in class loader I have a strange deadlock problem between two threads that are completely unrelated. Could some-one point me in the right direction to solve this problem. Here are the two threads in question .. The first one ins accessing thrid party jars and the second one is trying to look up an entity bean and is getting hung up in the jaas security. CCRAPoll prio=5 tid=0x87000d0 nid=0x943 waiting for monitor entry [0xbb7fe000..0xbb7ffad8] at java.lang.ClassLoader.loadClass(ClassLoader.java:288) at org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedClassLoade r.java :96) at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:403) at org.jboss.system.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at com.candata.gateway.Encryption.init(Unknown Source) at com.candata.gateway.CCRAAbstract.getEncryption(Unknown Source) at com.candata.gateway.CCRAAbstract.recvMsg(Unknown Source) at com.candata.gateway.CCRAPoll.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) and ... MessageListenerThread - CCRARecv prio=5 tid=0x8671b60 nid=0x946 waiting for monitor entry [0xbb1fd000..0xbb1ffad8] at java.lang.ClassLoader.loadClass(ClassLoader.java:288) at org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedClassLoade r.java :96) at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:403) at org.jboss.system.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:493) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedClassLoade r.java :96) at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:403) at org.jboss.system.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at java.lang.ClassLoader.defineClass0(Native Method
AW: [JBoss-user] RE: Bomb the bug parade! was AW: [JBoss-dev] Thread deadlock in class loader
I just filed an EOU-request with reference to the Bug-Id and a priority of can´t do without it. Maybe that was a fault, because I just got a review id and it is not yet visible officially? Anyone knows how this works? Will they publish the thing not until it reviewed, or what? CGJ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-user] RE: Bomb the bug parade! was AW: [JBoss-dev] Thr ead deadlock in class loader
Ok, so please guys, save your powder a bit for the upcoming real bug id which I will send as soon as I have it ... CGJ -Ursprüngliche Nachricht- Von: Juha-P Lindfors [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 11. April 2002 18:04 An: Jung , Dr. Christoph Cc: 'marc fleury'; Eric Kaplan; [EMAIL PROTECTED]; [EMAIL PROTECTED] Betreff: Re: AW: [JBoss-user] RE: Bomb the bug parade! was AW: [JBoss-dev] Thr ead deadlock in class loader On Thu, 11 Apr 2002, Jung , Dr. Christoph wrote: Anyone knows how this works? Will they publish the thing not until it reviewed, or what? yeah they'll review it to see if it makes sense, and then assign a bug id for it at which point you usually get an email about it -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] RE: AW: Patches to jboss.net
Addendum: 4.5 you have to first utter a jboss-all/testsuite/build because there are some basic testcase classes which do the server deployment for us. Maybe these were the unresolved symbols you were seeing. I added that hint to the jboss.net/docs/Readme ... Martin and Marius, any help in getting the installation and build as user-friendly as possible would be appreciated. If you want to rewrite/add things to the Readme in better and more intelligible English than mine (which is not too hard), please go ahead. I really want this web service thingy to work for you and the rest of the world ... CGJ -Ursprüngliche Nachricht- Von: Peter Braswell [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 10. April 2002 00:39 An: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] RE: AW: Patches to jboss.net All, I'm not sure if this is the *approved* way of doing things, but here's the sequence that seems to work for me: 1. Do a CVS update, rebuild jboss from jboss-all\build\build.sh or build.bat depending on your poison. 2. Goto jboss.net and build. Make sure .sar file makes it into the jboss deploy directory. This is a manual process for me. If this is a fresh get from CVS, sometimes the required .jars/config files don't make it to the right jboss directory in which case you have to do it manually. I can provide details here if this is what you are having problems with. 3. Start jboss, make sure jboss-net.sar deploys okay. 4. Goto jboss.net\testsuite and do a build tests-standard-unit 5. Watch in utter amazement the miracle to which you are witness to. Okay, maybe not that dramatic, but you get the idea... :-) All and all I know how frustrating this can be (BELEIVE ME!). Christoph and I will be working on docs/process/hints to make the whole thing easier... promise!! hope this helps, peter On Tue, 9 Apr 2002 15:24:44 -0700 [EMAIL PROTECTED] wrote: Hi Marius, I used ./build.sh -Dmodules=jboss.net/testsuite modules-tests which seems to just run the JBoss.net testsuite. This worked this morning but when I reapply my testsuite patch (capitalisation error removing the emption address book impl class, obviously hasn't made it into cvs yet), I still get a whole bunch of cannot resolve symbols when building the testsuites. I will try to find out what's causing this tomorrow morning. Cheers, Martin Original Message From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RE: AW: Patches to jboss.net Date: Tue, 09 Apr 2002 14:36:13 +0200 Tried ./build.sh testsuite -Dmodules=jboss.net. It doesn't complain on anything, but I can't see any .ear or wsr-files generated. Is this right? I though it would create hello.wsr. Martin Maisey wrote: Hi Christoph Thanks for having such a deep look into jboss.net and fixing these open issues. No problem + it wasn't a particularly deep look! Some of them were cause by my stupidity (the techtrader-lib copy operation, I did not commit, simply forgot it), Thought it was probably something like that - I've done the same thing myself many times... some of them are those frequent changes in the jboss-core which I cannot immediately adopt because of restricted time ... We really should have a separation of core and modules such as Peter Braswell suggested ... If you need a 'second pair of hands' to try to keep on top of this type of thing and test updates, I'm happy to do it as I would like to get a better knowledge of JBoss and web services and have (a small amount of ;-)) spare time. I noticed that some of the project web page seems a bit out of date - only one of the build commands worked for me and the command to start the test suite needs tweaking. What's the process to update it? I could also take a look at the failing JMX endpoint unit test if it would help, although this is likely to take a bit longer as I will probably have to wrap my head around much more of Axis and JBoss JMX ;-) Cheers, Martin ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Peter Braswell Utopian Software [EMAIL PROTECTED] 757.560.8867 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] RE: AW: Patches to jboss.net
This means that the testsuite does not find the jboss.net classes, could you please check That the class-path at the javac/ task points to jboss-all/jboss.net/output/lib/jboss-net.sar and that that file Exists. CGJ -Ursprüngliche Nachricht- Von: Marius [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 10. April 2002 10:24 An: Peter Braswell Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] RE: AW: Patches to jboss.net Peter Braswell wrote: All, I'm not sure if this is the *approved* way of doing things, but here's the sequence that seems to work for me: 1. Do a CVS update, rebuild jboss from jboss-all\build\build.sh or build.bat depending on your poison. 2. Goto jboss.net and build. Make sure .sar file makes it into the jboss deploy directory. This is a manual process for me. If this is a fresh get from CVS, sometimes the required .jars/config files don't make it to the right jboss directory in which case you have to do it manually. I can provide details here if this is what you are having problems with. 3. Start jboss, make sure jboss-net.sar deploys okay. 4. Goto jboss.net\testsuite and do a build tests-standard-unit Do you use windows? This step gived me many syntax-errors, for example: [javac] /home/marius/tmp/jbosscvs/jboss-all/jboss.net/testsuite/src/main/org/jboss/t est/net/jmx/JmxUnitTestCase.java:72: cannot resolve symbol [javac] symbol : class RemoteAdaptor [javac] location: class org.jboss.test.net.jmx.JmxUnitTestCase [javac] RemoteAdaptor handler=createRemoteAdaptor(new URL(JMX_END_POINT)); [javac] ^ [javac] 36 errors 5. Watch in utter amazement the miracle to which you are witness to. Okay, maybe not that dramatic, but you get the idea... :-) All and all I know how frustrating this can be (BELEIVE ME!). Christoph and I will be working on docs/process/hints to make the whole thing easier... promise!! hope this helps, peter On Tue, 9 Apr 2002 15:24:44 -0700 [EMAIL PROTECTED] wrote: Hi Marius, I used ./build.sh -Dmodules=jboss.net/testsuite modules-tests which seems to just run the JBoss.net testsuite. This worked this morning but when I reapply my testsuite patch (capitalisation error removing the emption address book impl class, obviously hasn't made it into cvs yet), I still get a whole bunch of cannot resolve symbols when building the testsuites. I will try to find out what's causing this tomorrow morning. Cheers, Martin Original Message From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RE: AW: Patches to jboss.net Date: Tue, 09 Apr 2002 14:36:13 +0200 Tried ./build.sh testsuite -Dmodules=jboss.net. It doesn't complain on anything, but I can't see any .ear or wsr-files generated. Is this right? I though it would create hello.wsr. Martin Maisey wrote: Hi Christoph Thanks for having such a deep look into jboss.net and fixing these open issues. No problem + it wasn't a particularly deep look! Some of them were cause by my stupidity (the techtrader-lib copy operation, I did not commit, simply forgot it), Thought it was probably something like that - I've done the same thing myself many times... some of them are those frequent changes in the jboss-core which I cannot immediately adopt because of restricted time ... We really should have a separation of core and modules such as Peter Braswell suggested ... If you need a 'second pair of hands' to try to keep on top of this type of thing and test updates, I'm happy to do it as I would like to get a better knowledge of JBoss and web services and have (a small amount of ;-)) spare time. I noticed that some of the project web page seems a bit out of date - only one of the build commands worked for me and the command to start the test suite needs tweaking. What's the process to update it? I could also take a look at the failing JMX endpoint unit test if it would help, although this is likely to take a bit longer as I will probably have to wrap my head around much more of Axis and JBoss JMX ;-) Cheers, Martin ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Peter Braswell Utopian Software [EMAIL PROTECTED] 757.560.8867 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
