RE: Remote deployment of service assemblies
Thanks! Ciao, Philipp > -Mensaje original- > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 17 de mayo de 2007 15:21 > Para: [EMAIL PROTECTED] > Asunto: Re: Remote deployment of service assemblies > > See http://issues.apache.org/activemq/browse/SM-858 > which has been fixed a few weeks ago in trunk. > > On 5/17/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > After quite a break, I am back with the issue relating to this thread. > > What I did was creating a jsr-181 WSDL first service, for which I set a > > ComponentContext *). The setup is different from what had been outlined > > earlier, as I am creating a service assembly ZIP based on parameters I > > receive. > > > > My idea was to obtain a DeliveryChannelImpl from the ComponentContext > > and to then follow the steps Guillaume has pointed out below. > > > > However, the ComponentContext that is being set by SM is an > > EndpointComponentContext which doesn't give me access to this > > information. > > > > Any hints of how I can get hold of the JBIContainer or its > > AdminCommandsServiceMBean? > > > > Thanks in advance, > > Ciao, > > Philipp > > > > *) http://incubator.apache.org/servicemix/servicemix-jsr181.html > > **) For the moment, I am creating a service assembly zip file for WSN > > subscriptions once the service gets invoked. Parameters are the > > wsa:address, the topic and an identifier. > > > > > -Mensaje original- > > > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > > > Enviado el: martes, 20 de marzo de 2007 11:21 > > > Para: [EMAIL PROTECTED] > > > Asunto: Re: Remote deployment of service assemblies > > > > > > On 3/20/07, Rossmanith, Philipp <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > Once you have the JBIContainer, just retrieve the needed > > interface: > > > > > JBIContainer container = dci.getContainer(); > > > > > AdminCommandsServiceMBean admin = > > > > container.getAdminCommandsService(); > > > > > > > > > > Then, you can use it to deploy / undeploy, manage life cycle, etc > > .. > > > > >admin.installComponent() > > > > >admin.startComponent() > > > > >admin.listServiceAssemblies() ... > > > > Ok, that is quite a bit cleaner... > > > > > > > > > all the administrative tasks are available from this interface, so > > I > > > > guess > > > > > the WSDL > > > > > should be quite easy to write. On the implementation side, one > > way is > > > > to > > > > > use > > > > > jaxb2 (not the full jsr181 though) as done in the WS-Notification > > > > > component. > > > > > See org.apache.servicemix.wsn.component.WSNEndpoint class. > > > > What I was thinking about was a WSDL wrapper around the > > > > AdminCommandsServiceMBean methods. > > > > > > > > I'm currently investigating the WSN component to use it for > > > > notifications based on message content (see > > > > > > http://www.nabble.com/how-to-implement-runtime-notifications-based-on-Me > > > > ssageExchange--content-tf3409844s12049.html), but I must say I'm > > afraid > > > > I don't really understand your idea (which may be due to my limited > > > > experience with jaxb2). > > > > > > > > It seems to me that the wsn component WSNEndpoint uses the > > annotations > > > > done in the org.apache.servicemix.wsn.AbstractEndpoint hierarchy (an > > > > object of this class is passed in as "pojo" in the constructor) to > > > > obtain a class object "endpointInterface" which is then used to get > > hold > > > > of the methods published in that interface. Jaxb2 seems to be used > > to > > > > unmarshal incoming normalized message content and to marshal it to > > > > outgoing exchanges (method: process). > > > > > > > > However, if I'm ""only"" writing a provider service and not a > > > > full-fledged component, what would be the advantages of the approach > > > > taken in WSNEndpoint? > > > > > > > > Or am I misinterpreting, and you're using jaxb2 for creating a > >
RE: Remote deployment of service assemblies
Hi, > Once you have the JBIContainer, just retrieve the needed interface: > JBIContainer container = dci.getContainer(); > AdminCommandsServiceMBean admin = container.getAdminCommandsService(); > > Then, you can use it to deploy / undeploy, manage life cycle, etc .. >admin.installComponent() >admin.startComponent() >admin.listServiceAssemblies() ... Ok, that is quite a bit cleaner... > all the administrative tasks are available from this interface, so I guess > the WSDL > should be quite easy to write. On the implementation side, one way is to > use > jaxb2 (not the full jsr181 though) as done in the WS-Notification > component. > See org.apache.servicemix.wsn.component.WSNEndpoint class. What I was thinking about was a WSDL wrapper around the AdminCommandsServiceMBean methods. I'm currently investigating the WSN component to use it for notifications based on message content (see http://www.nabble.com/how-to-implement-runtime-notifications-based-on-Me ssageExchange--content-tf3409844s12049.html), but I must say I'm afraid I don't really understand your idea (which may be due to my limited experience with jaxb2). It seems to me that the wsn component WSNEndpoint uses the annotations done in the org.apache.servicemix.wsn.AbstractEndpoint hierarchy (an object of this class is passed in as "pojo" in the constructor) to obtain a class object "endpointInterface" which is then used to get hold of the methods published in that interface. Jaxb2 seems to be used to unmarshal incoming normalized message content and to marshal it to outgoing exchanges (method: process). However, if I'm ""only"" writing a provider service and not a full-fledged component, what would be the advantages of the approach taken in WSNEndpoint? Or am I misinterpreting, and you're using jaxb2 for creating a jsr181 code skeleton based on a previously generated WSDL? > .. and discussions about servicemix developement should take place on the > dev > list ... ;-) Done :-) Thanks in advance, Ciao, Philipp > -Mensaje original- > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Enviado el: lunes, 19 de marzo de 2007 16:56 > Para: servicemix-users@geronimo.apache.org > Asunto: Re: Remote deployment of service assemblies > Importancia: Baja > > On 3/19/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: > > > > > > > Currently, remote deployment is not supported by the ant tasks. > > > The only way to do currently that is to start a servicemix console > > > on the same server, because the console accepts uploads and will > > > be able to point the container to a local file. > > > > > > The only way using JMX would be to add a method accepting a byte[] > > > parameter which would be the content of the JBI artifact to deploy, or > > > creating an management endpoint on the JBI bus (using an attachment > > > for the JBI archetype). Not sure what's the best way. > > I was thinking about this alternative, as well. There could be a > > provider service that accepts calls having an SA attachment. It could > > then obtain this attachment and physically place it in the deployment > > dir. > > > Using the hot deployer is imo not the best solution. > We should use the AdminCommandsService instead (see below) > > In that way, one could use the same access control mechanism as for the > > rest of the service invocations. Another advantage would be that through > > the different binding components, the functionality would be available > > in more than just Java. > > > Yeah, agreed. We just need to define a clean WSDL for it. > > However, I'd need to access some JBIContainer properties, such as the > > deployment directory. I assume that the best way to obtain internals > > about the JBI container would be to use the client API > > (http://incubator.apache.org/servicemix/client-api.html). > > > > I could then use the following code: > > >> > > ... > > DeliveryChannelImpl dci = (DeliveryChannelImpl) > > defaultSMClientInstance.getDeliveryChannel(); > > JBIContainer container = dci.getContainer(); > > ... > > String deploymentDirPath = container.getDeploymentDirPath(); > > ... > > << > > > > However, this hack seems quite (if not: too) dirty. Is there a more > > elegant solution? > > > > Once you have the JBIContainer, just retrieve the needed interface: > JBIContainer container = dci.getContainer(); > AdminCommandsServiceMBean admin = container.getAdminCommandsService(); > > Then, you can use it to deploy / undeploy, manage life cycle, etc .. >admin.installComponen
RE: Doc reorg
Hi, I always liked the documentation of Apache Cocoon, where you have a separation into documentation for developers (people that want to hack code improving the framework) and users (people who want to use the framework without actually modifying it) and some other tracks. They solve the overload problem by having collapsible menus. Is that something that could be done for SM? Ciao, Philipp Rossmanith > -Mensaje original- > De: James Strachan [mailto:[EMAIL PROTECTED] > Enviado el: lunes, 05 de marzo de 2007 15:25 > Para: servicemix-dev@geronimo.apache.org > Asunto: Re: Doc reorg > > On 2/21/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > I think we need to reorg the docs so that one can more easily > > find the informations (we also need to write more docs, but that's > > another problem). Currently, the only way to really find a page is > > to go to the site map and browse ... > > > > Any ideas on how to do that ? > > Its a tricky one. In some ways having a kinda SiteMap menu thingy on > the home page/navigation bar can help folks who know-what-they-want > navigate quickly to the right stuff. Sometimes that can be kinda > overload where new users don't know where to start (e.g. in the past > the ActiveMQ site has suffered, and still does I think, from > navigation-bar-overload). > > Maybe we need to put a bit more of the SiteMap onto the Navigation > bar? I wonder if CSS style popup menus might help reduce some of the > clutter of the Navigation bar while adding more of the SiteMap to the > average user? > http://www.grc.com/menu2/invitro.htm > > -- > > James > --- > http://radio.weblogs.com/0112098/ This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
SM Correlation ID vs. ebMS conversation ID
Hi, We're having a scenario where business processes leave SM boundaries into external systems in order to return later on. Interfaces to these systems are HTTP Web services (SOAP 1.1). Some of the processes involve human tasks. Therefore, estimates about the duration cannot be made. What we would like to have is a mechanism allowing relating incoming (HTTP SOAP) messages to flows that have previously occurred, as intended by the ebMS*) ConversationId element.**) Questions: - SM's correlation ID***) seems to be rather similar. Does it intend to provide the same thing? - Why is SM's correlationId set as ThreadLocal?) Why is it limited to "[tracing] the flow of the messages inside a Service Assembly"? - What about extending servicemix-http to look for an eb:ConversationId in the SOAP header and setting it as the correlation ID? Thanks in advance, Ciao, Philipp Rossmanith *) See http://www.oasis-open.org/specs/index.php#ebxmlmsgv2 **) 3.1.3 ConversationId Element The REQUIRED ConversationId element is a string identifying the set of related messages that make up a conversation between two Parties. It MUST be unique within the context of the specified CPAId. The Party initiating a conversation determines the value of the ConversationId element that SHALL be reflected in all messages pertaining to that conversation. The ConversationId enables the recipient of a message to identify the instance of an application or process that generated or handled earlier messages within a conversation. It remains constant for all messages within a conversation. The value used for a ConversationId is implementation dependent. An example of the ConversationId element follows: 20001209-133003-28572 ***) See https://issues.apache.org/activemq/browse/SM-751, http://www.nabble.com/Flow-tracing-problem-tf2197129s12049.html ) See org.apache.servicemix.common.AsyncBaseLifeCycle This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
RE: Default constructor for JBIContainer changes log level?
Japp, will do. Ciao, Philipp Rossmanith > -Mensaje original- > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 15 de febrero de 2007 19:57 > Para: servicemix-dev@geronimo.apache.org > Asunto: Re: Default constructor for JBIContainer changes log level? > > Sure, commons-logging is configured. > Which in turns, starts log4j if included in the classpath. > By default, log4j will load a log4j.properties file ... > > And you're right. It seems that o.a.s.id.IdGenerator > calls the java.util.logging package. This is the only call > afaik and it should be removed. Can you raise a JIRA > for that ? > > On 2/15/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: > > > > P.s. JBIContainer doesn't seem to use org.apache.log4j, but makes calls > > to org.apache.commons.logging.Log and > > org.apache.commons.logging.LogFactory: > > >> > > private static final Log log = LogFactory.getLog(JBIContainer.class); > > << > > ... as well as to java.util.logging.Logger: > > >> > > public Logger getLogger(String suffix, String resourceBundleName) throws > > MissingResourceException, JBIException > > << > > > > Ciao, > > Philipp Rossmanith > > > > This e-mail may contain confidential or privileged information. Any > unauthorised > > copying, use or distribution of this information is strictly prohibited. > > > > > -- > Cheers, > Guillaume Nodet > > Architect, LogicBlaze (http://www.logicblaze.com/) > Blog: http://gnodet.blogspot.com/ This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
RE: Default constructor for JBIContainer changes log level?
P.s. JBIContainer doesn't seem to use org.apache.log4j, but makes calls to org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory: >> private static final Log log = LogFactory.getLog(JBIContainer.class); << ... as well as to java.util.logging.Logger: >> public Logger getLogger(String suffix, String resourceBundleName) throws MissingResourceException, JBIException << Ciao, Philipp Rossmanith This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
RE: Default constructor for JBIContainer changes log level?
Hi Guillaume, org.apache.servicemix.jbi.security.SecuredBrokerTest, line 63: jbi = new JBIContainer(); I created a Logger before this call and did a watch on it. Ciao, Philipp Rossmanith ITC Analyst Systems Integration T-Systems ITC Iberia S.A.U. Edifici 22@ Sancho d'Àvila 110-130 08018 Barcelona Office: + 34 93 501 56 22 Main: + 34 93 501 50 00 Fax:+ 34 93 501 52 41 Email: [EMAIL PROTECTED] Internet: www.t-systems.com > -Mensaje original- > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 15 de febrero de 2007 19:38 > Para: servicemix-dev@geronimo.apache.org > Asunto: Re: Default constructor for JBIContainer changes log level? > > Hi Philipp ! > > Can you point where this happen ? > I don't recall any log4j direct calls in servicemix but the > reconfiguration > that happen in org.apache.servicemix.jbi.logging.LoggingService. > > > On 2/15/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I'm currently working on a DefaultBroker subclass (see > > http://www.nabble.com/Security-and-authorization-requirements-on-Request > > Broker-tf3135938s12049.html) in which I can add handlers processing > > MessageExchange instances within the sendExchangePacket method. > > > > One of them is a log4j-based logger with which I can log MessageExchange > > properties etc. > > > > I did a unit test based on the test cases for the SecuredBroker. After > > some investigations I found out that the call to the default constructor > > of the JBIContainer changes the level of the root logger to ERROR.*) > > > > Is this a desired behaviour, and how can I turn it off? > > > > Thanks in advance, > > Ciao, > > Philipp Rossmanith > > > > *) I observed the same behaviour in the original test case after adding > > a log4j Logger. > > > > This e-mail may contain confidential or privileged information. Any > unauthorised > > copying, use or distribution of this information is strictly prohibited. > > > > > -- > Cheers, > Guillaume Nodet > > Architect, LogicBlaze (http://www.logicblaze.com/) > Blog: http://gnodet.blogspot.com/ This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
Default constructor for JBIContainer changes log level?
Hi, I'm currently working on a DefaultBroker subclass (see http://www.nabble.com/Security-and-authorization-requirements-on-Request Broker-tf3135938s12049.html) in which I can add handlers processing MessageExchange instances within the sendExchangePacket method. One of them is a log4j-based logger with which I can log MessageExchange properties etc. I did a unit test based on the test cases for the SecuredBroker. After some investigations I found out that the call to the default constructor of the JBIContainer changes the level of the root logger to ERROR.*) Is this a desired behaviour, and how can I turn it off? Thanks in advance, Ciao, Philipp Rossmanith *) I observed the same behaviour in the original test case after adding a log4j Logger. This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
Security and authorization requirements on RequestBroker
Dear all, Apologies for the long mail, but there seemed to be no reasonable way of splitting this up. I'm working in a project where we will use ServiceMix (base: v3.0) as a router connecting several Web services (SOAP1.1 with attachments) and for providing commonly needed services, such as user and group management, authentication, authorization, XML-based data persistence, and others. In this project we will develop a number of extensions to/components, which - if there is interest - we might donate to the SM project, as well. Last week I was investigating SM security (for results: see http://goopen.org/confluence/pages/createpage.action?spaceKey=SM&title=S ecurity&linkCreation=true&fromPageId=13484 in the confluence; hasn't been activated yet) My findings suggest the following: - Authorization has to be done at the first endpoint where the normalized message (NM) appears - The SecuredBroker performs allows access based on the belonging of the normalized message's subject's roles. The permissions of the roles are given via the AuthorizationMap. The SecuredBroker DOES NOT check which service provided the original message. In our project, we have a setup where one and the same user may have different permissions depending on which service he's utilizing. Given that my findings are correct and that SM doesn't yet provide this function, I'd like to extend the authorization to include the originating service. (cp. JAAS authorization where a policy defines permissions based on codebase and Principal) Requirements: - *Authentication of calling service*: the consumer service starting a flow of messages (i.e. the one where the NM appears in the ESB) needs to be authenticated. - *Authentication of calling user*, the user using the calling service. Implementation: e.g. user tags in WS-Security. *Every service invocation needs to both authenticate user and service.* - *Client side permission specification* Client services need to be able to change permissions via service invocation. Hence, expanding the AuthorizationMap mechanism doesn't seem feasible. Ideas for implementation/realization: - *In general*: A new Broker as subclass of DefaultBroker/SecuredBroker authorizing based on calling service - *Authentication of calling service*: - For servicemix-http/external consumers: signing SOAP messages. - "ESB-internal" endpoints which are assumed to be trusted: lookup in the Broker's component registry. - Assuming that the NM's Subject refers to user information, the security information about the calling service (e.g. Subject) may be attached via NM's setProperty(...) method. - *Client side permission specification*: - Via group and user administration, or via a service engine replacing/complementing the AuthorizationMap (AuthorizationEntrys as SUs) Questions: 1. Are my assumptions about Security issues correct? (See page: "User's guide -> Security" in the confluence) 2. What do you think about this component? Is the outlined functionality already available in the current implementation? 3. Comments on/Ideas for implementation/realization? 4. My account in confluence seems to be disabled. When I log in, the system recognizes me but tells me: "You are not permitted to perform this operation." Any ideas? Thanks in advance, Ciao, Philipp Rossmanith This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
something wrong with the confluence server?
Hi, When trying to access the Confluence-Wiki for editing pages, I get a: >> HTTP Status 404 - /confluence/pages/createpage.action type Status report message /confluence/pages/createpage.action description The requested resource (/confluence/pages/createpage.action) is not available. << The same goes for editing... Any ideas what's wrong? Ciao, Philipp Rossmanith This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
RE: MessageExchange.getRole(): Role.PROVIDER vs. Role.CONSUMER
Hi, Response between the lines... > > 1.) States of MEs > > == > > A MessageExchange (ME) has an array of possible states (int [][]states), > which differs depending on the type of the ME. It is only being set in the > constructor of MessageExchangeImpl. > > > > When being sent, the method: > > > > > public void handleSend(boolean sync) throws MessagingException > > < > > changes the state depending on the current status/logical state of the > ME by consulting and reassigning the current state. Every row of the array > corresponds to a description of a state with all possible succeeding > states - depending on the value of the ExchangeStatus and whether there is > a Fault a new state is selected. > > The state is also changed in the handleAccept method which is called > when the message > is given to a component using the DeliveryChannel.accept method. Yes, I forgot to mention that one. > > The array of states determines the role of a MessageExchange. A > Role.PROVIDER indicates that an ME is being sent from a consumer to a > provider, whereas a Role.CONSUMER means that the ME goes from the provider > to the consumer. *) > > Note that the role for a given instance of the MessageExchangeImpl class > will > never change. The hack is that the consumer component and the > provider component > will be given two different objects (the mirror property). This is > mainly needed to ensure > that a exchange ownership is enforced (a component can not modify the > exchange > if it is not the owner). This is controlled by the CAN_OWNER flag and > checked at > several locations (setProperty, setMessage, setStatus, etc...) >From the spec: " MessageExchange instances are owned by either the initiator, servicer, or NMR. Creating or accepting a message exchange instance confers ownership on the creating (or accepting) component. Upon calling send() for a particular ME instance, the component surrenders ownership of the ME instance immediately. sendSync() causes ownership to be surrendered during the course of the call; when the call ends (returning true) the component resumes ownership of the ME instance. Ownership of an ME instance gives the owner the right to read from and write to the instance. When a component (or the NMR) doesn't have ownership of an ME instance, it MUST NOT read from or write to the instance, except for reading the message exchange status, which can be queried regardless of ownership. If a component that is not the current owner of the instance does attempt to call any method (other than getStatus()) on the instance an appropriate java.lang.IllegalStateException MUST be thrown." Ok. The CAN_OWNER flags are maintained along with the states; in a given state (which has been changed by accepting or sending an ME), it is or is not enabled, hence allowing or disallowing a component to change the ME. Correct? > > 2.) Duplicity of MessageExchange instances > > === > > What I didn't get is that from "JBI Components: Part 1 (Theory)" I > concluded that all messages related to ONE interaction between a Consumer > and a Provider go through the same MessageExchange > instance/MessageInstanceImpl object. **) > > I don't think this is a requirement. The data should be the same of > course. > Even for a component, the exchange is not always the same: for example > when > the exchange is serialized in the jms / jca flow. Hence, when using > sendSync, a > hack is needed (in the delivery channel) to copy the data from the > received response > to the original object. I see, the one via "exchangesById.put(exchangeKey, me)". > > However, in the code, it seems that the STATES_PROVIDER states are only > assigned to a _new_ instance - while copying the ExchangePacket and > assigning the ME from which it was copied as mirror. > > > > Correct? Why? > > See above. > > 3.) Documenting the above and SM JavaDoc > > = > > Where in the SM pages/documentation would be the best place to > contribute findings/investigations such as the above? Also, which one is > the official SM JavaDoc: http://incubator.apache.org/servicemix/maven/... > or http://servicemix.goopen.org/maven/... or http://XXX/...? > > Maybe somewhere near http://servicemix.org/site/how-stuff-works.html > If you have any idea to improve the organization of the docs, please stand > up > and speak ;-) Sure, can do. Alternatives: - A new "JBI in ServiceMix" page with the same structure as JBI, but describing how SM implements it (- Expanding the corresponding JavaDoc) Please let me know which place you consider the most appropriate, and I'll add our conversation there. On a side note, I like the structure of the Cocoon documentation, where general documentation is divided into a User and Developer part depending on whether you want to only use the framework or want to code (http://cocoon.apache.org/2.1/). > The javadocs for 3.0 release are deployed at > http
MessageExchange.getRole(): Role.PROVIDER vs. Role.CONSUMER
Hi, I tried to find out where the Role of a MessageExchange is being set. I got stuck with the following, and was hoping that someone might help me out with clarifying the issue(s). 1.) States of MEs == A MessageExchange (ME) has an array of possible states (int [][]states), which differs depending on the type of the ME. It is only being set in the constructor of MessageExchangeImpl. When being sent, the method: > public void handleSend(boolean sync) throws MessagingException < changes the state depending on the current status/logical state of the ME by consulting and reassigning the current state. Every row of the array corresponds to a description of a state with all possible succeeding states - depending on the value of the ExchangeStatus and whether there is a Fault a new state is selected. The array of states determines the role of a MessageExchange. A Role.PROVIDER indicates that an ME is being sent from a consumer to a provider, whereas a Role.CONSUMER means that the ME goes from the provider to the consumer. *) Correct? 2.) Duplicity of MessageExchange instances === What I didn't get is that from "JBI Components: Part 1 (Theory)" I concluded that all messages related to ONE interaction between a Consumer and a Provider go through the same MessageExchange instance/MessageInstanceImpl object. **) However, in the code, it seems that the STATES_PROVIDER states are only assigned to a _new_ instance - while copying the ExchangePacket and assigning the ME from which it was copied as mirror. Correct? Why? 3.) Documenting the above and SM JavaDoc = Where in the SM pages/documentation would be the best place to contribute findings/investigations such as the above? Also, which one is the official SM JavaDoc: http://incubator.apache.org/servicemix/maven/... or http://servicemix.goopen.org/maven/... or http://XXX/...? Thanks in advance, Ciao, Philipp Rossmanith *) From DefaultBroker.java: // If we found a destination, or this is a reply if (exchange.getEndpoint() != null || exchange.getRole() == Role.CONSUMER) **) "This serves as a container for the messages and state of a service invocation (i.e., "calling" a particular operation). There are separate MessageExchange subtypes for each supported MEP. New message exchange instances are created using a JBI-provided MessageExchangeFactory." ITC Analyst Systems Integration T-Systems ITC Iberia S.A.U. Edifici 22@ Sancho d'Àvila 110-130 08018 Barcelona Office: + 34 93 501 56 22 Main: + 34 93 501 50 00 Email: [EMAIL PROTECTED] Internet: www.t-systems.com This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
RE: Maven troubles with ServiceMix 3.0 - Follow-up
Not yet :-) I checked "Building", "Documentation", and the main page of servicemix.org, but that link slipped me. I'll try it out... Thanks - you made my day :-) Philipp Rossmanith > -Mensaje original- > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Enviado el: viernes, 19 de enero de 2007 16:33 > Para: servicemix-dev@geronimo.apache.org > Asunto: Re: Maven troubles with ServiceMix 3.0 - Follow-up > > Have you tried following instructions available at > http://servicemix.org/site/importing-servicemix-into-eclipse.html ? > > On 1/19/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I managed to resolve the problem > > > " [INFO] Error building POM (may not be this project's POM). > > > Project ID: null:xfire-all:jar:1.2.1 > > > Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for > > project: > > > null:xfire-all:jar:1.2.1" > > > > ... by proceeding as suggested here: > > http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/20061 > > 0.mbox/[EMAIL PROTECTED], that is, commenting out the > > https-repository in > > .m2\repository\org\codehaus\xfire\xfire-all\1.2.1\xfire-all-1.2.1.pom. > > > > Now, my SM 3.0 Maven build works fine. Still, when opening the project > > in Eclipse, there are 3388 errors, obviously resulting from missing > > dependencies. > > > > I installed the Maven Eclipse plugin from > > http://maven.apache.org/eclipse-plugin.html and added the Maven-managed > > dependencies to the build-path. > > > > This reduces the number of errors to 1166. Still, it gets stuck with > > tranql-1.3.pom, an issue that has been described in > > http://www.mail-archive.com/servicemix-users@geronimo.apache.org/msg0598 > > 0.html > > > > At the moment, I am adding the missing jars manually. However, that's a > > major pain. > > > > Hence, any feedback on how to resolve this issue would be highly > > appreciated. Should this post better be sent to a different mailing > > list, please let me know about it. > > > > Thanks in advance, > > Ciao, > > Philipp Rossmanith > > > > > -Mensaje original- > > > De: Rossmanith, Philipp > > > Enviado el: viernes, 19 de enero de 2007 9:30 > > > Para: servicemix-dev@geronimo.apache.org > > > Asunto: Maven troubles with yesterday's SNAPSHOT > > > > > > > > > Hi, > > > > > > In the project I'm working, we're planning to subclass the > > DefaultBroker > > > in order to enhance its features. Hence, I'll have to do some SM > > > programming and want to make its code available in Eclipse. > > > > > > Knowing from the past that the latest features are usually available > > in > > > the SVN, only, I tried to set up today's snapshot > > > (apache-servicemix-3.1-incubating-20070118.083008-58-src.zip). I had > > > some difficulties with Maven, though. > > > > > > I followed the steps described in > > > http://servicemix.org/site/building.html from within the top-level src > > > directory. I also added M2_REPO to my workspace. MD5 checksums are ok, > > > as well. > > > > > > At first, the build went fine, but when I opened the project, I got an > > > error about my build path and some missing libraries. However, they > > were > > > available in my Maven2 repository. > > > > > > Assuming it might be related to the Maven repository, I deleted it. > > > However, repeating the compilation process, the build yielded an > > error: > > > > > > "Project ID: null:xfire-all:jar:1.2.2 > > > Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for > > > project: null:xfire-all:jar:1.2.2" > > > > > > I tried with both the pom.xml contained within the src directory as > > well > > > as the apache-servicemix-3.1-incubating-20070118.083008-58.pom. > > > > > > I changed to the stable 3.0 version and did the same thing all over > > > again. Now, when executing: > > > > > > > > > Hence my questions: > > > 1. Any idea of what I did wrong > > > 2. Which is the fool-proof way of getting Eclipse-Access to the SM > > > sources > > > 3. Which of the two POMs do I have to use > > > > > > In the meanwhile, I'll be trying to fix the issues by manually > > > downloading and executing the missing poms (and perhaps adding the > > > repositories I find to the top-level pom). > > > > > > Thanks in advance, > > > Ciao, > > > Philipp Rossmanith > > > > This e-mail may contain confidential or privileged information. Any > unauthorised > > copying, use or distribution of this information is strictly prohibited. > > > > > -- > Cheers, > Guillaume Nodet > > Architect, LogicBlaze (http://www.logicblaze.com/) > Blog: http://gnodet.blogspot.com/ This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
Maven troubles with ServiceMix 3.0 - Follow-up
Hi, I managed to resolve the problem > " [INFO] Error building POM (may not be this project's POM). > Project ID: null:xfire-all:jar:1.2.1 > Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for project: > null:xfire-all:jar:1.2.1" ... by proceeding as suggested here: http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/20061 0.mbox/[EMAIL PROTECTED], that is, commenting out the https-repository in .m2\repository\org\codehaus\xfire\xfire-all\1.2.1\xfire-all-1.2.1.pom. Now, my SM 3.0 Maven build works fine. Still, when opening the project in Eclipse, there are 3388 errors, obviously resulting from missing dependencies. I installed the Maven Eclipse plugin from http://maven.apache.org/eclipse-plugin.html and added the Maven-managed dependencies to the build-path. This reduces the number of errors to 1166. Still, it gets stuck with tranql-1.3.pom, an issue that has been described in http://www.mail-archive.com/servicemix-users@geronimo.apache.org/msg0598 0.html At the moment, I am adding the missing jars manually. However, that's a major pain. Hence, any feedback on how to resolve this issue would be highly appreciated. Should this post better be sent to a different mailing list, please let me know about it. Thanks in advance, Ciao, Philipp Rossmanith > -Mensaje original- > De: Rossmanith, Philipp > Enviado el: viernes, 19 de enero de 2007 9:30 > Para: servicemix-dev@geronimo.apache.org > Asunto: Maven troubles with yesterday's SNAPSHOT > > > Hi, > > In the project I'm working, we're planning to subclass the DefaultBroker > in order to enhance its features. Hence, I'll have to do some SM > programming and want to make its code available in Eclipse. > > Knowing from the past that the latest features are usually available in > the SVN, only, I tried to set up today's snapshot > (apache-servicemix-3.1-incubating-20070118.083008-58-src.zip). I had > some difficulties with Maven, though. > > I followed the steps described in > http://servicemix.org/site/building.html from within the top-level src > directory. I also added M2_REPO to my workspace. MD5 checksums are ok, > as well. > > At first, the build went fine, but when I opened the project, I got an > error about my build path and some missing libraries. However, they were > available in my Maven2 repository. > > Assuming it might be related to the Maven repository, I deleted it. > However, repeating the compilation process, the build yielded an error: > > "Project ID: null:xfire-all:jar:1.2.2 > Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for > project: null:xfire-all:jar:1.2.2" > > I tried with both the pom.xml contained within the src directory as well > as the apache-servicemix-3.1-incubating-20070118.083008-58.pom. > > I changed to the stable 3.0 version and did the same thing all over > again. Now, when executing: > > > Hence my questions: > 1. Any idea of what I did wrong > 2. Which is the fool-proof way of getting Eclipse-Access to the SM > sources > 3. Which of the two POMs do I have to use > > In the meanwhile, I'll be trying to fix the issues by manually > downloading and executing the missing poms (and perhaps adding the > repositories I find to the top-level pom). > > Thanks in advance, > Ciao, > Philipp Rossmanith This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
Maven troubles with yesterday's SNAPSHOT
Hi, In the project I'm working, we're planning to subclass the DefaultBroker in order to enhance its features. Hence, I'll have to do some SM programming and want to make its code available in Eclipse. Knowing from the past that the latest features are usually available in the SVN, only, I tried to set up today's snapshot (apache-servicemix-3.1-incubating-20070118.083008-58-src.zip). I had some difficulties with Maven, though. I followed the steps described in http://servicemix.org/site/building.html from within the top-level src directory. I also added M2_REPO to my workspace. MD5 checksums are ok, as well. At first, the build went fine, but when I opened the project, I got an error about my build path and some missing libraries. However, they were available in my Maven2 repository. Assuming it might be related to the Maven repository, I deleted it. However, repeating the compilation process, the build yielded an error: "Project ID: null:xfire-all:jar:1.2.2 Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for project: null:xfire-all:jar:1.2.2" I tried with both the pom.xml contained within the src directory as well as the apache-servicemix-3.1-incubating-20070118.083008-58.pom. I changed to the stable 3.0 version and did the same thing all over again. Now, when executing: " [INFO] Error building POM (may not be this project's POM). Project ID: null:xfire-all:jar:1.2.1 Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for project: null:xfire-all:jar:1.2.1" Hence my questions: 1. Any idea of what I did wrong 2. Which is the fool-proof way of getting Eclipse-Access to the SM sources 3. Which of the two POMs do I have to use In the meanwhile, I'll be trying to fix the issues by manually downloading and executing the missing poms (and perhaps adding the repositories I find to the top-level pom). Thanks in advance, Ciao, Philipp Rossmanith This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
[general question]how do code contributions work
Hi, My name is Philipp Rossmanith and I'm working at T-Systems, Spain. We're currently involved in a research project where we need to implement a system providing functionality that to a large extent already seems to be provided by an ESB. Since a week, I and my team (4 people in total) are exploring which (open-source) ESB to use and to (later on) contribute code to. The last 2 remaining options are ServiceMix and Mule. So far, we have no experience of working in open-source projects. Hence I have a couple of questions regarding work in Apache projects: - In general, would you be interested in contributions on our behalf? - Can anyone raise any issues they like on the JIRA? - How are issues from the JIRA assigned to a developer? What's the procedure for resolving an issue? - How is the code merged into the code base? Thanks in advance, Ciao, Philipp This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited. Este mensaje electrónico puede contener información confidencial o privilegiada, por lo que está completamente prohibida la copia, el uso o la distribución no autorizada de dicha información Aquest missatge electrònic pot contenir informació confidencial o privilegiada i està completament prohibida qualsevol còpia, ús o distribució no autoritzada d'aquesta informació. Mezu honek, enpresaren jabetzapeko edo legalki babestutako isilpeko informazioa izan dezake. Zu ez baldin bazara hartzailea, mesedez bidaltzaileari jakinarazi iezaiozu eta mezua ezabatu, ez ezazu gorde ezta birbidali ere, baimendu gabeko bere erabilera debekatzen da eta.
