Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
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: <tho...@jb...> - 2005-08-04 07:30:04
|
Anil,
I made a few minor changes to the JavaToWSDL (1.52) API. I think this is clean now. Except that the features it supports should be enforced and documented. See org.jboss.ws.jaxrpc.CallImpl for an example.
The configuration that we support in jbossws-tools.xsd should map cleanly to JavaToWSDL API calls. That still needs to be done.
The JavaToXSD (1.23) API is still much too complicated. This needs to be refactored in a similar way. Additionally to some property getters/setters, it should really be offering only these methods
| JBossXSModel generateForEndpoint (Class epSEIorImpl)
| JBossXSModel generateForSingleType (Class javaType)
|
or am I missing something? JBossXSModel should make max reuse of the xerces XSModel, but not leak it ouside its private space. It is implementation detail.
JBossXSModel should allow me to add complexTypes, globalElements, etc. There should be a XSDWriter that can serialize the model, which I think we have.
WSDLToJava as implemented by the WSDLDefinitionsFactory is ok.
WSDL11Reader (1.6) uses direct calls to the xerces API. The read-only XSModel leaks into WSDLTypes, which then cannot be modified any more. This is nonsense.
| private XSModel parseSchema(URL fileurl)
| {
| XSLoader xsloader = new XMLSchemaLoader();
| XSModel xsmodel = xsloader.loadURI(fileurl.toExternalForm());
| return xsmodel;
| }
|
| should be
|
| private JBossXSModel parseSchema(URL fileurl)
| {
| ...
| }
|
In WSDLTypes we have
| // This registry maps a schema target namespace to the extracted schema model.
| // The registry is populated at parse time. It is possible that the wsdl types element
| // contains multiple schema definitions some assigned to the same target namespace.
| // This especially occurs when a schema uses xsd:include elements
| private Map<String, List<XSModel>> schemaModels = new LinkedHashMap<String, List<XSModel>>();
|
| // This registry maps a schema target namespace to the extracted temp file URL for that schema.
| // It is populated at parse time. Ideally this map should disappear and clients of this class
| // should work with the XSModel map exclusively. They may then serialize and cache the models if
| // needed. It is not clear to me how this can be done since XSModel cannot be written out easily.
| // A possible solution would be to maintain a Map<String, List<JBossXSModel>>
| private Map<String, List<URL>> schemaLocations = new LinkedHashMap<String, List<URL>>();
|
| should be a registry for read/write JBossXSModel, maybe similar to
|
| private Map<String, List<JBossXSModel>> schemaModels = new LinkedHashMap<String, List<JBossXSModel>>();
|
WSDLTypes should not have a registry of temp files to schema URLs.
If clients of WSDLTypes require a URL to a schema they can serialize JBossXSModel and maybe cache it if appropriate.
These refactorings have been discussed in bits on various occasions. Do we have JIRA issues that we can reference from here?
IMHO, these refactorings are most critical because they provide the API that the tools project itself needs to rely on, let alone its clients.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888366#3888366
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888366
|
|
From: mkural <nu...@jb...> - 2005-08-04 06:44:14
|
Hi Julien, I'd say download the IBM Faces for Laszlo alphaworks release: http://www.alphaworks.ibm.com/tech/faces4laszlo/download and try to use the JSF components inside a portlet in JBoss Portal. If I knew JBoss Portal well enough I would probably try it myself but I am pretty new at it. -Mete View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888362#3888362 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888362 |
|
From: twundke <nu...@jb...> - 2005-08-04 06:24:23
|
I'm using AOP with JBossCache (cache=1.2.3, AOP=1.3.1), and am having an issue with certain classes not being advised. Here is the interface/class hierarchy and xml file.
package com.generic.code;
| interface Base;
| class BaseImpl implements Base;
|
| package com.my.code;
| interface Sub extends Base;
| class SubImpl extends BaseImpl implements Sub;
<?xml version="1.0" encoding="UTF-8"?>
|
| <aop>
| <prepare expr="field(* $instanceof{com.generic.code.Base}->*)" />
| </aop>
So, what I would expect is that both BaseImpl and SubImpl would be advised (I'm using the aopc compiler rather than runtime instrumentation). However, I find that only BaseImpl is advised.
Two solutions seem to exist; make SubImpl explicitly implement Base, or add the Sub interface to the AOP file. Neither of these is especially appealing in my situation.
Are my expectations correct? The AOP reference documentation seems to imply that $instanceof works the same way as Java instanceof, which would mean that SubImpl really is an instance of Base, and hence should be advised.
Is this a bug, or am I just doing something wrong?
Tim.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888356#3888356
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888356
|
|
From: <ju...@jb...> - 2005-08-04 04:05:41
|
Hello mkural, the faces + laszlo integration seems powerfull. we will migrate our portlets to JSF (except the forum which has a specific interface non based on widgets) so if the faces + JSF integration works I think it is a good idea to use it to provide a richer UI. beside that for now, I don't see what JBoss Portal must implement specifically in order to enable laszlo portlets to run with it. "mkural" wrote : Hello Roy, | | <<They're using an IFrame portlet to insert the content. This is possible *now* with JBoss Portal. You just need the IFrame portlet and you can call any cgi, laszlo widget, flash movie, coldfusion application, etc...>> | | Yeah I noticed that later. Well, that is just that screenshot though, which was posted by some Liferay user on the forum. Since it is IFrame it's not a significant screenshot. But Liferay's lead developer Brian Chan has been building real Laszlo-based portlets for Liferay Portal for half a year. Please check here: | http://forums.liferay.com/index.php?showtopic=840&st=0&#entry2640 | | Also IBM built Faces for Laszlo which enables you to put JSF components that emit Laszlo GUI components. You can read more about Faces for Laszlo here: | http://dl.alphaworks.ibm.com/technologies/faces4laszlo/faces4laszlo_whitepaper.pdf | | Does JBoss Portal have any roadmap in terms of Laszlo? | | Thanks, | Mete View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888335#3888335 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888335 |
|
From: mkural <nu...@jb...> - 2005-08-04 03:30:27
|
Hello Roy, <<They're using an IFrame portlet to insert the content. This is possible *now* with JBoss Portal. You just need the IFrame portlet and you can call any cgi, laszlo widget, flash movie, coldfusion application, etc...>> Yeah I noticed that later. Well, that is just that screenshot though, which was posted by some Liferay user on the forum. Since it is IFrame it's not a significant screenshot. But Liferay's lead developer Brian Chan has been building real Laszlo-based portlets for Liferay Portal for half a year. Please check here: http://forums.liferay.com/index.php?showtopic=840&st=0&#entry2640 Also IBM built Faces for Laszlo which enables you to put JSF components that emit Laszlo GUI components. You can read more about Faces for Laszlo here: http://dl.alphaworks.ibm.com/technologies/faces4laszlo/faces4laszlo_whitepaper.pdf Does JBoss Portal have any roadmap in terms of Laszlo? Thanks, Mete View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888332#3888332 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888332 |
|
From: yxyang <nu...@jb...> - 2005-08-04 03:03:16
|
I implement a simple IFrame portlet in my own site which is based on jbp2.0 branch. http://www.mobmeee.com/index.html?ctrl:id=window.default.IFramePortletWindow&ctrl:type=render&iframemessage=http://www.roamingsms.com You can modify the value of iframemessage value to other URL to display other website. e.g. http://www.mobmeee.com/index.html?ctrl:id=window.default.IFramePortletWindow&ctrl:type=render&iframemessage=http://www.jboss.com regards yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888328#3888328 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888328 |
|
From: <roy...@jb...> - 2005-08-04 01:20:40
|
I will take your post and place it in our wiki. Mind if I take the graphics and post them too? Thanks for the contribution! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888326#3888326 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888326 |
|
From: <roy...@jb...> - 2005-08-04 01:19:37
|
"mkural" wrote : I think so. Well, it must be possible so that IBM and Liferay are able to make portlets that use Laszlo, hence Flash in them. Here is the screenshot of a HelloWorld Laszlo portlet running in Liferay Portal: | http://www.laszlosystems.com/developers/community/forums/attachment.php?s=cb9d97125b67b3fe848700de22c1f720&postid=5607 | They're using an IFrame portlet to insert the content. This is possible *now* with JBoss Portal. You just need the IFrame portlet and you can call any cgi, laszlo widget, flash movie, coldfusion application, etc... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888325#3888325 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888325 |
|
From: antzcp04 <nu...@jb...> - 2005-08-04 00:54:04
|
Hi Simba, Where you able to implement this kind of framework? I just want to know because i was thinking of using the same thing... thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888321#3888321 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888321 |
|
From: mkural <nu...@jb...> - 2005-08-03 23:46:41
|
<<I'm not sure, but wouldn't it be possible to wrap the stream with PortletContext.getNamedDispatcher and set the portlet's response type to swf?>> I think so. Well, it must be possible so that IBM and Liferay are able to make portlets that use Laszlo, hence Flash in them. Here is the screenshot of a HelloWorld Laszlo portlet running in Liferay Portal: http://www.laszlosystems.com/developers/community/forums/attachment.php?s=cb9d97125b67b3fe848700de22c1f720&postid=5607 Beyond just the portlets themselves, Laszlo could even be used to build the actual portal interface also. This could be a second additional more powerful interface as an alternative to the HTML-based interface. Here is a Laszlo demo that demonstrate what a Laszlo-based portal might look like: http://www.laszlosystems.com/lps/sample-apps/dashboard/dashboard.lzo?lzt=html Today Lazslo emits SWF but I hope in the future this will evolve towards SVG. I think there is already some noise about that. -Mete View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888317#3888317 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888317 |
|
From: martingi <nu...@jb...> - 2005-08-03 23:30:45
|
Rendering vector graphics would definitely be an interesting feature for me concerning the portal. From my knowlegde of laszlo, is that they are currently targetting the flash format - streaming out binary content from a servlet. I'm not sure, but wouldn't it be possible to wrap the stream with PortletContext.getNamedDispatcher and set the portlet's response type to swf? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888315#3888315 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888315 |
|
From: jlauman <nu...@jb...> - 2005-08-03 23:03:50
|
Things for you to verify:
Are all of the files in tools/lib? You should be able to see many jars there.
Yes it looks normal
What does buildmagic.task.classpath resolve to?
You can add an echo message to the init target and verify this.
[property] Loading /opt/java/jboss-cvs/jboss-4.0/build/local.properties
[echo] Classpath is /opt/java/jboss-cvs/jboss-4.0/tools/lib/README:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/ant-javamail.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/ant-junit.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/ant-launcher.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/ant-nodeps.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/ant-trax.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/ant-xalan2.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/ant-xslp.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/ant.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/bsf.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/buildmagic-tasks.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/jbossbuild.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/junit.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/pretty.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/resolver.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/xalan.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/xercesImpl.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/xml-apis.jar:
/opt/java/jboss-cvs/jboss-4.0/tools/lib:
/opt/java/jboss-cvs/jboss-4.0/tools/etc:
/opt/java/jboss-cvs/jboss-4.0/tools:
/opt/java/jboss-cvs/jboss-4.0/build
If I remove the "README" file from the tools/lib dir I can get rid of the Zip errors.
The local.properties file is always overwritten by a file in etc/local.properties.example
[property] Loading /opt/java/jboss-cvs/jboss-4.0/build/local.properties
[property] Loading /root/.buildmagic.properties
[property] Unable to find property file: /root/.buildmagic.properties
[property] Loading /root/.ant.properties
[property] Unable to find property file: /root/.ant.properties
Ignoring Exception java.util.zip.ZipException: error in opening zip file reading resource org/jboss/tools/buildmagic/task/util/TaskLogger.class from /opt/java/jboss-cvs/jboss-4.0/tools/lib/README
[available] Found: etc/local.properties-example
The files it's looking for in the root dir don't exist and I don't want them to live there. I want them to stay in the build dir.
I've been building Jboss on an almost daily basis for the last two years or so. I've never had this much trouble before.
Any help would be appreciated.
Jack
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888310#3888310
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888310
|
|
From: mkural <nu...@jb...> - 2005-08-03 22:44:01
|
Hello All, I know that other portal vendors are beginning to use Laszlo (http://www.openlaszlo.org/) in their portals and portlets so I am wondering if anyone has thought about making JBoss Portal Laszlo-able. From open-source portals I know you can use Laszlo in Liferay Portal. From commercial servers, IBM has some things they are working on in regards to Laszlo (http://today.java.net/pub/n/FacesforLazlo). Also soon Laszlo development may be part of Eclipse as well (http://www.eclipse.org/proposals/laszlo/). Is there any interest within JBoss Portal developers and community in regards to Laszlo? Thanks, Mete View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888308#3888308 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888308 |
|
From: <rl...@jb...> - 2005-08-03 21:19:49
|
Looking at your log file I see a number of things that raise flags. First off:
_buildmagic:init:
| [property] Loading /opt/java/jboss-cvs/jboss-4.0/build/local.properties
| Ignoring Exception java.util.zip.ZipException: error in opening zip file reading resource org/jboss/tools/buildmagic/task/config/LibrarySet.class from /opt/java/jboss-cvs/jboss-4.0/tools/lib/README
| Ignoring Exception java.util.zip.ZipException: error in opening zip file reading resource org/jboss/tools/buildmagic/task/MissingAttributeException.class from /opt/java/jboss-cvs/jboss-4.0/tools/lib/README
| Ignoring Exception java.util.zip.ZipException: error in opening zip file reading resource org/jboss/tools/buildmagic/task/module/ExecuteModules.class from /opt/java/jboss-cvs/jboss-4.0/tools/lib/README
The target _buildmagic:init: is being executed here. This target is located in tools/etc/buildmagic/buildmagic.ent.
The target works like this (important stuff in bold):
<!-- Setup the project environment. -->
| <dirname property="project.root" file="${basedir}"/>
| <property name="project.build" value="${project.root}/build"/>
| <property name="project.tools" value="${project.root}/tools"/>
| <property name="project.thirdparty" value="${project.root}/thirdparty"/>
|
| <!-- Setup the module environment. -->
| <property name="module.root" value="${basedir}"/>
| <property file="${module.root}/local.properties"/>
| <property name="module.source" value="${module.root}/src"/>
| <property name="module.output" value="${module.root}/output"/>
| <property name="module.tools" value="${module.root}/tools"/>
| <property name="module.thirdparty" value="${module.root}/thirdparty"/>
|
| <!-- Load Buildmagic extention tasks. -->
| <property name="buildmagic.local.classpath" value="."/>
| <path id="buildmagic.task.classpath">
| <fileset dir="${project.tools}/lib">
| <include name="*"/>
| </fileset>
| <pathelement location="${project.tools}/lib"/>
| <pathelement location="${project.tools}/etc"/>
| <pathelement location="${project.tools}"/>
| <pathelement path="${buildmagic.local.classpath}"/>
| </path>
| <taskdef file="${project.tools}/etc/buildmagic/autoload.properties"
| classpathref="buildmagic.task.classpath"/>
| <taskdef name="property" classname="org.jboss.tools.buildmagic.task.Property"
| classpathref="buildmagic.task.classpath"/>
Basically,
1) Read in a property file
2) Make a classpath
3) Create some taskdefs
From your logfile, it looks like it is trying to resolve the task definiton to this classpath:
/opt/java/jboss-cvs/jboss-4.0/tools/lib/README
Which is obviously bad.
Things for you to verify:
Are all of the files in tools/lib? You should be able to see many jars there. What does buildmagic.task.classpath resolve to?
You can add an echo message to the init target and verify this.
Something like:
<property name="cp" refid="buildmagic.task.classpath"/>
| <echo message="Classpath is ${cp}"/>
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888286#3888286
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888286
|
|
From: PeterJ <nu...@jb...> - 2005-08-03 20:30:11
|
Please don't break the build. The files you added require the Hibernate jars to be added to the classpath in order for the code to compile. I made that change to build.xml and checked it in. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888278#3888278 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888278 |
|
From: <ani...@jb...> - 2005-08-03 19:54:08
|
The schema file is changed based on Thomas's feedback. Ready for review. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888265#3888265 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888265 |
|
From: <ad...@jb...> - 2005-08-03 19:21:51
|
This thread is for the discussion of issues related to JBAS-2075 and the redesign/enhancement of the remote classloading service. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888260#3888260 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888260 |
|
From: <rl...@jb...> - 2005-08-03 18:52:41
|
There a few things which you can check. First off, please ensure that you have checked out and built in this fashion. mkdir test cd test cvs co -r Branch_4_0 jboss-4.0.x cd jboss-4.0 cd build ./build.sh What commands are you issuing to build? It would be helpful if you executed: build/build.sh -verbose -logfile -errorlog.txt This will generate an error log and place it in the build directory. You can send me these results and I will take a look at them. Ruel Loehr JBoss QA View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888252#3888252 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888252 |
|
From: aguizar <nu...@jb...> - 2005-08-03 18:46:19
|
Anil, The jBPM web service consumption requirements are summarized in the following jBPM process action, which describes an RPC invocation: <ws-invoke endpoint="anyURI" operation="math:add" xmlns:math='urn:example:math'> | <input location="firstNumber">var1</input> | <input location="secondNumber>var2</input> | <output location="result">result</output> | </ws-invoke> - 'math:add' is the qualified name of the RPC operation element. - Attribute 'location' specifies a (XPath) location path relative to the operation element. - The content of each 'input' element is an expression whose value is assigned to the specified location in the input message. Note, the value must be either a primitive type or a DOM element; XML<->data binding must be explicitly performed by the user. - The content of each 'output' element identifies a location that receives the value of the specified location in the output message. A request SOAP envelope we would expect to see is: <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> | <S:Body> | <math:add xmlns:math="urn:example:math"> | <firstNumber>20</firstNumber> | <secondNumber>45</secondNumber> | </math:add> | </S:Body> | </S:Envelope> A possible response SOAP envelope is: <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/";> | <S:Body> | <math:addResponse xmlns:math="urn:example:math"> | <result>65</result> | </math:addResponse> | </S:Body> | </S:Envelope> Do you think we can build a portable JAX-WS client that implements this design with the current features of JBossWS? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888251#3888251 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888251 |
|
From: jlauman <nu...@jb...> - 2005-08-03 18:20:20
|
I'm trying to build JBoss from the 4.0.x branch (clean checkout) and getting the following error. Am I missing something?
BUILD FAILED
/opt/java/jboss-cvs/jboss-4.0/tools/etc/buildmagic/buildmagic.ent:418: Could not create task or type of type: depend.
Full error follows:
Searching for build.xml ...
Buildfile: /opt/java/jboss-cvs/jboss-4.0/build/build.xml
check.inhibit.downloads:
createthirdparty:
_buildmagic:init:
Trying to override old definition of task property
_buildmagic:init:local-properties:
_buildmagic:init:buildlog:
configure:
[echo] groups: default
[echo] modules: common,jmx,test,system,naming,j2ee,transaction,server,deployment,security,messaging,connector,jaxrpc,jboss.net,webservice,cluster,varia,iiop,management,cache,tomcat,console,compatibility,media,aspects,ejb3x,ejb3,hibernate-int
init:
_buildmagic:modules:all:
======================================================================
== Executing 'all' in module 'common'...
==
_buildmagic:init:
Trying to override old definition of task libraryset
Trying to override old definition of task execmodules
Trying to override old definition of task resolveproperties
Trying to override old definition of task resolver
Trying to override old definition of task require
Trying to override old definition of task _dump
Trying to override old definition of task _puke
Trying to override old definition of task moduleinit
Trying to override old definition of task moduleconfig
Trying to override old definition of task modulelibrary
Trying to override old definition of task projectinfo
Trying to override old definition of task library
Trying to override old definition of task Ant
Trying to override old definition of task moduleinfo
Trying to override old definition of task projecthelp
Trying to override old definition of task propertyfilter
Trying to override old definition of task call
Trying to override old definition of task property
configure:
_default:task-init:
init:
_buildmagic:build-bypass-checker:
_buildmagic:build-bypass-notice:
_buildmagic:build-bypass-check:
jars:
_buildmagic:init:
init:
_default:compile-classes:
BUILD FAILED
/opt/java/jboss-cvs/jboss-4.0/tools/etc/buildmagic/buildmagic.ent:418: Could not create task or type of type: depend.
Ant could not find the task or a class this task relies upon.
This is common and has a number of causes; the usual
solutions are to read the manual pages then download and
install needed JAR files, or fix the build file:
- You have misspelt 'depend'.
Fix: check your spelling.
- The task needs an external JAR file to execute
and this is not found at the right place in the classpath.
Fix: check the documentation for dependencies.
Fix: declare the task.
- The task is an Ant optional task and the JAR file and/or libraries
implementing the functionality were not found at the time you
yourself built your installation of Ant from the Ant sources.
Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the
task and make sure it contains more than merely a META-INF/MANIFEST.MF.
If all it contains is the manifest, then rebuild Ant with the needed
libraries present in ${ant.home}/lib/optional/ , or alternatively,
download a pre-built release version from apache.org
- The build file was written for a later version of Ant
Fix: upgrade to at least the latest release version of Ant
- The task is not an Ant core or optional task
and needs to be declared using .
- You are attempting to use a task defined using
or but have spelt wrong or not
defined it at the point of use
Remember that for JAR files to be visible to Ant tasks implemented
in ANT_HOME/lib, the files must be in the same directory or on the
classpath
Please neither file bug reports on this problem, nor email the
Ant mailing lists, until all of these causes have been explored,
as this is not an Ant bug.
Total time: 4 seconds
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888247#3888247
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888247
|
|
From: <dim...@jb...> - 2005-08-03 17:43:30
|
Sure, I'll make the console a little more resilient too, thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888236#3888236 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888236 |
|
From: <sco...@jb...> - 2005-08-03 17:32:22
|
Ah, I fixed a similar problem in the JSR77SpecUnitTestCase. I'll just remove the j2eeType=J2EEDomain attribute from the jsr88 service. I don't see any other problem with having this service in the JMX_JSR77_DOMAIN, at least the web-console is working. Of course the deployment tests are broke until you update to the new default jsr88 name. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888232#3888232 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888232 |
|
From: <ad...@jb...> - 2005-08-03 16:59:40
|
The only place this exists currently is in the JBoss Bean Deployer. I was planning that this should go in the yet to be written profile service, but I don't see why this shouldn't also be in the plain deployer for people that don't want to use the profile service. I would think that this should also include an optional registration of a shutdown hook for when people press ctrl-c, KILL TERM, etc. The only issue would be that it makes the assumption that there is only one deployer per kernel or one kernel per JVM, which is something I don't want to assume. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888227#3888227 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888227 |
|
From: <ani...@jb...> - 2005-08-03 16:45:53
|
1. Will add the version information to the schema name. Honest miss. 2. Global options will be retained as before at the bottom. These options are used by advanced users and typically basic users will not have to deal with this. 3. JavaToXSD and XSDToJava is one feature of jbossws. Since I do not foresee any value in exposing this to general use, I will remove it. 4. I will go splurge on documentation as "space and comment are cheap". :-) Sometime ago, you had mentioned that you would like to see less of command line options and more of xml configuration. Hence many of the attributes that can be input via the command line, were fed in the xml configuration. But with a good user guide and a lean/mean schema, it should satisfy majority of the users' needs. Thanks for the feedback. Changes to the schema based on your feedback will also trigger changes to the user guide. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888224#3888224 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888224 |
|
From: <dim...@jb...> - 2005-08-03 16:02:45
|
Scott, any particular reason for loading org.jboss.deployment.services.DeploymentManagerService under: jboss.management.local:j2eeType=J2EEDomain,name=DeploymentManager? I just noticed the web-console breaks because it uses the query: JMX_JSR77_DOMAIN + ":j2eeType=J2EEDomain,*" to get to j2eeType=J2EEDomain,name=Manager, 'servers' attribute We are running out of names :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888202#3888202 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888202 |
1965 messages has been excluded from this view by a project administrator.
