[jira] Commented: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=comments#action_36762 ] Guillaume Nodet commented on SM-526: Is this patch ok to apply ? Your last comment seens to indicate it was not ready ... Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: servicemix-bpe.zip Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=all ] Grant McDonald updated SM-526: -- Description: When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DocumentFormattableValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has confirmed the correctness of the solution works for namespace and non-namespace messages that contain mixed namespace declarations. was: When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: JbiInvokeAction.java.patch Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DocumentFormattableValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has confirmed the correctness of the solution works for namespace and non-namespace messages that contain mixed namespace declarations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-539) Move org.apache.servicemix.eip.MessageUtil to org.apache.servicemix.jbi.util.MessageUtil (in servicemix-core)
Move org.apache.servicemix.eip.MessageUtil to org.apache.servicemix.jbi.util.MessageUtil (in servicemix-core) - Key: SM-539 URL: https://issues.apache.org/activemq/browse/SM-539 Project: ServiceMix Issue Type: Improvement Components: servicemix-core, servicemix-eip Reporter: Guillaume Nodet Fix For: 3.0-M3 MessageUtil is not specific to EIP component and could be reused in other components -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-539) Move org.apache.servicemix.eip.MessageUtil to org.apache.servicemix.jbi.util.MessageUtil (in servicemix-core)
[ https://issues.apache.org/activemq/browse/SM-539?page=all ] Guillaume Nodet resolved SM-539. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Sun Aug 13 12:10:07 2006 New Revision: 431207 URL: http://svn.apache.org/viewvc?rev=431207view=rev Log: SM-539: Move MessageUtil from servicemix-eip to servicemix-core Added: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/util/MessageUtil.java - copied, changed from r430484, incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/support/MessageUtil.java Removed: incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/support/MessageUtil.java Modified: incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/patterns/MessageFilter.java incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/patterns/Pipeline.java incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/patterns/StaticRecipientList.java incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/patterns/StaticRoutingSlip.java incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/patterns/WireTap.java incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/support/AbstractAggregator.java incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/support/AbstractContentBasedRouter.java incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/support/AbstractSplitter.java incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/support/XPathPredicate.java Move org.apache.servicemix.eip.MessageUtil to org.apache.servicemix.jbi.util.MessageUtil (in servicemix-core) - Key: SM-539 URL: https://issues.apache.org/activemq/browse/SM-539 Project: ServiceMix Issue Type: Improvement Components: servicemix-core, servicemix-eip Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 MessageUtil is not specific to EIP component and could be reused in other components -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: MessageUtil in eip package
Thanks a ton... and that was amazingly fast... Soumadeep On 8/14/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Done :) The new class is org.apache.servicemix.jbi.util.MessageUtil On 8/13/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, August 14, 2006 12:23 AM Subject: Re: MessageUtil in eip package Good idea, I will do it asap. There' s no dependency on the EIP component, but there are some on some classes in core, so it will be better to move it there. On 8/13/06, soumadeep sen [EMAIL PROTECTED] wrote: Guillaume, You have the MessageUtil class in the eip package. Would it be possible to move it to core? People can then use it without the eip dependency. Thanks Soumadeep -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
[jira] Closed: (SM-422) throttleInterval and throttleTimeout should be configurable in servicemix.xml
[ https://issues.apache.org/activemq/browse/SM-422?page=all ] Guillaume Nodet closed SM-422. -- Resolution: Duplicate throttleInterval and throttleTimeout should be configurable in servicemix.xml - Key: SM-422 URL: https://issues.apache.org/activemq/browse/SM-422 Project: ServiceMix Issue Type: Improvement Components: servicemix-common Affects Versions: incubation Reporter: Marc Tremblay Currently ComponentMBeanImpl has throttleInterval and throttleTimeout properties that are accessible via JMX. It would be great if one could enable throttling and set these two properties for a component in servicemix.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build failure
Works now... built successfully - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, August 14, 2006 1:18 AM Subject: Build failure Just tried and update and install (with test off) Stack trace: == [INFO] Determining component name for service unit loan-broker-bpe-su [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The service unit loan-broker-bpe-su does not have a dependency which is p ackaged as a jbi-component or a project property 'componentName' [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The service unit loan-br oker-bpe-su does not have a dependency which is packaged as a jbi-component or a project property 'componentName' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: The service unit loan -broker-bpe-su does not have a dependency which is packaged as a jbi-component o r a project property 'componentName' at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescrip torMojo.getComponentName(GenerateServiceAssemblyDescriptorMojo.java:260) at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescrip torMojo.generateJbiDescriptor(GenerateServiceAssemblyDescriptorMojo.java:180) at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescrip torMojo.execute(GenerateServiceAssemblyDescriptorMojo.java:124) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more [INFO] [INFO] Total time: 1 minute 41 seconds [INFO] Finished at: Mon Aug 14 01:14:49 IST 2006 [INFO] Final Memory: 33M/59M [INFO]
Re: Build failure
Yeah, it seems it sometimes fail, but i have no idea why :( On 8/13/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Works now... built successfully - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, August 14, 2006 1:18 AM Subject: Build failure Just tried and update and install (with test off) Stack trace: == [INFO] Determining component name for service unit loan-broker-bpe-su [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The service unit loan-broker-bpe-su does not have a dependency which is p ackaged as a jbi-component or a project property 'componentName' [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The service unit loan-br oker-bpe-su does not have a dependency which is packaged as a jbi-component or a project property 'componentName' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: The service unit loan -broker-bpe-su does not have a dependency which is packaged as a jbi-component o r a project property 'componentName' at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescrip torMojo.getComponentName(GenerateServiceAssemblyDescriptorMojo.java:260) at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescrip torMojo.generateJbiDescriptor(GenerateServiceAssemblyDescriptorMojo.java :180) at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescrip torMojo.execute(GenerateServiceAssemblyDescriptorMojo.java:124) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more [INFO] [INFO] Total time: 1 minute 41 seconds [INFO] Finished at: Mon Aug 14 01:14:49 IST 2006 [INFO] Final Memory: 33M/59M [INFO] -- Cheers, Guillaume Nodet
Re: build broken
I'm having the same problem... I am using java version 1.5 on Mac OS X
Tiger... if I execute mvn with -X I see something interesting...
The path for the Bean file appears to be invalid... Here is the output:
2006-08-13 01:02:19,948 [main ] INFO XBeanXmlBeanDefinitionReader
- Loading XML bean definitions from file
[/Users/ldangelo/Development/servicemix/trunk/samples/wsdl-first/wsdl-first-jsr181-su/Users/ldangelo/Development/servicemix/trunk/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml]
Also if you notice the actuall error message:
Embedded error: Unable to generate service unit descriptor!
Users/ldangelo/Development/servicemix/trunk/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
(No such file or directory)
The leading slash is missing? It should be /Users... Any idea how to work
around/fix this issue?
-LeoD
Antoni Reus wrote:
It seems there is a problem in samples:
It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
mvn -Dmaven.test.skip=true -Dprofile=step2 install, fails with:
[INFO]
[INFO] Building ServiceMix :: Samples :: WSDL first :: JSR181
[INFO]task-segment: [install]
[INFO]
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
11/08/200It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml6
09:41:37 org.codehaus.xfire.gen.Wsdl11Generator generate
INFO: Generating code for WSDL at
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
with a base URI of
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
org/apache/servicemix/samples/wsdl_first/types/GetPersonRequest.java
org/apache/servicemix/samples/wsdl_first/types/GetPersonResponse.java
org/apache/servicemix/samples/wsdl_first/types/ObjectFactory.java
org/apache/servicemix/samples/wsdl_first/types/UnknownPersonFault.java
org/apache/servicemix/samples/wsdl_first/types/package-info.java
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class org.apache.servicemix.samples.wsdl_first.Person
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class
org.apache.servicemix.samples.wsdl_first.PersonServiceImpl
org/apache/servicemix/samples/wsdl_first/Person.java
org/apache/servicemix/samples/wsdl_first/PersonServiceImpl.java
org/apache/servicemix/samples/wsdl_first/PersonServiceService.java
org/apache/servicemix/samples/wsdl_first/UnknownPersonFault.java
[INFO] Executed tasks
[INFO] Registering compile source root
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/target/jaxws
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/target/classes
[INFO] [jbi:generate-jbi-service-unit-descriptor]
[INFO] Generating jbi.xml
[INFO] Created Service Unit Analyzer
[EMAIL PROTECTED]
2006-08-11 09:41:38,733 [main ] INFO
CollectionFactory - JDK 1.4+ collections available
2006-08-11 09:41:38,743 [main ] INFO
CollectionFactory - Commons Collections 3.x available
2006-08-11 09:41:38,785 [main ] INFO
XBeanXmlBeanDefinitionReader - Loading XML bean definitions from file
[/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to generate jbi.xml
Embedded error: Unable to generate service unit descriptor!
home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
(No such file or directory)
Salut.
--
Antoni Reus Darder
Cap de Projecte
Administració Digital, Negoci Electrònic i Sanitat
F u n d a c i ó I B I T
Illes Balears Innovació Tecnològica
http://www.ibit.org
Tel. +34 971 17 72 70/71
Fax. +34 971 17 72 79
--
View this message in context:
http://www.nabble.com/build-broken-tf2089208.html#a5782296
Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Is PackagingCommandLine still used anywhere?
On Aug 11, 2006, at 9:13 PM, Jason Dillon wrote: Anyone know? IIRC it was an experiment that didn't work out. If the online deployer doesn't use it and the maven car plugin doesn't use it nothing uses it. thanks david jencks --jason
Re: What is left to merge from dead-1.2?
On Aug 12, 2006, at 12:19 AM, Matt Hogstrom wrote: I don't have anything left in dead-1.2. Jason, perhaps we can propose a deadline of next Friday for completing the work or raising an issue. That way we'll be able to put this baby to bed :) I have some doubts I will be able to finish reviewing dead-1.2 for changes to apply to trunk by next friday, but I'll try. I also doubt many of the others who committed work to that branch have migrated it. Check the all_changes.log in trunk and make sure your changes are marked as merged. When all changes here are marked merged I'll be OK with deleting the dead-1.2 branch and not before. thanks david jencks Jason Dillon wrote: Can we get this finished... so we can move forward and setup modules to use the m2 standard layout? Also, if there is a list of modules which no merge is needed, we can update them now. Anyone know? --jason
Re: car plugin changes... geronimo-plugin.xml, etc.
On Aug 12, 2006, at 1:52 PM, Jason Dillon wrote: On Aug 12, 2006, at 6:56 AM, anita kulshreshtha wrote: Since the m1 build will be dropped and you have changed the plans, it should be possible to remove the velocity merge. Nope, the plan.xml is not being filtered as a normal resources at the moment, so we still need velocity there... or replace that with the same mechanism that the resources plugin is using. The daytrader generates 3 artifacts. They must (?) each get notice.txt, etc and then get zipped. They are installed using the attached artifacts. I'm not really worried about DayTrader now... I'd like to get trunk sorted first, then I can work on the external projects. I suggest you work with daytrader right now, or you will not know if your changes have any hope of working with multiple output cars. thanks david jencks --jason
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
Exactly, that's what I have been thinking too. Let me work on it a bit more. I was thinking whether to introduce a scripting or rules engine support such as Groovy or Drools to handle the rules, your thoughts. Yeah, I agree about the EIP component-wiretap. Let me also utilize it. Soumadeep On 8/13/06, Guillaume Nodet [EMAIL PROTECTED] wrote: If the xml content is a stream, you first need to transform it to a re-readable xml source before any processing can be applied. The EIP component does this and still give a NormalizedMessage (take a look at it: oa.s.eip.support.MessageUtil). You should really take a look at the wire tap implementation, as this is the exact same thing that the BAM component does. If the Rule does not use a simple interface, the component has to handle all your 16 cases internally. I would prefer an extensible design, where the component would first implement the xpath rule on the content and where rules could be written by users for custom things. And as you say, even a test on a property could have lots of different implementations: someone may want to test a string property which will match a regular expression, or an integer value, ... I think all these cases can not be handled by the component, without leading to a bad xml schema and a code which will be difficult to maintain. On 8/12/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I actually agree with you in all accounts but just trying to decouple the config sources so that there is minimum dependency if it's fed from external sources. But either way the internal dependency will be there. One important thing that I need to mention here is that you had commented about having an interface for what to evaluate, such as properties,content etc... Let's discuss about this as the scope will broaden a lot: The possible sources that one could monitor are: From the MessageExchange: (These in my opinion are not relevant as they are more application specific and not content specific) 1) Endpoint 2) Error 3) ExchangeId 4) Fault 5) InterfaceName 6) Operation 7) Pattern 8) Property 9) Role 10) Service 11) Status 12) IsTransacted 13) Message For (13) Message alone could have 13.1) Attachment (have to deal with DataHandler) 13.2) Property (handle Object) 13.3) SecuritySubject ( subject and principal) 13.4) Content (xml- being handled now) The rule definition will change as each of the above needs to be uniquely handled. This will get pretty complicated as we may then have to have an interface for the Rule and have different implementations, example - XPathRule could be an implementation where we can handle it based on what we have, PropertyBasedRule would introduce another story where the evaluation could be expression based, With attachment it could be anything - depends on the DahaHandler... So rather than having Object evaluate(NormalizedMessage message) we could have an interface for the BAMProcessor and pass appropriate values to the implementation. The other thing is we can't pass the NormalizedMessage directly to the processor as it's an async operation so we should not wait for any values to be passed from the processor. It will make it blocking. (as in the processor we may take the content out so there would be no content left after delegation to the processor) Your thoughts... Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Saturday, August 12, 2006 2:36 PM Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component On 8/11/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks for the reply, my comments are inline... - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Friday, August 11, 2006 3:02 PM Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component A few comments: 1) Files should include the Apache standard header Will include them 2) resources are loaded with xbean in BAMEndpoint.process they override any definition specified directly with the rules, actions properties IMHO, they should be loaded when activate is called (or at initialization time, by implementing the spring interface InitializingBean) and only if the properties are not set I had kept both ways to load properties, but going forward I think resource based file loading would be the most appropriate solution so will keep that and remove the embedded beans defn. from BAMEndpoint. Let me know if I missing the point. Mmmh, i guess it depend. Having to create 4 xml files instead of 1 is not always the easiest way ... 3) I don't see any use of the BAMGlobalConfig / Params classes This has been kept for future use where global parameters can be defined and used by adaptors as well as actions and rules 4)
[jira] Created: (SM-536) The defaultMep is a mandatory attribute on consumer endpoints and should be checked
The defaultMep is a mandatory attribute on consumer endpoints and should be checked --- Key: SM-536 URL: https://issues.apache.org/activemq/browse/SM-536 Project: ServiceMix Issue Type: Bug Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Fix For: 3.0-M3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-537) Define several endpoint implementations instead of having only one
Define several endpoint implementations instead of having only one -- Key: SM-537 URL: https://issues.apache.org/activemq/browse/SM-537 Project: ServiceMix Issue Type: Improvement Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet It would be much more easy to know which kind of endpoint is it and which attributes are mandatory. Having more specialized classes will also be easier to maintain. http:consumer ... http:provider ... jms:consumer .. jms:provider jms:jca-consumer ... jms:jca-provider .. jms:amq-consumer jms:amq-provider .. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
On 8/13/06, soumadeep sen [EMAIL PROTECTED] wrote: Exactly, that's what I have been thinking too. Cool :) Let me work on it a bit more. I was thinking whether to introduce a scripting or rules engine support such as Groovy or Drools to handle the rules, your thoughts. Note that spring has built-in support for Groovy. See http://static.springframework.org/spring/docs/2.0.x/reference/dynamic-language.html#dynamic-language-beans-groovy I was also thinking that the BAM component could leverage a rule engine features such as Drools, but i have not tought about it more yet. You can take a look at the Drools lightweight commponent, it may be helpfull. Yeah, I agree about the EIP component-wiretap. Let me also utilize it. Note that if you put a WireTap in front of the BAM component, the NMR will already process this message asynchronously without delaying the main exchange processing and the BAM component would not need to have an internal thread pool to process the exchanges asynchronously (it would only receive InOnly exchanges to process). Though i'm still not sure if this is the best way to go, as you would need a WireTap endpoint in front of all your BAM endpoints. The other way would be to include the eip component jar and inherit the WireTap to reuse the code as much as possible. Soumadeep On 8/13/06, Guillaume Nodet [EMAIL PROTECTED] wrote: If the xml content is a stream, you first need to transform it to a re-readable xml source before any processing can be applied. The EIP component does this and still give a NormalizedMessage (take a look at it: oa.s.eip.support.MessageUtil). You should really take a look at the wire tap implementation, as this is the exact same thing that the BAM component does. If the Rule does not use a simple interface, the component has to handle all your 16 cases internally. I would prefer an extensible design, where the component would first implement the xpath rule on the content and where rules could be written by users for custom things. And as you say, even a test on a property could have lots of different implementations: someone may want to test a string property which will match a regular expression, or an integer value, ... I think all these cases can not be handled by the component, without leading to a bad xml schema and a code which will be difficult to maintain. On 8/12/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I actually agree with you in all accounts but just trying to decouple the config sources so that there is minimum dependency if it's fed from external sources. But either way the internal dependency will be there. One important thing that I need to mention here is that you had commented about having an interface for what to evaluate, such as properties,content etc... Let's discuss about this as the scope will broaden a lot: The possible sources that one could monitor are: From the MessageExchange: (These in my opinion are not relevant as they are more application specific and not content specific) 1) Endpoint 2) Error 3) ExchangeId 4) Fault 5) InterfaceName 6) Operation 7) Pattern 8) Property 9) Role 10) Service 11) Status 12) IsTransacted 13) Message For (13) Message alone could have 13.1) Attachment (have to deal with DataHandler) 13.2) Property (handle Object) 13.3) SecuritySubject ( subject and principal) 13.4) Content (xml- being handled now) The rule definition will change as each of the above needs to be uniquely handled. This will get pretty complicated as we may then have to have an interface for the Rule and have different implementations, example - XPathRule could be an implementation where we can handle it based on what we have, PropertyBasedRule would introduce another story where the evaluation could be expression based, With attachment it could be anything - depends on the DahaHandler... So rather than having Object evaluate(NormalizedMessage message) we could have an interface for the BAMProcessor and pass appropriate values to the implementation. The other thing is we can't pass the NormalizedMessage directly to the processor as it's an async operation so we should not wait for any values to be passed from the processor. It will make it blocking. (as in the processor we may take the content out so there would be no content left after delegation to the processor) Your thoughts... Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Saturday, August 12, 2006 2:36 PM Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component On 8/11/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks for the reply, my comments are inline... - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Friday, August 11,
Re: build broken
So it may be a platform issue. Philip, could you take a look at it ?
On 8/13/06, ldangelo [EMAIL PROTECTED] wrote:
I'm having the same problem... I am using java version 1.5 on Mac OS X
Tiger... if I execute mvn with -X I see something interesting...
The path for the Bean file appears to be invalid... Here is the output:
2006-08-13 01:02:19,948 [main ]
INFO XBeanXmlBeanDefinitionReader
- Loading XML bean definitions from file
[/Users/ldangelo/Development/servicemix/trunk/samples/wsdl-first/wsdl-first-jsr181-su/Users/ldangelo/Development/servicemix/trunk/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml]
Also if you notice the actuall error message:
Embedded error: Unable to generate service unit descriptor!
Users/ldangelo/Development/servicemix/trunk/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
(No such file or directory)
The leading slash is missing? It should be /Users... Any idea how to
work
around/fix this issue?
-LeoD
Antoni Reus wrote:
It seems there is a problem in samples:
It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
mvn -Dmaven.test.skip=true -Dprofile=step2 install, fails with:
[INFO]
[INFO] Building ServiceMix :: Samples :: WSDL first :: JSR181
[INFO]task-segment: [install]
[INFO]
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
11/08/200It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml6
09:41:37 org.codehaus.xfire.gen.Wsdl11Generator generate
INFO: Generating code for WSDL at
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
with a base URI of
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
org/apache/servicemix/samples/wsdl_first/types/GetPersonRequest.java
org/apache/servicemix/samples/wsdl_first/types/GetPersonResponse.java
org/apache/servicemix/samples/wsdl_first/types/ObjectFactory.java
org/apache/servicemix/samples/wsdl_first/types/UnknownPersonFault.java
org/apache/servicemix/samples/wsdl_first/types/package-info.java
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class org.apache.servicemix.samples.wsdl_first.Person
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class
org.apache.servicemix.samples.wsdl_first.PersonServiceImpl
org/apache/servicemix/samples/wsdl_first/Person.java
org/apache/servicemix/samples/wsdl_first/PersonServiceImpl.java
org/apache/servicemix/samples/wsdl_first/PersonServiceService.java
org/apache/servicemix/samples/wsdl_first/UnknownPersonFault.java
[INFO] Executed tasks
[INFO] Registering compile source root
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/target/jaxws
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/target/classes
[INFO] [jbi:generate-jbi-service-unit-descriptor]
[INFO] Generating jbi.xml
[INFO] Created Service Unit Analyzer
[EMAIL PROTECTED]
2006-08-11 09:41:38,733 [main ] INFO
CollectionFactory - JDK 1.4+ collections available
2006-08-11 09:41:38,743 [main ] INFO
CollectionFactory - Commons Collections 3.x available
2006-08-11 09:41:38,785 [main ] INFO
XBeanXmlBeanDefinitionReader - Loading XML bean definitions from file
[/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to generate jbi.xml
Embedded error: Unable to generate service unit descriptor!
home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
(No such file or directory)
Salut.
--
Antoni Reus Darder
Cap de Projecte
Administració Digital, Negoci Electrònic i Sanitat
F u n d a c i ó I B I T
Illes Balears Innovació Tecnològica
http://www.ibit.org
Tel. +34 971 17 72 70/71
Fax. +34 971 17 72 79
--
View this message in context:
Re: Is PackagingCommandLine still used anywhere?
It been nuked. --jason On Aug 12, 2006, at 11:25 PM, David Jencks wrote: On Aug 11, 2006, at 9:13 PM, Jason Dillon wrote: Anyone know? IIRC it was an experiment that didn't work out. If the online deployer doesn't use it and the maven car plugin doesn't use it nothing uses it. thanks david jencks --jason
Re: car plugin changes... geronimo-plugin.xml, etc.
I can peek at it soon... now that it appears that trunk and gplugins are sorted. --jason On Aug 12, 2006, at 11:34 PM, David Jencks wrote: On Aug 12, 2006, at 1:52 PM, Jason Dillon wrote: On Aug 12, 2006, at 6:56 AM, anita kulshreshtha wrote: Since the m1 build will be dropped and you have changed the plans, it should be possible to remove the velocity merge. Nope, the plan.xml is not being filtered as a normal resources at the moment, so we still need velocity there... or replace that with the same mechanism that the resources plugin is using. The daytrader generates 3 artifacts. They must (?) each get notice.txt, etc and then get zipped. They are installed using the attached artifacts. I'm not really worried about DayTrader now... I'd like to get trunk sorted first, then I can work on the external projects. I suggest you work with daytrader right now, or you will not know if your changes have any hope of working with multiple output cars. thanks david jencks --jason
Re: What is left to merge from dead-1.2?
I am not really concerned about deleting the dead-1.2 branch... but I'd like to start reorganizing the module structure to the m2 standard. --jason On Aug 12, 2006, at 11:28 PM, David Jencks wrote: On Aug 12, 2006, at 12:19 AM, Matt Hogstrom wrote: I don't have anything left in dead-1.2. Jason, perhaps we can propose a deadline of next Friday for completing the work or raising an issue. That way we'll be able to put this baby to bed :) I have some doubts I will be able to finish reviewing dead-1.2 for changes to apply to trunk by next friday, but I'll try. I also doubt many of the others who committed work to that branch have migrated it. Check the all_changes.log in trunk and make sure your changes are marked as merged. When all changes here are marked merged I'll be OK with deleting the dead-1.2 branch and not before. thanks david jencks Jason Dillon wrote: Can we get this finished... so we can move forward and setup modules to use the m2 standard layout? Also, if there is a list of modules which no merge is needed, we can update them now. Anyone know? --jason
New car-maven-plugin issue
So I can build Plugin A (quartz-scheduler). But the build for Plugin B (quartz-deployer) which depends on Plugin A fails to create the CAR with an error like this: INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.gplugins.quartz.QuartzScheduler in classloader gplugins/quartz-deployer/0.3/car [INFO] [INFO] Trace java.lang.NoClassDefFoundError: org.gplugins.quartz.QuartzScheduler in classloader gplugins/quartz-deployer/0.3/car ... at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:76) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) So it's saying that a quartz-deployer GBean can't find a quartz-scheduler class. Now, both the POM for quartz-deployer and the plan for quartz-deployer include an entry for the quartz-scheduler CAR: POM: dependency groupIdgplugins/groupId artifactIdquartz-scheduler/artifactId scopeprovided/scope typecar/type /dependency target/plan/plan.xml: dependency groupIdgplugins/groupId artifactIdquartz-scheduler/artifactId typecar/type /dependency And when I deploy the quartz-deployer JAR by hand using the plan at target/plan/plan.xml, then it works fine. What I don't understand is, how can service-config-builder not load the quartz-scheduler CAR dependency and then claim that the classes are missing? If it loaded the dependency, the classes should be there (e.g. it works if deployed to a real server). If it didn't load the dependency, why didn't it get a missing dependency error? Thanks, Aaron
[jira] Updated: (AMQ-874) The Activemq-cpp example code no longer builds.
[ https://issues.apache.org/activemq/browse/AMQ-874?page=all ] Timothy Bish updated AMQ-874: - Attachment: example-patch-081306.txt This patch contains a fixed exmaple main.cpp that will now compile. There is also a new VC2005 project file for the exmaple. The Activemq-cpp example code no longer builds. --- Key: AMQ-874 URL: https://issues.apache.org/activemq/browse/AMQ-874 Project: ActiveMQ Issue Type: Bug Components: CMS (C++ client) Reporter: Timothy Bish Assigned To: Timothy Bish Priority: Minor Attachments: example-patch-081306.txt Code in the Activemq-cpp example is no longer up to date with the latest version. We need to clean this code up to match the samll changes in the CMS interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-874) The Activemq-cpp example code no longer builds.
[ https://issues.apache.org/activemq/browse/AMQ-874?page=all ] Timothy Bish reassigned AMQ-874: Assignee: Nathan Mittler (was: Timothy Bish) Nate, I'm assigning this to you so that it can be applied ASAP, since I don't have commit access yet. The Activemq-cpp example code no longer builds. --- Key: AMQ-874 URL: https://issues.apache.org/activemq/browse/AMQ-874 Project: ActiveMQ Issue Type: Bug Components: CMS (C++ client) Reporter: Timothy Bish Assigned To: Nathan Mittler Priority: Minor Attachments: example-patch-081306.txt Code in the Activemq-cpp example is no longer up to date with the latest version. We need to clean this code up to match the samll changes in the CMS interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: What is left to merge from dead-1.2?
I marked all of my remaining changes as Unnecessary as they are all simple changes the the build system which are not longer necessary. -dain On Aug 12, 2006, at 11:28 PM, David Jencks wrote: On Aug 12, 2006, at 12:19 AM, Matt Hogstrom wrote: I don't have anything left in dead-1.2. Jason, perhaps we can propose a deadline of next Friday for completing the work or raising an issue. That way we'll be able to put this baby to bed :) I have some doubts I will be able to finish reviewing dead-1.2 for changes to apply to trunk by next friday, but I'll try. I also doubt many of the others who committed work to that branch have migrated it. Check the all_changes.log in trunk and make sure your changes are marked as merged. When all changes here are marked merged I'll be OK with deleting the dead-1.2 branch and not before. thanks david jencks Jason Dillon wrote: Can we get this finished... so we can move forward and setup modules to use the m2 standard layout? Also, if there is a list of modules which no merge is needed, we can update them now. Anyone know? --jason
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 12, 2006, at 10:03 PM, Jeff Genender wrote:
David Blevins wrote:
Seems like I'm walking in mid-conversation, but I hope I can add some
details.
On Aug 11, 2006, at 8:30 PM, Aaron Mulder wrote:
On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote:
Ok, I understand where you are going with this. I totally agree
with
your thinking here. But...IIUC...in the web app, if you are
including
your own PU, you likely wouldn't be using the JNDI (and thus the
container) for this and would be declaring use of the spi bootstrap
directly:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(mywebpersistenceunit)
That's one way any component (servlet, ejb, ee app client, or java se
app) can get an EntityManagerFactory. But as Aaron says, anyone
(servlet, ejb, ee app client) who wants a DataSource managed by the
container has to use JNDI or dependecy injection (which is JNDI
driven
in JEE).
Well...that wasn't my point ;-) My point was there was no reason to
access the JNDI to get an EMF for a stand alone web app. However,
there
is nothing wrong with the persistence.xml declaring access to the JNDI
for the datasource...even in a stand alone web app... i.e:
persistence
persistence-unit name=myPU transaction-type=JTA
jta-data-sourcejava:/MySQLDS/jta-data-source
...
In this case...the code I showed could still apply to get a container
managed datasource...as does yours ;-)
Just checked my spec again and it looks like we're both wrong,
support for Persistence.createEntityManagerFactory isn't required in
an EE environment. It'd probably be a good idea to support if other
EE platforms will be supporting it, though.
-David
Jeff
E.g. a Servlet with this:
public class MySerlvet extends HttpServlet {
@Resource EntityManagerFactory myEmf;
}
Or the equivalent EJB:
@Stateful public class ShoppingCart {
@Resource EntityManagerFactory myEmf;
}
At this moment it won't be a problem, since the plugin only supports
web apps, but with Blevins' expertise it should be easy enough to
support EJB JARs too. Eventually we'll need to get clever --
perhaps
detecting that correctly-named JPA GBeans already exist in the
parent
tree so it's not necessary to redefine them for the web app. In
fact,
that's probably the way to go.
Happy to help in whatever approach you're taking. As I mentioned my
current thinking is to wrap JNDI with an extended JNDI and put
the JPA
resources in there so EJBs or Servlets that have persistence.xml
files
in their archives can use them. I like your idea on checking to
see if
a gbean is already defined and not redefining it (it being the JPA
factory). From a spec perspective, I can find anything that requires
this. Have you found something? Best I can find is that the
persistence classes themselves (i.e. your persistent pojo classes)
have
to come from the same classloader and can't be reloaded in a child
classloader if they were also listed in a parent classloader.
-David
Thanks,
Aaron
And when using the EJB, you would call the JNDI. Therefore, I
don't
think this is a problem at all.
Thanks,
Aaron
But unless
the spi jar uses some sort of mechanism using static
declarations or
componanents like Spring, then it really shouldn't be an issue.
If it
is, I think its reasonable to claim storage of duplicate PUs in
the same
package causing the problem (again, like the Spring Commons
Logging
problem).
Thanks,
Aaron
Aaron Mulder wrote:
So what happens if an EJB JAR has a persistence.xml and a web
app in
the same EAR has a separate persistence.xml? If we just look
in the
class loader, when we go to deploy the web app, we'll see
them both
because the EJB JAR is added to the parent classpath of the
WAR. Is
there a good way to distinguish resource in my ClassLoader
from
resources in my ClassLoader tree?
Thanks,
Aaron
Re: Build failure on branches/1.1.1
I swa the same on Friday and was going to checkout a new set of branches to make sure I hadn't cobbled anything up. Looks like its chronic :( I think it started after the security fix but need to verify if that is the culprit. Aaron Mulder wrote: I just tried to build this branche from scratch and I get a dependency failure in the OpenEJB deployer on Axis. I confirmed that my OpenEJB is http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2. Thanks, Aaron + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but openejb-builder-2.1.1-SNAPSHOT.jar may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository [mkdir] Created dir: /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository Packaging configuration /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/plan/plan.xml 15:14:17,919 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5a100f07.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:472) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute(PackageBuilderShell.java:291) at
Re: Build failure on branches/1.1.1
Doesn't look like Alan's changes caused the problem -- they were pretty small and localized. The openejb-builder failures appear to be caused by a typo in axis-builder project.xml introduced as part of the NOTICE changes. Kevan is looking and has found at least one more bad project.xml too. Thanks, Aaron On 8/13/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I swa the same on Friday and was going to checkout a new set of branches to make sure I hadn't cobbled anything up. Looks like its chronic :( I think it started after the security fix but need to verify if that is the culprit. Aaron Mulder wrote: I just tried to build this branche from scratch and I get a dependency failure in the OpenEJB deployer on Axis. I confirmed that my OpenEJB is http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2. Thanks, Aaron + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but openejb-builder-2.1.1-SNAPSHOT.jar may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository [mkdir] Created dir: /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository Packaging configuration /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/plan/plan.xml 15:14:17,919 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5a100f07.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:472) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:332) at
Re: Build failure on branches/1.1.1
OK, the project.xml fixes helped, but we're still getting the failures in configs, e.g.: + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + ... 16:16:39,866 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler It doesn't look like much has changed in the modules in question for quite some time... Looking at branches/1.1: openejb/modules/openejb-builder: 12 days configs/openejb-deployer: 7 weeks plugins/geronimo-packaging-plugin: 11 days, except NOTICE change I did discover that the OpenEJB 2.1.2 branch was still using the Geronimo 1.1.1 M1 plugins instead of the Geronimo 1.1.2 M1 plugins, but wiping out all my Geronimo M1 plugins and fixing that didn't solve the problem. Any other ideas what might have changed to cause this? Something that would make dependencies suddenly fail during CAR packaging? Thanks, Aaron On 8/13/06, Aaron Mulder [EMAIL PROTECTED] wrote: Doesn't look like Alan's changes caused the problem -- they were pretty small and localized. The openejb-builder failures appear to be caused by a typo in axis-builder project.xml introduced as part of the NOTICE changes. Kevan is looking and has found at least one more bad project.xml too. Thanks, Aaron On 8/13/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I swa the same on Friday and was going to checkout a new set of branches to make sure I hadn't cobbled anything up. Looks like its chronic :( I think it started after the security fix but need to verify if that is the culprit. Aaron Mulder wrote: I just tried to build this branche from scratch and I get a dependency failure in the OpenEJB deployer on Axis. I confirmed that my OpenEJB is http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2. Thanks, Aaron + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but openejb-builder-2.1.1-SNAPSHOT.jar may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository [mkdir] Created dir: /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository Packaging configuration /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/plan/plan.xml 15:14:17,919 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at
Issues with generics in maven-JBI-plugin -FYI
While compiling custom components generated from maven jbi plugin, if maven complains about generics are not supported in 1.3 then add the fragment below in your POM file (in the plugins section). This would only happen if you used generics in your java code! plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId !-- best lock down version of the plugin too -- configuration source1.5/source target1.5/target /configuration /plugin Thanks Soumadeep
Re: Issues with generics in maven-JBI-plugin -FYI
Well, this happen as soon as you use JDK 5 features ;) On 8/13/06, soumadeep sen [EMAIL PROTECTED] wrote: While compiling custom components generated from maven jbi plugin, if maven complains about generics are not supported in 1.3 then add the fragment below in your POM file (in the plugins section). This would only happen if you used generics in your java code! plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId !-- best lock down version of the plugin too -- configuration source1.5/source target1.5/target /configuration /plugin Thanks Soumadeep -- Cheers, Guillaume Nodet
XBean and QDox
It seems that nobody work on QDox since several months. (see http://www.nabble.com/Anyone-developing-QDox--tf705135r1.html)Does anyone know of any replacement we could use to allow java 5 parsing ? I was thinking of introducing real annotations, but this would make xbean-springJDK 5 specific. Any thoughts ?-- Cheers,Guillaume Nodet
Re: Build failure on branches/1.1.1
OK, I think I'm going to leave this for now, but... It looks like the problem below is definitely that as of a few days ago, configs/openejb-deployer/target/plan/plan.xml had a dependency on axis, and now it doesn't. I still don't know what could have changed (other than the project.xml in openejb-builder or openejb-deployer or something with the dependency or packaging plugin) to change this. I guess the brute-force fix is to work through all the failing configs and mark the JARs in question as geronimo.dependency=true, but it would be nice to understand what changed. Thanks, Aaron On 8/13/06, Aaron Mulder [EMAIL PROTECTED] wrote: OK, the project.xml fixes helped, but we're still getting the failures in configs, e.g.: + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + ... 16:16:39,866 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler It doesn't look like much has changed in the modules in question for quite some time... Looking at branches/1.1: openejb/modules/openejb-builder: 12 days configs/openejb-deployer: 7 weeks plugins/geronimo-packaging-plugin: 11 days, except NOTICE change I did discover that the OpenEJB 2.1.2 branch was still using the Geronimo 1.1.1 M1 plugins instead of the Geronimo 1.1.2 M1 plugins, but wiping out all my Geronimo M1 plugins and fixing that didn't solve the problem. Any other ideas what might have changed to cause this? Something that would make dependencies suddenly fail during CAR packaging? Thanks, Aaron On 8/13/06, Aaron Mulder [EMAIL PROTECTED] wrote: Doesn't look like Alan's changes caused the problem -- they were pretty small and localized. The openejb-builder failures appear to be caused by a typo in axis-builder project.xml introduced as part of the NOTICE changes. Kevan is looking and has found at least one more bad project.xml too. Thanks, Aaron On 8/13/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I swa the same on Friday and was going to checkout a new set of branches to make sure I hadn't cobbled anything up. Looks like its chronic :( I think it started after the security fix but need to verify if that is the culprit. Aaron Mulder wrote: I just tried to build this branche from scratch and I get a dependency failure in the OpenEJB deployer on Axis. I confirmed that my OpenEJB is http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2. Thanks, Aaron + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but openejb-builder-2.1.1-SNAPSHOT.jar may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository [mkdir] Created dir: /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository Packaging configuration /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/plan/plan.xml 15:14:17,919 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at
Console JACC Security Error in 1.1.1
I'm not sure if this is related to the recent web app security fix or not. I hacked the build enough that I got the 1.1.1 server running. I went to the console, went to the database pool screen, selected that I wanted to create a new pool, filled out the name and DB type on that screen and hit submit, and got the error below. I have no idea why it only came up on that submission and not any of the previous ones (though it was the first POST request I think). Thanks, Aaron 18:19:51,940 WARN [/console] /console/portal/services/services_jdbc/_rp_services_jdbc_row1_col1_p1_adapterDisplayName/1_TranQL0x8Generic0x8JDBC0x8Resource0x8Adapter/_rp_services_jdbc_row1_col1_p1_rarPath/1_tranql0x3tranql-connector0x310x220x3rar/_rp_services_jdbc_row1_col1_p1_mode/1_params/_rp_services_jdbc_row1_col1_p1_driverClass/1_com0x2mysql0x2jdbc0x2Driver/_pm_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_dbtype/1_MySQL/_rp_services_jdbc_row1_col1_p1_urlPrototype/1_jdbc%3Amysql%3A0x30x3%7BHost%7D%3A%7BPort%7D0x3%7BDatabase%7D/_st_services_jdbc_row1_col1_p1/normal/_ps_services_jdbc_row1_col1_p1/normal/_pid/services_jdbc_row1_col1_p1/_md_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_name/1_JPAPool: java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:194) at org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:607) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:432) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWebApplicationHandler.java:58) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
[jira] Created: (SM-540) Add a new handler to force parsing the input message as a DOM
Add a new handler to force parsing the input message as a DOM - Key: SM-540 URL: https://issues.apache.org/activemq/browse/SM-540 Project: ServiceMix Issue Type: New Feature Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-540) Add a new handler to force parsing the input message as a DOM
[ https://issues.apache.org/activemq/browse/SM-540?page=all ] Guillaume Nodet resolved SM-540. Resolution: Fixed Author: gnodet Date: Sun Aug 13 15:33:12 2006 New Revision: 431259 URL: http://svn.apache.org/viewvc?rev=431259view=rev Log: SM-540: add a DOM handler to force parsing the input stream Added: incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/dom/ incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/dom/DomHandler.java Add a new handler to force parsing the input message as a DOM - Key: SM-540 URL: https://issues.apache.org/activemq/browse/SM-540 Project: ServiceMix Issue Type: New Feature Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-874) The Activemq-cpp example code no longer builds.
[ https://issues.apache.org/activemq/browse/AMQ-874?page=all ] Nathan Mittler resolved AMQ-874. Resolution: Fixed Patch has been applied to trunk. The Activemq-cpp example code no longer builds. --- Key: AMQ-874 URL: https://issues.apache.org/activemq/browse/AMQ-874 Project: ActiveMQ Issue Type: Bug Components: CMS (C++ client) Reporter: Timothy Bish Assigned To: Nathan Mittler Priority: Minor Attachments: example-patch-081306.txt Code in the Activemq-cpp example is no longer up to date with the latest version. We need to clean this code up to match the samll changes in the CMS interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: build broken
Works on OS X now as well... nice work!
-LeoD
Antoni Reus wrote:
It seems there is a problem in samples:
It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
mvn -Dmaven.test.skip=true -Dprofile=step2 install, fails with:
[INFO]
[INFO] Building ServiceMix :: Samples :: WSDL first :: JSR181
[INFO]task-segment: [install]
[INFO]
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
11/08/200It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml6
09:41:37 org.codehaus.xfire.gen.Wsdl11Generator generate
INFO: Generating code for WSDL at
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
with a base URI of
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
org/apache/servicemix/samples/wsdl_first/types/GetPersonRequest.java
org/apache/servicemix/samples/wsdl_first/types/GetPersonResponse.java
org/apache/servicemix/samples/wsdl_first/types/ObjectFactory.java
org/apache/servicemix/samples/wsdl_first/types/UnknownPersonFault.java
org/apache/servicemix/samples/wsdl_first/types/package-info.java
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class org.apache.servicemix.samples.wsdl_first.Person
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class
org.apache.servicemix.samples.wsdl_first.PersonServiceImpl
org/apache/servicemix/samples/wsdl_first/Person.java
org/apache/servicemix/samples/wsdl_first/PersonServiceImpl.java
org/apache/servicemix/samples/wsdl_first/PersonServiceService.java
org/apache/servicemix/samples/wsdl_first/UnknownPersonFault.java
[INFO] Executed tasks
[INFO] Registering compile source root
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/target/jaxws
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/target/classes
[INFO] [jbi:generate-jbi-service-unit-descriptor]
[INFO] Generating jbi.xml
[INFO] Created Service Unit Analyzer
[EMAIL PROTECTED]
2006-08-11 09:41:38,733 [main ] INFO
CollectionFactory - JDK 1.4+ collections available
2006-08-11 09:41:38,743 [main ] INFO
CollectionFactory - Commons Collections 3.x available
2006-08-11 09:41:38,785 [main ] INFO
XBeanXmlBeanDefinitionReader - Loading XML bean definitions from file
[/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to generate jbi.xml
Embedded error: Unable to generate service unit descriptor!
home/IBIT/areus/java/servicemix/servicemix-3.0-dev/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
(No such file or directory)
Salut.
--
Antoni Reus Darder
Cap de Projecte
Administració Digital, Negoci Electrònic i Sanitat
F u n d a c i ó I B I T
Illes Balears Innovació Tecnològica
http://www.ibit.org
Tel. +34 971 17 72 70/71
Fax. +34 971 17 72 79
--
View this message in context:
http://www.nabble.com/build-broken-tf2089208.html#a5789839
Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Java 1.4 and JEE 5
On 8/8/06, Andrus Adamchik [EMAIL PROTECTED] wrote: I'd like to chime in with the Cayenne JPA provider here. Could you point me in the right direction on how to approach integrating it with the plugin you are writing? Andrus, I've put the initial JPA plugin code up on SourceForge at SVN https://svn.sourceforge.net/svnroot/gplugins/jpa/trunk There's a JPA provider for TopLink in there (vendors/toplink) -- for Cayenne, you can probably just copy that module and change the ToplinkProvider class to a CayenneProvider class. We'd also need to create a module like plugins/cayenne to hold the Geronimo deployment plan and plugin metadata for the Cayenne provider -- the main thing we need for that is a list of all the JARs that the Cayenne JPA provider will need on its class path. Regrettably, I don't think you'll be able to build this whole thing (specifically the plugins/* modules) as is because I'm waiting on some Geronimo archives to be posted to the Maven 2 repo. If you like, I can probably send you a zip of the missing modules that you could unpack into your local M2 repo to get the plugin modules to build. This also will only run on the as-yet-unreleased Geronimo 1.1.1 due to some bugs in G 1.1... I'm hoping the 1.1.1-rc1 will be available soon. Thanks, Aaron
JPA Plugin Status
The code for the app-managed-JPA-for-web-apps plugin is up at SVN https://svn.sourceforge.net/svnroot/gplugins/jpa/trunk So far, it's just got a TopLink provider, but if people want to copy that to create providers for Cayenne or OpenJPA or whatever, that would be great. It basically just needs to have a customized name and ClassPath, though I'm assuming any provider we integrate with will be compatible with the Geronimo JPA spec JAR (currently org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) If you try to build and run this, you'll be held up by a couple things: * It needs the latest car-maven-plugin, and I'm not sure whether Jason has pushed a fresh snapshot since the last changes to it * It needs Geronimo 1.1 CARs in the M2 repo, and Matt has said posting those is on his to-do list * It only runs in Geronimo 1.1.1 due to reference resolution bugs in G 1.1, and currently the G 1.1.1 build is broken But if you get past all that (or comment out the plugins child from the main POM to avoid the first two issues) and run your server under Java 5, you can deploy web apps using JPA. :) My goal is to have a release of this plugin with sufficient user documentation when G 1.1.1 is released. It would be great to have some open source JPA providers for that release too. I also started talking to David B about the JPA work being done in OpenEJB, and I think we're agreed that we probably don't need two such plugins for G 1.1.x, so hopefully we can work toward a unification as we move forward. Thanks, Aaron
Re: Java 1.4 and JEE 5
Hi Aaron, Yeah, I'd appreciate if you could send me the missing stuff. Andrus On Aug 13, 2006, at 11:24 PM, Aaron Mulder wrote: On 8/8/06, Andrus Adamchik [EMAIL PROTECTED] wrote: I'd like to chime in with the Cayenne JPA provider here. Could you point me in the right direction on how to approach integrating it with the plugin you are writing? Andrus, I've put the initial JPA plugin code up on SourceForge at SVN https://svn.sourceforge.net/svnroot/gplugins/jpa/trunk There's a JPA provider for TopLink in there (vendors/toplink) -- for Cayenne, you can probably just copy that module and change the ToplinkProvider class to a CayenneProvider class. We'd also need to create a module like plugins/cayenne to hold the Geronimo deployment plan and plugin metadata for the Cayenne provider -- the main thing we need for that is a list of all the JARs that the Cayenne JPA provider will need on its class path. Regrettably, I don't think you'll be able to build this whole thing (specifically the plugins/* modules) as is because I'm waiting on some Geronimo archives to be posted to the Maven 2 repo. If you like, I can probably send you a zip of the missing modules that you could unpack into your local M2 repo to get the plugin modules to build. This also will only run on the as-yet-unreleased Geronimo 1.1.1 due to some bugs in G 1.1... I'm hoping the 1.1.1-rc1 will be available soon. Thanks, Aaron
Re: AJAX and Geronimo
This is a good idea Paul. Im not exactly sure how you would implement it but let me know if I can help with anything (testing, dev, docs, etc.). This will definitely help those who wanted to develop Ajax enabled apps in G. Also nice to have is if we can find a way to do the same thing for DWR if its possible. Cheers, chris --- Paul McMahan [EMAIL PROTECTED] wrote: Dojo is a popular open source AJAX library that's available under the BSD and Academic Free licenses. The DayTrader folks use it in the web UI they recently announced on the Geronimo dev list and Chris used it in the nice LDAP UI he did for GERONIMO-1823. I would also like to start introducing some use of it into the Geronimo admin console when its appropriate to do so. The way that developers usually incorporate an AJAX library into their applications is by making a copy of its static files (javascript, css, gifs, etc) in their webapp and referencing them from their servlets and JSPs. The obvious downside is that each application has a separate copy of the AJAX library, increasing the server's overall disk footprint (Dojo is ~3mb) and preventing the browser from using a single copy of the library files from its cache. Another downside is that the AJAX library can't be upgraded independently from the web application. I think it would be great if Geronimo could provide a more AJAX friendly development environment by helping solve these problems. One idea is that Geronimo could include the Dojo library as a native, standalone webapp with its AJAX library files laid out so that other applications can point at from their HTML. Referencing it in geronimo-web.xml would cause Geronimo to start it up and make its files available at some predetermined context root, say /dojo. Referencing it with a versionless moduleId would make sure the most recent version is always used. So AJAX enabling your application in Geronimo would be a simple as add this line to your geronimo-web.xml. Does this sound like a good idea? Any suggestions or concerns? Perhaps this could be done as a plugin instead of a native module? Best wishes, Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (XBEAN-39) NPE in XBeanHelper.createBeanDefinitionReader with some Classloaders
[ http://issues.apache.org/jira/browse/XBEAN-39?page=comments#action_12427800 ] Stefan Kleineikenscheidt commented on XBEAN-39: --- A fix of this issue at Spring seems to be on its way, too: http://opensource.atlassian.com/projects/spring/browse/SPR-2401 NPE in XBeanHelper.createBeanDefinitionReader with some Classloaders Key: XBEAN-39 URL: http://issues.apache.org/jira/browse/XBEAN-39 Project: XBean Issue Type: Bug Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5 Reporter: Stefan Kleineikenscheidt Assigned To: Guillaume Nodet Fix For: 2.6 Attachments: XBEAN-39.patch, XBEAN-39.patch XBean fails on systems with some classloaders, which do not return sensible values from the following methods pkg.getImplementationVersion(); or cl.getResourceAsStream(name); This leads to a) a NPE thrown by SpringVersion.getVersion, b) the property files with custom mappings are not found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
