[jira] Assigned: (SM-939) CXF based Service Engine and Bnding Component
[ https://issues.apache.org/activemq/browse/SM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SM-939: -- Assignee: Freeman Fang (was: Freeman Fang) CXF based Service Engine and Bnding Component - Key: SM-939 URL: https://issues.apache.org/activemq/browse/SM-939 Project: ServiceMix Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Freeman Fang Priority: Critical Fix For: 3.2 Attachments: patch.txt, patch0627.txt, patch0702.txt, patch0720.txt, patch0806.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ServiceMix 4.0
On 8/24/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/24/07, Adrian Co [EMAIL PROTECTED] wrote: Not sure if this is the right forum to bring this up, but I was wondering if this is a good opportunity to migrate some of servicemix's infra to newer version. i.e. 1. Use slf4j as the logging framework. (http://www.slf4j.org/) - btw, I'm not sure if its a better option, but I did hear some good stuff about it. Yes, SMX should switch to using the slf4j-api which will allow any logging framework to be plugged in at deployment time. how's that different from commons-logging (other than adding yet another dependency, since many things SMX depends on also depends on commons logging) -- James --- http://macstrac.blogspot.com/
[jira] Assigned: (SM-1018) support ws-security
[ https://issues.apache.org/activemq/browse/SM-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned SM-1018: Assignee: Freeman Fang support ws-security --- Key: SM-1018 URL: https://issues.apache.org/activemq/browse/SM-1018 Project: ServiceMix Issue Type: Sub-task Reporter: Freeman Fang Assignee: Freeman Fang should refer to the ws-security implementation in servicemix-soap model -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1035) Continuation problems when Max Idle Time ocurr
[
https://issues.apache.org/activemq/browse/SM-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40009
]
Jorge RodrÃguez Pedrianes commented on SM-1035:
---
Yes this solved my problem.
BTW, at first, i refered to the file ConsumerProcessor (this is used whith
HttpEndpoint, now I use servicemix 3.1 and this new enpoint appear in trunk
version) but I see that in HttpConsumerEndpoint happen the same problem.
Thanks
Continuation problems when Max Idle Time ocurr
--
Key: SM-1035
URL: https://issues.apache.org/activemq/browse/SM-1035
Project: ServiceMix
Issue Type: Bug
Components: servicemix-http
Environment: Servicemix 3.1
Reporter: Jorge RodrÃguez Pedrianes
Fix For: 3.1.2
Original Estimate: 2 minutes
Remaining Estimate: 2 minutes
HI!
I saw in Http binding component, that if my service work too time, the
http endpoint retry the current request. but this it's wrong. I think that in
ConsumerProcessor class it's better to do this:
{code:title=ConsumerProcessor java|borderStyle=solid}
...
public void process(HttpServletRequest request, HttpServletResponse
response) throws Exception {
// If the continuation is not a retry
if (!cont.isPending() cont.isNew()) {
...
}
{code}
Whith this we avoid put the request two times in the bus.
Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
On Aug 25, 2007, at 2:12 AM, Nodet Guillaume wrote: Ok, sounds like we have enough people. So we just need to find a data and an hour. What about Friday 3 pm GMT, 11 am EST, 8 am PST Adrian, I'm not sure how to find a time that would suits you... Other propositions are welcome... +1 Cheers, Guillaume Nodet -- Daryl http://itsallsemantics.com Under capitalism, man exploits man. Under communism, it's just the opposite. -- John Kenneth Galbraith
[jira] Closed: (SM-1042) Build fails in Java 6: Cannot find symbol StandardMBean(Object, Class?)
[
https://issues.apache.org/activemq/browse/SM-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen closed SM-1042.
---
Resolution: Fixed
Fix Version/s: 3.2
Changing Class? back into Class fixes this:
http://svn.apache.org/viewvc?view=revrevision=570136
Build fails in Java 6: Cannot find symbol StandardMBean(Object, Class?)
-
Key: SM-1042
URL: https://issues.apache.org/activemq/browse/SM-1042
Project: ServiceMix
Issue Type: Bug
Components: servicemix-core
Affects Versions: 3.1.1
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Fix For: 3.2
Seems to be a problem that is mentioned in the adoption guide:
http://java.sun.com/javase/6/webnotes/adoption/adoptionguide.html#2.2.1
{noformat}
[INFO] Compilation failure
C:\projects\servicemix\core\servicemix-core\src\main\java\org\apache\servicemix\jbi\management\BaseStandardMBean.java:[117,8]
cannot
find symbol
symbol : constructor
StandardMBean(java.lang.Object,java.lang.Classcapture#863 of ?)
location: class javax.management.StandardMBean
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-1043) Poller sends invalid MessageExchange when file has been deleted
Poller sends invalid MessageExchange when file has been deleted --- Key: SM-1043 URL: https://issues.apache.org/activemq/browse/SM-1043 Project: ServiceMix Issue Type: Bug Components: servicemix-ftp Affects Versions: 3.1.1 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: 3.1.2, 3.2 If a file is deleted from the FTP server while the Poller is processing a directory, the poller stills sends a MessageExchange, resulting in a FileNotFoundException... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ServiceMix 4.0
On 8/27/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/27/07, James Strachan [EMAIL PROTECTED] wrote: 1. Use slf4j as the logging framework. (http://www.slf4j.org/) - btw, I'm not sure if its a better option, but I did hear some good stuff about it. Yes, SMX should switch to using the slf4j-api which will allow any logging framework to be plugged in at deployment time. how's that different from commons-logging (other than adding yet another dependency, since many things SMX depends on also depends on commons logging) There are a lot of reasons, including an extremely good writeup about JCL that Ceki did back in 2004 that is available here: http://www.qos.ch/logging/thinkAgain.jsp But the most important point of all is that the use of JCL is most oftentimes incorrect from an architecture standpoint. At least this is what the creator of JCL says: '...The purpose of Commons Logging is not to somehow take the logging world by storm. In fact, there are very limited circumstances in which Commons Logging is useful. If you're building a stand-alone application, don't use commons-logging. If you're building an application server, don't use commons-logging. If you're building a moderately large framework, don't use commons-logging. If however, like the Jakarta Commons project, you're building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can't be sure what logging framework they're going to want to use, then commons-logging might be useful to you...' See Rod's full blog entry here: http://radio.weblogs.com/0122027/2003/08/15.html Also, moving toward an architecture based on OSGi almost guarantees that we will run into classloader issues with JCL. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/
Re: ServiceMix 4.0
You are correct about OSGi having more control over classloaders, but in the case of JCL things are a little different. Below is a link to the mailing list thread where we went through all of this pain on the Spring-OSGi project and decided to replace JCL with the slf4j facade in order to eliminate the side effects caused by Spring using JCL. I think Spring-OSGi uses slf4j natively now because of this and I believe it has been a consideration for Spring itself to move to it, but I am not sure of the final outcome of that discussion. http://tinyurl.com/3axajc I think the thread was cross posted to Equinox as well and a discussion occured there... Just google commons logging madness :-) As you said about OSGi being flexible, one nice thing about using slf4j in OSGi is that you can have all implementation bundles (slf4j-log4j, slf4j-jdk14, etc.) available in the container, and it is up to each bundle to specify which one it imports, thereby adding it to the classloader wiring. I can't remember if that is built in functionality of slf4j or if it is something that I made work, but it is all done with manifest headers so it is easy to do if its not shipped like that. Good luck! Chris On 8/27/07, Nodet Guillaume [EMAIL PROTECTED] wrote: I would say the opposite. The OSGi classloaders are much more powerful and you can more easily control the visibility of classes. In addition, if JCL is required by a given bundle A, it does not mean that it will be visible by a bundle using bundle A. Obviously, this means to be tested (or maybe OSGi experts could help there...) Cheers, Guillaume Nodet On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote: Also, moving toward an architecture based on OSGi almost guarantees that we will run into classloader issues with JCL. Bruce
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
It's fine. I'll try to join in when I can or just read the logs. :) Nodet Guillaume wrote: Ok, sounds like we have enough people. So we just need to find a data and an hour. What about Friday 3 pm GMT, 11 am EST, 8 am PST Adrian, I'm not sure how to find a time that would suits you... Other propositions are welcome... Cheers, Guillaume Nodet On Aug 24, 2007, at 11:04 AM, Nodet Guillaume wrote: Any other people interested ? Cheers, Guillaume Nodet On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote: I'd be up for a few chat sessions! On 8/23/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Btw, if there is sufficient interest, we could organize irc meetings to discuss these topics and post the log to the dev list for archiving and later discussion. Cheers, Guillaume Nodet On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote: As I explained in the other thread, I've been working on a new API for ServiceMix 4.0. Hopefully this will serve as an input for JBI 2.0. This API is available at https://svn.apache.org/repos/asf/ incubator/servicemix/branches/servicemix-4.0/api So here a few key changes: * clean integration with OSGi * the NormalizedMessage can contain not only XML * no more components * no more JBI packaging (just use OSGi bundles) * move the Channel to the Endpoint * use push delivery instead of pulling exchanges * introduce a single interface for identifying the Target of an Exchange As we remove components, everything goes down to the endpoint which become a key feature. The endpoint must implement the Endpoint interface. In OSGi, the NMR would listen to endpoints registered in the OSGi registry and call the registry to register / unregister the endpoints. As part of the endpoint registration, the NMR would inject a Channel into them, thus actually activating the endpoint. I guess I could write a sequence diagram for that (anybody knows a good tool for uml ?). In a non OSGI environment, the Endpoint will be registered in the Registry by calling the register method somehow. The Endpoint receives Exchange to be processed on the process method. I think we should keep the JBI 1.0 semantics and the endpoint use the same process as for JBI 1.0, which is send the exchange back using the Channel (with the response / fault / error / done). This will put the threading, transactions and security burden on the container itself. Which means it is easier to write JBI apps :-) Exchanges can be created using the Channel#createExchange method. The only change I'd like to integrate in the messaging API is to allow for non xml payloads and maybe untyped attachments. The body could be converted automatically to a given type if supported (I think Camel does it nicely, so I'm thinking of shamelessly copying the converter layer). I have added a few helper methods on the exchanges and messages (copy, copyFrom, ensureReReadable, display) to ease message management. For the deployment part, there is no packaging anymore. One would deploy an OSGi bundle that would register the needed endpoints in the OSGi registry. For certain types of endpoints, we may need an external activation process (such as creating a server socket for listening to HTTP requests) that may need to be shared across endpoints of a given type. In such a case, you would deploy a component that listens to new endpoints implementing HttpEndpoint for example. When a new endpoint is registered, the listener would activate a server socket that could be shared across all http endpoints. In a different way, if we have a BPEL engine, the bpel component would listen for new bundles and look for a specific file containing deployment information. The component would register new endpoints in the OSGi registry as needed (we could do that for jaxws pojos using cxf for example). So I said there is no more components, because this feature is not in the api anymore, but we will certainly need these components for some use cases. For simple endpoints, you would not need any component at all. Another benefit is that you can easily deploy a whole application inside a single OSGi bundle. Using spring-osgi, the bundle would just consist in a spring configuration file containing the endpoints declaration and expose them as OSGi services. Of course, we need to write a JBI 1.0 compatibility layer, and we could have an intermediate layer where SAs and JBI components could be OSGi bundles directly, thus leveraging the OSGi classloading mechanism. The thing I'm not completely sure about if the Target interface which aims to identify the target of an exchange. I'm thinking that some metadata are associated with endpoints (like service name, interface name, wsdl location, etc..). These metadatas could be used to retrieve targets using the Registry. We could plug in different mechanisms to query the metadata (simple lookup per id, policy based, etc...). And the result itself could be not only a single Endpoint, but could include some
