search

igniterealtime / Fastpath-webchat

Fastpath Web Chat Component
Apache License 2.0
40 stars 31 forks source link

Build Fastpath Webchat without Openfire #8

Closed bdetweiler closed 8 years ago

bdetweiler commented 8 years ago

Greetings! My employer tasked me with implementing a webchat solution while staying within the bounds of our secure architecture. Fastpath ended up being the perfect solution to that because I can deploy it as a WAR and it will act as a kind of reverse proxy to Openfire. The catch was, to make this work within our change management system, I needed it to build without Openfire. So I've included the necessary JARs and an alternative build file (build-no-of.xml) that will allow Fastpath to build independently of Openfire.

I have more enhancements to make down the road, so I would appreciate feedback - positive or negative. Thanks!

akrherz commented 8 years ago

@bdetweiler Sorry that you got no response from us. We really don't have anybody working on Fastpath. So do you have interest in leading it's development? :)

bdetweiler commented 8 years ago

@akrherz That was my original intent, as I thought I might be working on this for a while, but as with all things corporate, I was moved to another project so I probably won't have time for it. It's a really great project that doesn't get enough love. There's really nothing like it out there. The other options are all paid third-party services and this fit my requirements perfectly. Anyway, thanks for the reply, and keep up the good work on the other Ignite Realitime projects!

guusdk commented 8 years ago

Although I value the contribution, I'm not sure if swapping the build dependency with Openfire for an inclusion of the build artifiact (this PR includes openfire.jar) is an improvement. We would need to update that new dependency continuously, which I dislike. I'd love for a problem like this to be tackled by the ongoing (yet stallled) Mavenization of Openfire.

This PR seems to be a project management workaround, driven primarily by the limitations of your integration environment. I can see how it would be of value to you, but I'm wondering if it would be beneficial for the rest of us - it appears to be fairly specific to your setup.

bdetweiler commented 8 years ago

@guusdk I agree that Mavenization is definitely the way to go, and it was going to be my next step until I was moved to a new project. Had it already been Maven project, I wouldn't have needed this workaround. Feel free to reject this. You can point people to my fork if they find themselves in the same situation in the mean time.