You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
From: fullerj <nu...@jb...> - 2005-07-01 19:39:00
|
I'm trying to deploy the "Hello" example from the jBPM BPEL Extension tutorial using JBoss 4.0.2 which results in the following error: [java] [Fatal Error] hello.wsdl:2:473: The prefix "tns" for attribute "tns: dummy" associated with an element type "definitions" is not bound. [java] 14:44:09,944 ERROR ProblemCollector : could not read wsdl document [java] WSDLException: faultCode=PARSER_ERROR: Problem parsing '- WSDL Document -'.: The prefix "tns" for attribute "tns:dummy" associated with an element type "definitions" is not bound.: org.xml.sax.SAXParseException: The prefix "tns" for attribute "tns:dummy" associated with an element type "definitions" is not bound. The wsdl file is: <?xml version="1.0" encoding="UTF-8"?> <definitions targetNamespace="http://jbpm.org/examples/hello" xmlns:tns="http://jbpm.org/examples/hello" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/wsdl/ http://schemas.xmlsoap.org/wsdl/ http://schemas.xmlsoap.org/ws/2003/05/partner-link/ http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <!-- characterizes the relationship between the process and its caller --> "<plt:partnerLinkType name="helloPLT"> <plt:role name="service"> <plt:portType name="tns:helloPT"/> </plt:role> </plt:partnerLinkType>" <!-- carries the name of a person --> " " <!-- carries the greeting --> " " <!-- describes the interface presented to callers --> The complete error trace from the command "ant deploy-hello-definition" using the build.xml that came with the download is Buildfile: build.xml pack-hello-definition: deploy-hello-definition: deploy-definition: [java] 14:44:08,392 DEBUG JbpmConfiguration : jbpm.task.instance.class=org.jbpm.taskmgmt.exe.TaskInstance [java] 14:44:08,392 DEBUG JbpmConfiguration : jbpm.scheduler.service.factory=org.jbpm.scheduler.impl.SchedulerServiceImpl [java] 14:44:08,392 DEBUG JbpmConfiguration : jbpm.deploy.jndi.context=bpelProcesses [java] 14:44:09,173 DEBUG LocalEntityResolver : bpel_definition_1_0.xsd maps to URL: jar:file:/D:/fullerj/fullerj/jbpm-bpel-1.0-alpha2/build/jbpm-bpel-1.0-alpha2.jar!/org/jbpm/bpel/xml/util/bpel_definition_1_0.xsd [java] 14:44:09,683 DEBUG BpelReader : read wsdl document: hello.wsdl [java] 14:44:09,683 DEBUG LocalEntityResolver : wsdl.xsd maps to URL: jar:file:/D:/fullerj/fullerj/jbpm-bpel-1.0-alpha2/build/jbpm-bpel-1.0-alpha2.jar!/org/jbpm/bpel/xml/util/wsdl.xsd [java] 14:44:09,753 DEBUG LocalEntityResolver : plink_1_1.xsd maps to URL: jar:file:/D:/fullerj/fullerj/jbpm-bpel-1.0-alpha2/build/jbpm-bpel-1.0-alpha2.jar!/org/jbpm/bpel/xml/util/plink_1_1.xsd [java] 14:44:09,914 DEBUG ImportWsdlLocator : upgraded wsdl document: hello.wsdl [java] [Fatal Error] hello.wsdl:2:473: The prefix "tns" for attribute "tns: dummy" associated with an element type "definitions" is not bound. [java] 14:44:09,944 ERROR ProblemCollector : could not read wsdl document [java] WSDLException: faultCode=PARSER_ERROR: Problem parsing '- WSDL Document -'.: The prefix "tns" for attribute "tns:dummy" associated with an element type "definitions" is not bound.: org.xml.sax.SAXParseException: The prefix "tns" for attribute "tns:dummy" associated with an element type "definitions" is not bound. [java] at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) [java] at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) [java] at org.jbpm.bpel.xml.BpelReader.readWsdlDocument(BpelReader.java:304) [java] at org.jbpm.bpel.par.ParDescriptorArchiveParser.readDocuments(ParDescriptorArchiveParser.java:68) [java] at org.jbpm.bpel.par.ParDescriptorArchiveParser.readFromArchive(ParDescriptorArchiveParser.java:47) [java] at org.jbpm.jpdl.par.ProcessArchive.parseProcessDefinition(ProcessArchive.java:46) [java] at org.jbpm.bpel.par.JndiProcessDeployer.deployProcessArchive(JndiProcessDeployer.java:53) [java] at org.jbpm.bpel.par.JndiProcessDeployer.deployProcessArchives(JndiProcessDeployer.java:184) [java] at org.jbpm.bpel.par.JndiProcessDeployer.main(JndiProcessDeployer.java:160) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) [java] at org.jbpm.bpel.xml.BpelReader.readWsdlDocument(BpelReader.java:304) [java] at org.jbpm.bpel.par.ParDescriptorArchiveParser.readDocuments(ParDescriptorArchiveParser.java:68) [java] at org.jbpm.bpel.par.ParDescriptorArchiveParser.readFromArchive(ParDescriptorArchiveParser.java:47) [java] at org.jbpm.jpdl.par.ProcessArchive.parseProcessDefinition(ProcessArchive.java:46) [java] at org.jbpm.bpel.par.JndiProcessDeployer.deployProcessArchive(JndiProcessDeployer.java:53) [java] at org.jbpm.bpel.par.JndiProcessDeployer.deployProcessArchives(JndiProcessDeployer.java:184) [java] at org.jbpm.bpel.par.JndiProcessDeployer.main(JndiProcessDeployer.java:160) [java] 14:44:09,964 DEBUG LocalEntityResolver : bpel_1_1.xsd maps to URL: jar:file:/D:/fullerj/fullerj/jbpm-bpel-1.0-alpha2/build/jbpm-bpel-1.0-alpha2.jar!/org/jbpm/bpel/xml/util/bpel_1_1.xsd [java] 14:44:09,984 DEBUG LocalEntityResolver : wsdl.xsd maps to URL: jar:file:/D:/fullerj/fullerj/jbpm-bpel-1.0-alpha2/build/jbpm-bpel-1.0-alpha2.jar!/org/jbpm/bpel/xml/util/wsdl.xsd [java] 14:44:10,134 DEBUG BpelReader : upgraded bpel document: hello.bpel [java] 14:44:10,134 ERROR JndiProcessDeployer : deployment failed [java] java.lang.NullPointerException [java] at org.jbpm.bpel.xml.BpelReader.registerPropertyAliases(BpelReader.java:217) [java] at org.jbpm.bpel.xml.BpelReader.registerPropertyAliases(BpelReader.java:210) [java] at org.jbpm.bpel.xml.BpelReader.read(BpelReader.java:190) [java] at org.jbpm.bpel.xml.BpelReader.read(BpelReader.java:148) [java] at org.jbpm.bpel.par.BpelArchiveParser.readFromArchive(BpelArchiveParser.java:25) [java] at org.jbpm.jpdl.par.ProcessArchive.parseProcessDefinition(ProcessArchive.java:46) [java] at org.jbpm.bpel.par.JndiProcessDeployer.deployProcessArchive(JndiProcessDeployer.java:53) [java] at org.jbpm.bpel.par.JndiProcessDeployer.deployProcessArchives(JndiProcessDeployer.java:184) [java] at org.jbpm.bpel.par.JndiProcessDeployer.main(JndiProcessDeployer.java:160) BUILD SUCCESSFUL Total time: 3 seconds Has anyone dealt with this problem before or successfully run the example following the tutorial posted on the web? Any help is certainly appreciated. John View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883408#3883408 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883408 |
From: <sco...@jb...> - 2005-07-01 18:55:50
|
Right, there is info needed, but this info is not availble on the server side. I put up a service on X, and have no control over the path the client has to navigate to get to me. Its his net admin that says to connect to service X, use endpoint Y in order to get through the firewall. The simplest way to handle this on the client is via system properties that are specified on the client command line. Adrian's point is what we should allow for more sophisticated name resolution on the client rather than having to require system properties. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883404#3883404 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883404 |
From: <tom...@jb...> - 2005-07-01 18:44:00
|
This is all fine. The problem is I still don't understand how anyone on the client side is going to be able to resolve how to access the server during runtime without some extra information being provided from somewhere. The only way I can see this working is if the server broadcasts some type of message that is picked up by something external to the network and resolves where it came from (and uses that routing path to get back to the server). This can be done via detection, but means the detector has to run outside the server network, which won't work for multicast and is probably not practical for JNDI. I am guessing I am missing something somewhere? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883403#3883403 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883403 |
From: <sco...@jb...> - 2005-07-01 17:38:54
|
The issue is how is the connection handled when the connection endpoint that the client needs to use is not known on the server side. It may not even be meaningful to have a name for the clientConnectAddress. If there is a name, we need a multi-step approach to resolving it at the time the client is making the connection. We can either code a multi-step behavior, or introduce an interface to externalize the resolution: {{{ import java.net.InetSocketAddress; public interface EndpointResolver { public InetSocketAddress resolve(String name, int port); } }}} We could also have a resolver chain notion to tier prioritize and stack the resolution process. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883398#3883398 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883398 |
From: mlybarger <nu...@jb...> - 2005-07-01 10:47:23
|
i do have debug logging turned on, but i'll add some explicit log4j logging in my servlet to make sure in my example of using the CallLoggingInterceptor. i was unsuccessfull with the injboss example. i gave the jboss.dir needed in the build.xml, then ran ant deploy-basic-lt-war. I point my browser to http://localhost:8080/aopexample and run the example. there's a lot of output on the first run when the classes are going through any transform. when running, i only see the output from the ExampleValue class and the BasicExampleServlet class. I see the same results in the console and the server/default/log/server.log file. | 06:31:12,858 INFO [STDOUT] [trying to transform] org.apache.catalina.core.ApplicationDispatcher | 06:31:12,859 INFO [STDOUT] [debug] There are no caller pointcuts! | 06:31:12,932 INFO [STDOUT] [debug] was org.apache.catalina.core.ApplicationDispatcher converted: false | 06:31:12,959 INFO [STDOUT] [trying to transform] org.apache.catalina.core.ApplicationHttpResponse | 06:31:12,960 INFO [STDOUT] [debug] There are no caller pointcuts! | 06:31:12,963 INFO [STDOUT] [debug] was org.apache.catalina.core.ApplicationHttpResponse converted: false | 06:31:12,988 INFO [STDOUT] [trying to transform] org.apache.catalina.core.ApplicationResponse | 06:31:12,989 INFO [STDOUT] [debug] There are no caller pointcuts! | 06:31:12,991 INFO [STDOUT] [debug] was org.apache.catalina.core.ApplicationResponse converted: false | 06:31:13,011 INFO [STDOUT] [trying to transform] org.apache.catalina.core.ApplicationHttpRequest | 06:31:13,012 INFO [STDOUT] [debug] There are no caller pointcuts! | 06:31:13,022 INFO [STDOUT] [debug] was org.apache.catalina.core.ApplicationHttpRequest converted: false | 06:31:13,048 INFO [STDOUT] [trying to transform] org.apache.catalina.core.ApplicationRequest | 06:31:13,050 INFO [STDOUT] [debug] There are no caller pointcuts! | 06:31:13,052 INFO [STDOUT] [debug] was org.apache.catalina.core.ApplicationRequest converted: false | 06:31:13,082 INFO [STDOUT] **** ExampleValue.getMessage() | 06:31:38,315 INFO [STDOUT] **** BasicExampleServlet.service() | 06:31:38,316 INFO [STDOUT] **** ExampleValue String Constructor | 06:31:38,317 INFO [STDOUT] **** ExampleValue.getMessage() | 06:31:52,624 INFO [STDOUT] **** BasicExampleServlet.service() | 06:31:52,624 INFO [STDOUT] **** ExampleValue String Constructor | 06:31:52,626 INFO [STDOUT] **** ExampleValue.getMessage() | 06:32:31,721 INFO [STDOUT] **** BasicExampleServlet.service() | 06:32:31,722 INFO [STDOUT] **** ExampleValue String Constructor | 06:32:31,723 INFO [STDOUT] **** ExampleValue.getMessage() | i expected to see more output when running the servlet. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883339#3883339 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883339 |
From: legolas <nu...@jb...> - 2005-07-01 10:38:41
|
Hi, sounds like your missing the xdoclet-portlet-module on your classpath. Check the xdoclet website, http://xdoclet.sourceforge.net, for the downloads... PS I doubt it can generate any of the jboss specific descriptors though. Cheers, Marcel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883336#3883336 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883336 |
From: <kab...@jb...> - 2005-07-01 09:32:35
|
OK, so I can't type: I meant CallLoggingInterceptor logs using DEBUG level messages, have you got DEBUG logging turned on? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883328#3883328 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883328 |
From: <kab...@jb...> - 2005-07-01 09:32:04
|
Did the injboss example work for you? Get that working first, that should help get over any configuration issues. CallLoggingInterceptor logs using DEBUG lever messages, have you got dEBUG logging turned on? Maybe try with a real simple interceptor just to make sure you get it up and running. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883327#3883327 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883327 |
From: canghel <nu...@jb...> - 2005-07-01 09:14:50
|
Hi all, I posted the problem on the JBoss user forum first, topic: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=65842 I received no answer so I tried to read the JBoss source code in order to learn more about the problem. I have noticed that the org.jboss.invocation.InvokerInterceptor implementation changed in 3.2.7 and after a remote debugging session I came to the conclusion that instead of making the call on the remote MBean Server the call is done on the local MBeanServer. The exact same code worked correctly on 3.2.6 and is no more working correctly in 3.2.7(maybe because of the new implementation of public boolean isLocal(Invocation invocation)). Is my conclusion correct? Is this a bug in 3.2.7? In case this is intended behaviour then how can one call a method on a remote MBeanServer in jboss 3.2.7? thanks, Claudiu Anghel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883325#3883325 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883325 |
From: mbalz <nu...@jb...> - 2005-07-01 09:08:43
|
Hello, when a file upload form (enctype=multipart/formdata) is used to transfer files as well as normal form fields, and the form field data is fetched from the request inside Nukes using page.getParameter, then all umlaut characters in the parameter values appear in a wrong encoding. Is there any way to work around this and get the values with the right encoding? Many thanks in advance, Moritz View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883324#3883324 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883324 |
From: BlackDuck005 <nu...@jb...> - 2005-07-01 08:33:10
|
Have the same problem, but don't understand your answer. Can you provide some more information? Thanks. "wobbet" wrote : Got it... | | Having the username/password be in Base64 was a small suprise... | | rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883320#3883320 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883320 |
From: <tom...@jb...> - 2005-07-01 04:37:53
|
BTW, this is one of the things I have talked to Eric and Ryan a little about for having setup in the QA lab for testing. Is currently a pain in the ass to test from my home network. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883306#3883306 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883306 |
From: <tom...@jb...> - 2005-07-01 04:35:19
|
The remoting jar is over 200K as it is now, so is larger than what you are wanting. However, this includes a lot of extras that you probably would not need (callback persistence, samples, etc.). My goal is to break up the different parts of remoting into core framework and then different implementations that plug in (each being their own jar), but probably won't be able to do this till end of summer. However, remoting does have support for http(s), including proxy and basic authentication support. If can live with the remoting jar size for now (or feel comfortable removing the classes you will not need), it should be fine for applets. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883305#3883305 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883305 |
From: <tom...@jb...> - 2005-07-01 04:27:33
|
Remoting has the ability to set the bind address and port for both the client and server for all transports (see http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_Transports_Configuration). This is only useful if know what the NAT will use for the external address and port for the server. For a long time I have been thinking about how to detect this automatically. The problem is have to be able to either query the router(executing the NAT), which is not practical, or having something external to the network that can identify the ip/port to get back to the server externally. The later approach is fairly easy, but then have an issue of reliability. Am open to suggestions for this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883304#3883304 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883304 |
From: mlybarger <nu...@jb...> - 2005-07-01 01:29:25
|
I'm now getting very close i think. after changing to use the AspectManagerServiceJDK5, i now get lots of aspect info in the logs. I see this when my class is loaded: | 21:23:24,329 INFO [STDOUT] method matched binding execution(* org.test.*->*(..)) protected void org.test.ProfTest.doGet(javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse) throws javax.servlet.ServletException,java.io.IOException | but when this method is executed, i don't see anything being logged. here's the snipped from the base-aop.xml for what i'm binding.: | <interceptor class="org.jboss.aspects.logging.CallLoggingInterceptor"/> | <bind pointcut="execution(* org.test.*->*(..))"> | <interceptor-ref name="org.jboss.aspects.logging.CallLoggingInterceptor"/> | </bind> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883300#3883300 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883300 |
From: hbarlas <nu...@jb...> - 2005-06-30 18:50:38
|
This post is regarding the IP Address parameterization in the JBoss testsuite. I will go over the idea again of what is being accomplished. Basically by allowing parameterization of the testsuite it will be possible to run the testsuite on an IP other than the current hardcoded 'localhost'. Below is a summary of what changes were made to the testsuite, their impact and comparisons between the unmodified testsuite and the 'parameterized' testsuite. ====================== DESCRIPTION OF CHANGES ====================== ---------- Filtersets ---------- 1) Filtersets were applied in the "compile-resources" target to parameterize all .xml, .properties and .wsdl files. 2) In imports/code-generation.xml the "init-code-generation" target now depends on the "compile-resources" target. This is needed because the token substitution is performed in the "compile-resources" target. It must be called before code-generation starts to allow the proper IP to be propagated in build/resources. 3) In imports/test-jars.xml all occurences of {source.resources} have been replaced by {build.resources}. The "compile-resources" target ensures that the @NODE_0@ token in src/resources is substituted correctly with the IP to form build/resources. Therefore test-jars.xml must reference {build.resources} instead of {source.resources} --------------------- Property Substitution --------------------- 1) In all the jboss-client.xml files, localhost is replaced with the property {jboss.bind.address}. 2) Occurrences of localhost in the source code in src/main have been parameterized as follows: - all the testcase source files use getServerHost() - static variables and methods use System.getProperty("jbosstest.server.host" , "localhost") - server related code uses System.getProperty("jboss.bind.address" , "localhost") ============ IMPACT ============ There won't be any difference in using the testsuite, it will output the same results as the current one. When used with a specified IP on non-clustered tests, it will run exclusively on that IP. Since these are big changes to the testsuite, my suggestion is to tag the existing testsuite as 'pre-parameterized'. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883267#3883267 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883267 |
From: rmcdonough <nu...@jb...> - 2005-06-30 17:05:51
|
Thanks Kabir, I was doing all of that but my aspects weren't being picked up if I didn't use the SystemClassLoader. I figured I was doing something else wrong. It turns out that I was setting the src property to point to teh location of sources, not the compiled classes. Now all is well, thanks! Ryan- View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883252#3883252 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883252 |
From: <kab...@jb...> - 2005-06-30 12:09:10
|
The SystemClassLoader has been deprecated. Take a look at chapter 10 of the reference manual http://docs.jboss.com/aop/1.3/aspect-framework/reference/en/html/running.html#d0e2820 and http://docs.jboss.com/aop/1.3/aspect-framework/reference/en/html/running.html#d0e3063 Kabir View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883211#3883211 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883211 |
From: <kab...@jb...> - 2005-06-30 12:01:52
|
1) Yes you need to use the AspectManagerServiceJDK5 service this is needed for the -javaagent to take effect- I have updated the documentation for the next release to make this cleare. 2) You only need to set the Include attribute if they would otherwise be picked up by the Exclude attribute. In the snippet above everything under org.jboss gets excluded apart from org.jboss.test. So org.jboss.whatever.* would be excluded. org.acme.* would be included. The reason for mentioning this was that the "injboss" example's classes are in org.jboss.injbossaop and would be excluded using the out of the box setup. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883209#3883209 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883209 |
From: rmcdonough <nu...@jb...> - 2005-06-30 11:32:36
|
We're using JBoss AOP standalong under Java 1.4.2 and we're having some issues with 1.3. We're executing our code using: java -Djava.system.class.loader=org.jboss.aop.standalone.SystemClassLoader -Djboss.aop.path=project/jboss-aop.xml foo.Main This has been working for us, acutually the only way we could get it to work was declaring the VM to use the JBoss classloader. Anyway, under 1.3 the app throws a ClassNotFoundException and the stack reveals that there is a duplicate entry of the AspectManager in the class path. I have only the JDK14 AO classes in the path so I'm confused. If there's a better alternative to using the SystemClassLoader, I'm all ears. Also on a lighter note, the index.html is mising from the 1.3 JavaDocs. Ryan- View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883203#3883203 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883203 |
From: mlybarger <nu...@jb...> - 2005-06-30 11:19:58
|
one more question. (there seems to be no editing of your posts in this forum as i'm use to in forums.gentoo.org).. do i need to set the include attribute to include a pattern for the classes i'm interested in testing? org.test.*? thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883201#3883201 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883201 |
From: mlybarger <nu...@jb...> - 2005-06-30 11:17:40
|
yes, i set the attribute you mentioned. i used the jboss-aop-jdk50.deployer from the 1.3 aop release. here's my jboss-service.xml. | <server> | | <mbean code="org.jboss.aop.deployment.AspectManagerService" | name="jboss.aop:service=AspectManager"> | <attribute name="EnableLoadtimeWeaving">true</attribute> | <!-- only relevant when EnableLoadtimeWeaving is true. | When transformer is on, every loaded class gets | transformed. If AOP can't find the class, then it | throws an exception. Sometimes, classes may not have | all the classes they reference. So, the Suppressing | is needed. (i.e. Jboss cache in the default configuration --> | <attribute name="SuppressTransformationErrors">true</attribute> | <attribute name="Prune">true</attribute> | <attribute name="Include">org.jboss.test</attribute> | <attribute name="Exclude">org.jboss.</attribute> | <attribute name="Optimized">true</attribute> | <attribute name="Verbose">true</attribute> | </mbean> | | <mbean code="org.jboss.aop.deployment.AspectDeployer" | name="jboss.aop:service=AspectDeployer"> | </mbean> | | </server> | in the post you linked to, you say to use the AspectManagerServiceJDK5. is this indeed needed? if so, i think the jboss-serivce.xml that is included in the jboss-aop-jdk50.deployer release should have this set as this service is specifically intended for jdk50 (uses -javaagent). once again, thanks for your help with all this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883200#3883200 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883200 |
From: pesalomo <nu...@jb...> - 2005-06-30 09:46:36
|
Hi, I wonder if JBOSS remoting is suitable for use in java applets. The total size of the applet should be small < 150kb. I need a way to communicate with enterprise beans, and it also have to handle http transport and proxy servers. Regards, Peter Salomonsen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883195#3883195 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883195 |
From: <kab...@jb...> - 2005-06-30 08:19:58
|
By using the -javaagent switch all classloaders will get intercepted with the chance to instrument classes. Maybe try getting it to work with the "main" classloader first, and come back to us with any issues that may arise with the custom classloaders. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883188#3883188 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883188 |
From: legolas <nu...@jb...> - 2005-06-30 08:08:01
|
Hi developers. I have our theme/layout pretty much on track. So I'd like to share my findings with you guys and ask you some questions. I wrote 2 tags that could be useful for others. One tag, named isNotEmptyRegion, is doing the exact opposite of Julian's original isEmptyTag, it evaluates the body only if the region has content. The second tag, named navigation, adds 2 objects to the pageContext within the scope of the tag. These objects allow the layout developer to iterate over the defined pages, and detect the currently active page. If you are interested in the code please let me know how I can submit them your repository. The first release of our portal based on JbossPortal only requires anonymous access and a single navigation level in 3 languages, but the next release requires uid/password access and smart card access, and a 2 level navigation bar. Given these requirements I have a couple of questions about the purpose of the *-pages.xml file, and its equivalent section in the *-portal.xml files. What is the actual purpose of it, is it merely to define each page and its layout, or is it meant to define the whole navigation structure of the portal including page layout? In case it is the latter, I am missing the navigational structure and the access rights definitions. The pages as defined in *-pages.xml have no ordering, my tag provides for the ordering based on a user supplied or a default comparator. Also no localisation is provided, I (ab)used the pages name as key for retrieving the actual localized page name. What are your plans about this? Is it, or will it be, possibile to define a renderer per window? To test my layout, I created a simple portlet. Only showing some default text. I followed the instructions in chapter 2 of the reference guide and included the descriptors portlet.xml, jboss-portlet.xml, jboss-app.xml and portlet-instance.xml. Which of these re mandatory? BTW the reference guide, paragraph 2.6, describes that the first part of the instance-ref is the application name as defined in the jboss-portlet.xml, I think it should be the jboss-app.xml, is that correct? Thank you for your time and for doing a great job developing JbossPortal! Marcel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883187#3883187 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883187 |