RE: Interested in becoming a contributor

2006-07-03 Thread Grant McDonald
Hi James,

 Thanks for those Grant!

No problem: everybody benefits when people get involved.

 There's some documentation about it here...
 http://incubator.apache.org/servicemix/becoming-a-committer.html
 
 basically keep doing what you're doing and the committers will take a
 vote to grant you full commit karma. I take it you are interested in
 becoming a committer? :)

I read the doco at the earlier and I am definitely interested in becoming a
committer, so I'll keep submitting patches. Btw, do you mind if new
contributors like myself take a look at unassigned issues and attach
patches?  That's probably the quickest way to get some work done that
everybody can use.


Regards,

Grant


[jira] Created: (SM-481) servicemix-http provider truncates a large xml response

2006-07-03 Thread Pete (JIRA)
servicemix-http provider truncates a large xml response
---

 Key: SM-481
 URL: https://issues.apache.org/activemq/browse/SM-481
 Project: ServiceMix
Type: Bug

  Components: servicemix-http  
 Environment: windows xp professional.  Java 1.5 
Reporter: Pete 
Priority: Critical
 Fix For: incubation
 Attachments: soap_response.txt

When using servicemix-http as a provider, our provider web service returns a 
very large xml response, this gets truncated somewhere in servicemix (I did 
notice when debugging it went down the stax xml route) 
 
We had the same problem when using SaajBinding, we fixed this locally by 
extending the SaajBinding and overridng the

onMessageExchange

in particular just after the call() we added  response.saveChanges();  e.g.

SOAPMessage response = connection.call(inMessage, soapEndpoint);
response.saveChanges();  
 
This I believe was a known issue using this particular SAAJ implementation, 
which is why saveChanges() was added to the api.

see 
http://www.nabble.com/servicemix-http-provider-truncates-a-large-xml-response-tf1857975.html
 for forum post 

Our response xml is 673148 bytes. I have attached an example of the failing 
soap response. Note: you'll need to remove header stuff and save as xml.  The 
response has a single xml element, where embedded (as a string) is another xml 
document - nasty I know. 

XML Config is

!-- Http based client recieve/send html request/response passes message to a 
router component--
sm:activationSpec componentName=httpReceiver 
service=my:httpBinding endpoint=httpReceiver
destinationService=my:router
sm:component
bean 
xmlns=http://xbean.org/schemas/spring/1.0; 
class=org.apache.servicemix.components.http.HttpConnector
property name=host value=localhost 
/
property name=port value=8912 /
property name=marshaler
bean class=org.apache.servicemix.components.http.HttpMarshaler /
/property
/bean
/sm:component
/sm:activationSpec


Then there is an eip router that routes to

 sm:component
http:component
  http:endpoints
http:endpoint service=my:search
   endpoint=search
   role=provider
   soap=true
   
soapAction=http://www.blah.com/blah;
   
locationURI=http://www.blah.com:80/blah.asmx/
  /http:endpoints
/http:component
  /sm:component



-- 
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-480) Transitive dependencies of dependent projects not included in installer lib directory

2006-07-03 Thread Philip Dodds (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-480?page=all ]
 
Philip Dodds resolved SM-480:
-

Fix Version: incubation
 Resolution: Fixed

The problem was the different in versions between the dependency management and 
the transitive dependency - have added a warning and will use the version from 
the transitive dependency for packaging.

 Transitive dependencies of dependent projects not included in installer lib 
 directory
 -

  Key: SM-480
  URL: https://issues.apache.org/activemq/browse/SM-480
  Project: ServiceMix
 Type: Bug

   Components: tooling
 Versions: incubation
  Environment: Ubuntu Linux 5.10, Windows XP SP2
 Reporter: Grant McDonald
  Fix For: incubation


 Original Estimate: 2 days
 Remaining: 2 days

 Whilst using servicemix I got a NoClassDefFound error from the 
 servicemix-http service engine.  It appears that the code in question was 
 throwing a DecoderException which is defined in commons-codec which is a 
 transitive dependency of commons-httpclient.  This dependency was not 
 included in the installer lib directory and is obviously quite critical to 
 the running of httpclient.

-- 
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



ServiceMix Geronimo Plugin

2006-07-03 Thread Aaron Mulder

So Guillaume and I talked at ApacheCon EU, and we came up with the
following thoughts about ServiceMix integration into Geronimo.

Use Cases

* Deploy combined JBI/J2EE applications.  In the short term there may
not be one bundle such as a ZIP or EAR containing both types of
components, but they should be able to work well together.
  * A J2EE web application should be able to send messages to the JBI bus
  * A JBI service should be able to dispatch messages to a J2EE
endpoint (other than just an MDB via JMS, etc.).  Typically this would
be a stateless session bean.
  * Should be able to deploy both JBI and J2EE components using the
same deploy tool(s)
  * Eventually, should be able to deploy a combined package
containing both types of components, supporting bidirectional
dependencies (J2EE components send messages to JBI components in the
same app and vice versa)
* Manage Geronimo and ServiceMix together, via a combined admin
console, combined JMX space, etc.
* Share resources between Geronimo and ServiceMix
  * Same security realm for authentication and same Subject for authorization
  * Same transaction manager
  * Same HTTP server
  * Single source of SSL settings (keystores, passwords, etc.)  SSL factories

As I understand it, as of today:

* There are GBeans to start ServiceMix in Geronimo
* There is a builder to deploy JBI service assemblies to ServiceMix
using the Geronimo deploy tools (I'm not clear whether this can also
deploy JBI components, which actually seem more like containers)
* Some work has been done to leverage the Geronimo transaction manager
  * The JCA flow in ServiceMix may use the Geronimo transaction manager
* There is a ServiceMix admin console using the same technology as
the Geronimo admin console

So out of these, we have the following to-dos to create a ServiceMix
plugin for Geronimo 1.1:

* Try out the current ServiceMix Geronimo GBeans
* Confirm whether the JCA flow uses the Geronimo transasction manager correctly
* Update the GBeans to expose EJBs as endpoints for ServiceMix
(perhaps leveraging JSR-181 code for mapping normalized messages to
EJB invocations?)
* Provide a GBean that is a client factory -- so you can map this
factory into JNDI for a J2EE component, and it can look that up and
use it to generate a ServiceMixClient instance
   * Provide factories that support both client authentication
(caller specifies user/password if any) and container authentication
(e.g. Subject from web app login is passed to ServiceMix as is)
* Add a security provider to ServiceMix that uses Geronimo security
realms to authenticate and populate a Subject
* Update ServiceMix so it can use the Geronimo HTTP container for
HTTP/HTTPS binding components (allowing only configuring of the part
after http://host:port/context/ in the URL)
* Add the glue code to deploy the ServiceMix admin screens to the
Geronimo admin console when the ServiceMix features are added
* Create and document sample apps to call JBI-J2EE and vice versa

And the following that will require Geronimo code changes (in other
words, targeting G 1.2+):

* Provide a deployment unit that contains both J2EE and JBI
components (either an EAR with extra content or a ZIP containing both
a JBI service assembly and an EAR, etc.)
* Let ServiceMix initiate HTTP bindings on new ports, wtih fully
arbitrary URLs, etc.
* Update Geronimo keystore provider to offer the new functions that
ServiceMix needs

We thought it would be best for any work done on this in the short
term to happen in the ServiceMix SVN head (for GBeans and Geronimo
configus) using the ServiceMix 3.0-M2-incubating ServiceMix release
for the ServiceMix features, and the Geronimo 1.1 release for the
Geronimo features.

Anyone else have any thoughts about this?

Thanks,
   Aaron


Re: Transitive dependency problem with jbi maven plugin

2006-07-03 Thread Philip Dodds

Yeah the warning is in place to just show the problem has occurred though
you are right that probably managing situations like this in either changes
to the dependencyManagement or the pom

Cheers

P

On 7/3/06, Grant McDonald [EMAIL PROTECTED] wrote:


I tried something similar by switching off the lines I mentioned in the
issue report. This had the effect of including commons-codec-1.2 instead
of
1.3 which actually caused servicemix to completely crash since the
versions
had different encoding/decoding formats (this was using the trunk as of
2006-06-28 with a few custom patches).  When I explicitly added
commons-codec-1.3 as a dependency in servicemix-http this problem went
away.
So it may be that fine tuning is needed in some cases with regards to
transitive dependencies (either that or just use the override from the
parent pom.

-Original Message-
From: Philip Dodds [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 4 July 2006 12:27 AM
To: servicemix-dev@geronimo.apache.org
Subject: Re: Transitive dependency problem with jbi maven plugin


The problem was that the version found through the transitive dependency
was
not the same as the version from the top level pom's dependency management
-
I have switched it so that in this case a warning it thrown but the
version
from the transitive dependency it packaged into the installer.

P

On 7/2/06, Grant McDonald [EMAIL PROTECTED] wrote:


 This appears to be due to line 181 in GenerateComponentMojo.java in the
 jbi-maven-plugin project.  At this point the includes are refiltered
based
 on the JbiResolutionListener created for the project.  This seems to
eject
 some dependencies of subprojects needs more investigation.
 --
 View this message in context:


http://www.nabble.com/Transitive-dependency-problem-with-jbi-maven-plugin-tf
1879526.html#a5139375
 Sent from the ServiceMix - Dev forum at Nabble.com.