Aritz Galdos Vor 12 Jahren looks great!!!! but wiki link seems to bee broken Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Bruno Farache Aritz Galdos Vor 12 Jahren thanks Aritz, should be fixed now. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Jonas Yuan Bruno Farache Vor 12 Jahren Looks great! Thanks, Bruno. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Bruno Farache Aritz Galdos Vor 12 Jahren thanks Aritz, should be fixed now. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Jonas Yuan Bruno Farache Vor 12 Jahren Looks great! Thanks, Bruno. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Jonas Yuan Bruno Farache Vor 12 Jahren Looks great! Thanks, Bruno. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Amos Fong Vor 12 Jahren Great news! Chatting from a web page is difficult... Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Joshua Asbury Amos Fong Vor 12 Jahren Great job, guys! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Joshua Asbury Amos Fong Vor 12 Jahren Great job, guys! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Sohui Gu Vor 12 Jahren Great job. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Jay Patel Vor 12 Jahren Cool feature Bruno..Thanks for sharing this.. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Gabriel Leon Leyva Vor 12 Jahren will this work for msn messenger?great work thanks !! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Bruno Farache Gabriel Leon Leyva Vor 12 Jahren Gabriel, I don't think MSN messenger can connect to Jabber. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Bruno Farache Gabriel Leon Leyva Vor 12 Jahren Gabriel, I don't think MSN messenger can connect to Jabber. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Paul Hinz Vor 12 Jahren Very nice - continues to show our ability to give you features out of the box while we also plug in to whatever you already have. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva Paul Hinz Vor 12 Jahren Bruno, about msn messenger, I think I didn't express the right idea, as we know any jabber program like spark can comunicate thru the jabber server to the msn protocol. That is the right question will liferay comunicate thru the jabber server to msn protocol? Thanks have a nice day. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Bruno Farache Gabriel Leon Leyva Vor 12 Jahren Got it Gabriel. The chat portlet in Liferay can communicate using the Jabber protocol only. The portlet is a chat client, just like Spark, except that it supports only one protocol, Jabber. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva Bruno Farache Vor 12 Jahren Thanks Bruno. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Gabriel Leon Leyva Paul Hinz Vor 12 Jahren Bruno, about msn messenger, I think I didn't express the right idea, as we know any jabber program like spark can comunicate thru the jabber server to the msn protocol. That is the right question will liferay comunicate thru the jabber server to msn protocol? Thanks have a nice day. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Bruno Farache Gabriel Leon Leyva Vor 12 Jahren Got it Gabriel. The chat portlet in Liferay can communicate using the Jabber protocol only. The portlet is a chat client, just like Spark, except that it supports only one protocol, Jabber. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva Bruno Farache Vor 12 Jahren Thanks Bruno. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Bruno Farache Gabriel Leon Leyva Vor 12 Jahren Got it Gabriel. The chat portlet in Liferay can communicate using the Jabber protocol only. The portlet is a chat client, just like Spark, except that it supports only one protocol, Jabber. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva Bruno Farache Vor 12 Jahren Thanks Bruno. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Gabriel Leon Leyva Bruno Farache Vor 12 Jahren Thanks Bruno. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Dominique Magré Vor 12 Jahren beau travail Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Fuad Efendi Vor 12 Jahren Bruno, are you real LOL ; - )I always thought you are from another planet... Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Bruno Farache Fuad Efendi Vor 12 Jahren haha, thanks for calling me an alien, Fuad. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol Bruno Farache Vor 12 Jahren Thanks for the post!Looking at this it would appear that we could just point "jabber.host" to one of Googles SRV records for xmpp-client for our google apps corporate account, which should permit users in our liferay install with matching emails/passwords to chat within our google apps domain. Correct? Meaning I don't really see anything here preventing that (nothing openfire specific). Correct?Secondly this is still a short polling based system right? Any plans to move to comet/BOSH? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Need to get this running to play with it. So I've got the portal trunk (6.1) and plugins trunk (generated the 6.1 sdk) running and starting up OK in Dev Studio 1.2 on a clean database. The portal is up and running OK via a clean startup. I successfully did a build-service for the chat-portlet in the trunk + deployed it ok. It says available for use, but in the menus on the running 6.1 liferay instance I don't see it showing up to add it to a page? How do I get the chat portlet to show up somewhere? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva az eol Vor 12 Jahren facebook supports jabber Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva Gabriel Leon Leyva Vor 12 Jahren http://developers.facebook.com/docs/chat/ Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol Gabriel Leon Leyva Vor 12 Jahren Hi,We needed to use the latest trunk chat-portlet sooner than later, and as part of that, we had to make some modifications for it to work for us. Below they are described and included in a patch file, and hopefully these changes can be included/supported in the official 6.1 release whenever it comes out.Please note the patch file also includes some service generation code which is not different than the trunk. The primary changes are all in the jabber.* package.In general our use case is that we needed to use it with Google Apps corporate accounts. Our users have corresponding accounts in our google apps corporate account and there are more than one @domainname (sub-domains) under our google apps account so assumptions currently in the trunk about all user's screen names existing within one domain, or screen name reliance only, does not work with Smack -> Google Talk for a corporate account.Overall we are asking that configurable support for the changes we made be rolled into the planned mainline release of the chat-portlet so that we do not have to maintain our own branch of it.-------------------------------------------------------------OVERVIEW OF CHANGES WE MADE-------------------------------------------------------------(#1) Changed JabberImpl's sendMessage() to set the TO (destination user's) jabberId = the user's email address rather than just the screen name. Can an config option be added for this behavior?(i.e.) String jabberId = toUser.getEmailAddress();(#2) Altered JabblerImpl.connect()'s Smack ConnectionConfiguration to set the service name equal to the user's email domain (right side of @) which is what is needed to work with google apps accounts.Can an config option be added for this kind of behavior?ConnectionConfiguration config = getConnectionConfiguration();String serviceName = StringUtil.extractLast(user.getEmailAddress(), StringPool.AT);config.setServiceName(serviceName);connection = new XMPPConnection(config);(#3) Altered the JabberImp.connect()'s smack connection login call to pass email address instead of screen nameCan an config option be added for this kind of behavior? Likely could read from the same config for the above.connection.login(user.getEmailAddress(), password, PortletPropsValues.JABBER_RESOURCE);(#4) Adjusted JabberMessageListener.processMessage() to retrieve the sender user by email address rather than screen name due to screen names being different (potentially) than the email for the user (which must match the jabberid MINUS the /resource). This change also added a new method on the Jabber interface: public String getEmailAddress(String jabberIdWithResource); plus on the implementing classes. Again the use of looking up by email might need to be controlled by a config property.(#5) Adjusted the JabberImpl's getStatuses() method to fetch by email instead of screen name (same reasons as above) as well as catch Exceptions and do a null check in calls to "UserLocalServiceUtil.getUserByEmailAddress()" when a user returned by the XMPP server does not exist in the local liferay install. It seems legitimate that someone might connect this to an XMPP server where users in someone's roster are not in the local Liferay install. This should fail without error, (log/warn maybe) but not cause it to bomb out. Just filter the user from the roster returned. (i.e. _log.warn("XMPP Roster user: " + rosterEntry.getUser() + " not in local Liferay... skipping adding to chat roster..");)(#6) We front our liferay install via an SSO mechanism and have a custom AuthLogin hook implemented. Subsequently the LoginPostAction in com.liferay.chat.hook.events.LoginPostAction has no password available to us for Smack to consume in its login calls. We made a modification in our copy to fetch it via other means as Smack requires it. However it would be nice if the official chat-portlet release had access to the password OR provided another hook that would permit us to get it via another means available in our AuthLogin hook. Is the login.events.post configuration configurable outside of the portlet WAR? If so this may suffice.(#7) We backported this to run in 6.0 EE SP1. To do that we had to modify various timer/delay related JS calls in main.js to use AUI DelayedTask instead of the newer debounce methods. (#8) To work with google talk our portlet.properties ended up looking like thisjabber.enabled=truejabber.import.user.enabled=false jabber.host=talk.l.google.com jabber.port=5222jabber.resource=jabber.service.name=jabber.sock5.proxy.enabled=falsejabber.sock5.proxy.port=-1 Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Couldn't attach patch files, please email me if you need them. Thanks Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Bruno Farache Fuad Efendi Vor 12 Jahren haha, thanks for calling me an alien, Fuad. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol Bruno Farache Vor 12 Jahren Thanks for the post!Looking at this it would appear that we could just point "jabber.host" to one of Googles SRV records for xmpp-client for our google apps corporate account, which should permit users in our liferay install with matching emails/passwords to chat within our google apps domain. Correct? Meaning I don't really see anything here preventing that (nothing openfire specific). Correct?Secondly this is still a short polling based system right? Any plans to move to comet/BOSH? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Need to get this running to play with it. So I've got the portal trunk (6.1) and plugins trunk (generated the 6.1 sdk) running and starting up OK in Dev Studio 1.2 on a clean database. The portal is up and running OK via a clean startup. I successfully did a build-service for the chat-portlet in the trunk + deployed it ok. It says available for use, but in the menus on the running 6.1 liferay instance I don't see it showing up to add it to a page? How do I get the chat portlet to show up somewhere? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva az eol Vor 12 Jahren facebook supports jabber Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva Gabriel Leon Leyva Vor 12 Jahren http://developers.facebook.com/docs/chat/ Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol Gabriel Leon Leyva Vor 12 Jahren Hi,We needed to use the latest trunk chat-portlet sooner than later, and as part of that, we had to make some modifications for it to work for us. Below they are described and included in a patch file, and hopefully these changes can be included/supported in the official 6.1 release whenever it comes out.Please note the patch file also includes some service generation code which is not different than the trunk. The primary changes are all in the jabber.* package.In general our use case is that we needed to use it with Google Apps corporate accounts. Our users have corresponding accounts in our google apps corporate account and there are more than one @domainname (sub-domains) under our google apps account so assumptions currently in the trunk about all user's screen names existing within one domain, or screen name reliance only, does not work with Smack -> Google Talk for a corporate account.Overall we are asking that configurable support for the changes we made be rolled into the planned mainline release of the chat-portlet so that we do not have to maintain our own branch of it.-------------------------------------------------------------OVERVIEW OF CHANGES WE MADE-------------------------------------------------------------(#1) Changed JabberImpl's sendMessage() to set the TO (destination user's) jabberId = the user's email address rather than just the screen name. Can an config option be added for this behavior?(i.e.) String jabberId = toUser.getEmailAddress();(#2) Altered JabblerImpl.connect()'s Smack ConnectionConfiguration to set the service name equal to the user's email domain (right side of @) which is what is needed to work with google apps accounts.Can an config option be added for this kind of behavior?ConnectionConfiguration config = getConnectionConfiguration();String serviceName = StringUtil.extractLast(user.getEmailAddress(), StringPool.AT);config.setServiceName(serviceName);connection = new XMPPConnection(config);(#3) Altered the JabberImp.connect()'s smack connection login call to pass email address instead of screen nameCan an config option be added for this kind of behavior? Likely could read from the same config for the above.connection.login(user.getEmailAddress(), password, PortletPropsValues.JABBER_RESOURCE);(#4) Adjusted JabberMessageListener.processMessage() to retrieve the sender user by email address rather than screen name due to screen names being different (potentially) than the email for the user (which must match the jabberid MINUS the /resource). This change also added a new method on the Jabber interface: public String getEmailAddress(String jabberIdWithResource); plus on the implementing classes. Again the use of looking up by email might need to be controlled by a config property.(#5) Adjusted the JabberImpl's getStatuses() method to fetch by email instead of screen name (same reasons as above) as well as catch Exceptions and do a null check in calls to "UserLocalServiceUtil.getUserByEmailAddress()" when a user returned by the XMPP server does not exist in the local liferay install. It seems legitimate that someone might connect this to an XMPP server where users in someone's roster are not in the local Liferay install. This should fail without error, (log/warn maybe) but not cause it to bomb out. Just filter the user from the roster returned. (i.e. _log.warn("XMPP Roster user: " + rosterEntry.getUser() + " not in local Liferay... skipping adding to chat roster..");)(#6) We front our liferay install via an SSO mechanism and have a custom AuthLogin hook implemented. Subsequently the LoginPostAction in com.liferay.chat.hook.events.LoginPostAction has no password available to us for Smack to consume in its login calls. We made a modification in our copy to fetch it via other means as Smack requires it. However it would be nice if the official chat-portlet release had access to the password OR provided another hook that would permit us to get it via another means available in our AuthLogin hook. Is the login.events.post configuration configurable outside of the portlet WAR? If so this may suffice.(#7) We backported this to run in 6.0 EE SP1. To do that we had to modify various timer/delay related JS calls in main.js to use AUI DelayedTask instead of the newer debounce methods. (#8) To work with google talk our portlet.properties ended up looking like thisjabber.enabled=truejabber.import.user.enabled=false jabber.host=talk.l.google.com jabber.port=5222jabber.resource=jabber.service.name=jabber.sock5.proxy.enabled=falsejabber.sock5.proxy.port=-1 Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Couldn't attach patch files, please email me if you need them. Thanks Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
az eol Bruno Farache Vor 12 Jahren Thanks for the post!Looking at this it would appear that we could just point "jabber.host" to one of Googles SRV records for xmpp-client for our google apps corporate account, which should permit users in our liferay install with matching emails/passwords to chat within our google apps domain. Correct? Meaning I don't really see anything here preventing that (nothing openfire specific). Correct?Secondly this is still a short polling based system right? Any plans to move to comet/BOSH? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Need to get this running to play with it. So I've got the portal trunk (6.1) and plugins trunk (generated the 6.1 sdk) running and starting up OK in Dev Studio 1.2 on a clean database. The portal is up and running OK via a clean startup. I successfully did a build-service for the chat-portlet in the trunk + deployed it ok. It says available for use, but in the menus on the running 6.1 liferay instance I don't see it showing up to add it to a page? How do I get the chat portlet to show up somewhere? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva az eol Vor 12 Jahren facebook supports jabber Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva Gabriel Leon Leyva Vor 12 Jahren http://developers.facebook.com/docs/chat/ Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol Gabriel Leon Leyva Vor 12 Jahren Hi,We needed to use the latest trunk chat-portlet sooner than later, and as part of that, we had to make some modifications for it to work for us. Below they are described and included in a patch file, and hopefully these changes can be included/supported in the official 6.1 release whenever it comes out.Please note the patch file also includes some service generation code which is not different than the trunk. The primary changes are all in the jabber.* package.In general our use case is that we needed to use it with Google Apps corporate accounts. Our users have corresponding accounts in our google apps corporate account and there are more than one @domainname (sub-domains) under our google apps account so assumptions currently in the trunk about all user's screen names existing within one domain, or screen name reliance only, does not work with Smack -> Google Talk for a corporate account.Overall we are asking that configurable support for the changes we made be rolled into the planned mainline release of the chat-portlet so that we do not have to maintain our own branch of it.-------------------------------------------------------------OVERVIEW OF CHANGES WE MADE-------------------------------------------------------------(#1) Changed JabberImpl's sendMessage() to set the TO (destination user's) jabberId = the user's email address rather than just the screen name. Can an config option be added for this behavior?(i.e.) String jabberId = toUser.getEmailAddress();(#2) Altered JabblerImpl.connect()'s Smack ConnectionConfiguration to set the service name equal to the user's email domain (right side of @) which is what is needed to work with google apps accounts.Can an config option be added for this kind of behavior?ConnectionConfiguration config = getConnectionConfiguration();String serviceName = StringUtil.extractLast(user.getEmailAddress(), StringPool.AT);config.setServiceName(serviceName);connection = new XMPPConnection(config);(#3) Altered the JabberImp.connect()'s smack connection login call to pass email address instead of screen nameCan an config option be added for this kind of behavior? Likely could read from the same config for the above.connection.login(user.getEmailAddress(), password, PortletPropsValues.JABBER_RESOURCE);(#4) Adjusted JabberMessageListener.processMessage() to retrieve the sender user by email address rather than screen name due to screen names being different (potentially) than the email for the user (which must match the jabberid MINUS the /resource). This change also added a new method on the Jabber interface: public String getEmailAddress(String jabberIdWithResource); plus on the implementing classes. Again the use of looking up by email might need to be controlled by a config property.(#5) Adjusted the JabberImpl's getStatuses() method to fetch by email instead of screen name (same reasons as above) as well as catch Exceptions and do a null check in calls to "UserLocalServiceUtil.getUserByEmailAddress()" when a user returned by the XMPP server does not exist in the local liferay install. It seems legitimate that someone might connect this to an XMPP server where users in someone's roster are not in the local Liferay install. This should fail without error, (log/warn maybe) but not cause it to bomb out. Just filter the user from the roster returned. (i.e. _log.warn("XMPP Roster user: " + rosterEntry.getUser() + " not in local Liferay... skipping adding to chat roster..");)(#6) We front our liferay install via an SSO mechanism and have a custom AuthLogin hook implemented. Subsequently the LoginPostAction in com.liferay.chat.hook.events.LoginPostAction has no password available to us for Smack to consume in its login calls. We made a modification in our copy to fetch it via other means as Smack requires it. However it would be nice if the official chat-portlet release had access to the password OR provided another hook that would permit us to get it via another means available in our AuthLogin hook. Is the login.events.post configuration configurable outside of the portlet WAR? If so this may suffice.(#7) We backported this to run in 6.0 EE SP1. To do that we had to modify various timer/delay related JS calls in main.js to use AUI DelayedTask instead of the newer debounce methods. (#8) To work with google talk our portlet.properties ended up looking like thisjabber.enabled=truejabber.import.user.enabled=false jabber.host=talk.l.google.com jabber.port=5222jabber.resource=jabber.service.name=jabber.sock5.proxy.enabled=falsejabber.sock5.proxy.port=-1 Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Couldn't attach patch files, please email me if you need them. Thanks Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
az eol az eol Vor 12 Jahren Need to get this running to play with it. So I've got the portal trunk (6.1) and plugins trunk (generated the 6.1 sdk) running and starting up OK in Dev Studio 1.2 on a clean database. The portal is up and running OK via a clean startup. I successfully did a build-service for the chat-portlet in the trunk + deployed it ok. It says available for use, but in the menus on the running 6.1 liferay instance I don't see it showing up to add it to a page? How do I get the chat portlet to show up somewhere? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva az eol Vor 12 Jahren facebook supports jabber Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva Gabriel Leon Leyva Vor 12 Jahren http://developers.facebook.com/docs/chat/ Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol Gabriel Leon Leyva Vor 12 Jahren Hi,We needed to use the latest trunk chat-portlet sooner than later, and as part of that, we had to make some modifications for it to work for us. Below they are described and included in a patch file, and hopefully these changes can be included/supported in the official 6.1 release whenever it comes out.Please note the patch file also includes some service generation code which is not different than the trunk. The primary changes are all in the jabber.* package.In general our use case is that we needed to use it with Google Apps corporate accounts. Our users have corresponding accounts in our google apps corporate account and there are more than one @domainname (sub-domains) under our google apps account so assumptions currently in the trunk about all user's screen names existing within one domain, or screen name reliance only, does not work with Smack -> Google Talk for a corporate account.Overall we are asking that configurable support for the changes we made be rolled into the planned mainline release of the chat-portlet so that we do not have to maintain our own branch of it.-------------------------------------------------------------OVERVIEW OF CHANGES WE MADE-------------------------------------------------------------(#1) Changed JabberImpl's sendMessage() to set the TO (destination user's) jabberId = the user's email address rather than just the screen name. Can an config option be added for this behavior?(i.e.) String jabberId = toUser.getEmailAddress();(#2) Altered JabblerImpl.connect()'s Smack ConnectionConfiguration to set the service name equal to the user's email domain (right side of @) which is what is needed to work with google apps accounts.Can an config option be added for this kind of behavior?ConnectionConfiguration config = getConnectionConfiguration();String serviceName = StringUtil.extractLast(user.getEmailAddress(), StringPool.AT);config.setServiceName(serviceName);connection = new XMPPConnection(config);(#3) Altered the JabberImp.connect()'s smack connection login call to pass email address instead of screen nameCan an config option be added for this kind of behavior? Likely could read from the same config for the above.connection.login(user.getEmailAddress(), password, PortletPropsValues.JABBER_RESOURCE);(#4) Adjusted JabberMessageListener.processMessage() to retrieve the sender user by email address rather than screen name due to screen names being different (potentially) than the email for the user (which must match the jabberid MINUS the /resource). This change also added a new method on the Jabber interface: public String getEmailAddress(String jabberIdWithResource); plus on the implementing classes. Again the use of looking up by email might need to be controlled by a config property.(#5) Adjusted the JabberImpl's getStatuses() method to fetch by email instead of screen name (same reasons as above) as well as catch Exceptions and do a null check in calls to "UserLocalServiceUtil.getUserByEmailAddress()" when a user returned by the XMPP server does not exist in the local liferay install. It seems legitimate that someone might connect this to an XMPP server where users in someone's roster are not in the local Liferay install. This should fail without error, (log/warn maybe) but not cause it to bomb out. Just filter the user from the roster returned. (i.e. _log.warn("XMPP Roster user: " + rosterEntry.getUser() + " not in local Liferay... skipping adding to chat roster..");)(#6) We front our liferay install via an SSO mechanism and have a custom AuthLogin hook implemented. Subsequently the LoginPostAction in com.liferay.chat.hook.events.LoginPostAction has no password available to us for Smack to consume in its login calls. We made a modification in our copy to fetch it via other means as Smack requires it. However it would be nice if the official chat-portlet release had access to the password OR provided another hook that would permit us to get it via another means available in our AuthLogin hook. Is the login.events.post configuration configurable outside of the portlet WAR? If so this may suffice.(#7) We backported this to run in 6.0 EE SP1. To do that we had to modify various timer/delay related JS calls in main.js to use AUI DelayedTask instead of the newer debounce methods. (#8) To work with google talk our portlet.properties ended up looking like thisjabber.enabled=truejabber.import.user.enabled=false jabber.host=talk.l.google.com jabber.port=5222jabber.resource=jabber.service.name=jabber.sock5.proxy.enabled=falsejabber.sock5.proxy.port=-1 Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Couldn't attach patch files, please email me if you need them. Thanks Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Gabriel Leon Leyva az eol Vor 12 Jahren facebook supports jabber Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Gabriel Leon Leyva Gabriel Leon Leyva Vor 12 Jahren http://developers.facebook.com/docs/chat/ Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol Gabriel Leon Leyva Vor 12 Jahren Hi,We needed to use the latest trunk chat-portlet sooner than later, and as part of that, we had to make some modifications for it to work for us. Below they are described and included in a patch file, and hopefully these changes can be included/supported in the official 6.1 release whenever it comes out.Please note the patch file also includes some service generation code which is not different than the trunk. The primary changes are all in the jabber.* package.In general our use case is that we needed to use it with Google Apps corporate accounts. Our users have corresponding accounts in our google apps corporate account and there are more than one @domainname (sub-domains) under our google apps account so assumptions currently in the trunk about all user's screen names existing within one domain, or screen name reliance only, does not work with Smack -> Google Talk for a corporate account.Overall we are asking that configurable support for the changes we made be rolled into the planned mainline release of the chat-portlet so that we do not have to maintain our own branch of it.-------------------------------------------------------------OVERVIEW OF CHANGES WE MADE-------------------------------------------------------------(#1) Changed JabberImpl's sendMessage() to set the TO (destination user's) jabberId = the user's email address rather than just the screen name. Can an config option be added for this behavior?(i.e.) String jabberId = toUser.getEmailAddress();(#2) Altered JabblerImpl.connect()'s Smack ConnectionConfiguration to set the service name equal to the user's email domain (right side of @) which is what is needed to work with google apps accounts.Can an config option be added for this kind of behavior?ConnectionConfiguration config = getConnectionConfiguration();String serviceName = StringUtil.extractLast(user.getEmailAddress(), StringPool.AT);config.setServiceName(serviceName);connection = new XMPPConnection(config);(#3) Altered the JabberImp.connect()'s smack connection login call to pass email address instead of screen nameCan an config option be added for this kind of behavior? Likely could read from the same config for the above.connection.login(user.getEmailAddress(), password, PortletPropsValues.JABBER_RESOURCE);(#4) Adjusted JabberMessageListener.processMessage() to retrieve the sender user by email address rather than screen name due to screen names being different (potentially) than the email for the user (which must match the jabberid MINUS the /resource). This change also added a new method on the Jabber interface: public String getEmailAddress(String jabberIdWithResource); plus on the implementing classes. Again the use of looking up by email might need to be controlled by a config property.(#5) Adjusted the JabberImpl's getStatuses() method to fetch by email instead of screen name (same reasons as above) as well as catch Exceptions and do a null check in calls to "UserLocalServiceUtil.getUserByEmailAddress()" when a user returned by the XMPP server does not exist in the local liferay install. It seems legitimate that someone might connect this to an XMPP server where users in someone's roster are not in the local Liferay install. This should fail without error, (log/warn maybe) but not cause it to bomb out. Just filter the user from the roster returned. (i.e. _log.warn("XMPP Roster user: " + rosterEntry.getUser() + " not in local Liferay... skipping adding to chat roster..");)(#6) We front our liferay install via an SSO mechanism and have a custom AuthLogin hook implemented. Subsequently the LoginPostAction in com.liferay.chat.hook.events.LoginPostAction has no password available to us for Smack to consume in its login calls. We made a modification in our copy to fetch it via other means as Smack requires it. However it would be nice if the official chat-portlet release had access to the password OR provided another hook that would permit us to get it via another means available in our AuthLogin hook. Is the login.events.post configuration configurable outside of the portlet WAR? If so this may suffice.(#7) We backported this to run in 6.0 EE SP1. To do that we had to modify various timer/delay related JS calls in main.js to use AUI DelayedTask instead of the newer debounce methods. (#8) To work with google talk our portlet.properties ended up looking like thisjabber.enabled=truejabber.import.user.enabled=false jabber.host=talk.l.google.com jabber.port=5222jabber.resource=jabber.service.name=jabber.sock5.proxy.enabled=falsejabber.sock5.proxy.port=-1 Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Couldn't attach patch files, please email me if you need them. Thanks Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Gabriel Leon Leyva Gabriel Leon Leyva Vor 12 Jahren http://developers.facebook.com/docs/chat/ Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol Gabriel Leon Leyva Vor 12 Jahren Hi,We needed to use the latest trunk chat-portlet sooner than later, and as part of that, we had to make some modifications for it to work for us. Below they are described and included in a patch file, and hopefully these changes can be included/supported in the official 6.1 release whenever it comes out.Please note the patch file also includes some service generation code which is not different than the trunk. The primary changes are all in the jabber.* package.In general our use case is that we needed to use it with Google Apps corporate accounts. Our users have corresponding accounts in our google apps corporate account and there are more than one @domainname (sub-domains) under our google apps account so assumptions currently in the trunk about all user's screen names existing within one domain, or screen name reliance only, does not work with Smack -> Google Talk for a corporate account.Overall we are asking that configurable support for the changes we made be rolled into the planned mainline release of the chat-portlet so that we do not have to maintain our own branch of it.-------------------------------------------------------------OVERVIEW OF CHANGES WE MADE-------------------------------------------------------------(#1) Changed JabberImpl's sendMessage() to set the TO (destination user's) jabberId = the user's email address rather than just the screen name. Can an config option be added for this behavior?(i.e.) String jabberId = toUser.getEmailAddress();(#2) Altered JabblerImpl.connect()'s Smack ConnectionConfiguration to set the service name equal to the user's email domain (right side of @) which is what is needed to work with google apps accounts.Can an config option be added for this kind of behavior?ConnectionConfiguration config = getConnectionConfiguration();String serviceName = StringUtil.extractLast(user.getEmailAddress(), StringPool.AT);config.setServiceName(serviceName);connection = new XMPPConnection(config);(#3) Altered the JabberImp.connect()'s smack connection login call to pass email address instead of screen nameCan an config option be added for this kind of behavior? Likely could read from the same config for the above.connection.login(user.getEmailAddress(), password, PortletPropsValues.JABBER_RESOURCE);(#4) Adjusted JabberMessageListener.processMessage() to retrieve the sender user by email address rather than screen name due to screen names being different (potentially) than the email for the user (which must match the jabberid MINUS the /resource). This change also added a new method on the Jabber interface: public String getEmailAddress(String jabberIdWithResource); plus on the implementing classes. Again the use of looking up by email might need to be controlled by a config property.(#5) Adjusted the JabberImpl's getStatuses() method to fetch by email instead of screen name (same reasons as above) as well as catch Exceptions and do a null check in calls to "UserLocalServiceUtil.getUserByEmailAddress()" when a user returned by the XMPP server does not exist in the local liferay install. It seems legitimate that someone might connect this to an XMPP server where users in someone's roster are not in the local Liferay install. This should fail without error, (log/warn maybe) but not cause it to bomb out. Just filter the user from the roster returned. (i.e. _log.warn("XMPP Roster user: " + rosterEntry.getUser() + " not in local Liferay... skipping adding to chat roster..");)(#6) We front our liferay install via an SSO mechanism and have a custom AuthLogin hook implemented. Subsequently the LoginPostAction in com.liferay.chat.hook.events.LoginPostAction has no password available to us for Smack to consume in its login calls. We made a modification in our copy to fetch it via other means as Smack requires it. However it would be nice if the official chat-portlet release had access to the password OR provided another hook that would permit us to get it via another means available in our AuthLogin hook. Is the login.events.post configuration configurable outside of the portlet WAR? If so this may suffice.(#7) We backported this to run in 6.0 EE SP1. To do that we had to modify various timer/delay related JS calls in main.js to use AUI DelayedTask instead of the newer debounce methods. (#8) To work with google talk our portlet.properties ended up looking like thisjabber.enabled=truejabber.import.user.enabled=false jabber.host=talk.l.google.com jabber.port=5222jabber.resource=jabber.service.name=jabber.sock5.proxy.enabled=falsejabber.sock5.proxy.port=-1 Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Couldn't attach patch files, please email me if you need them. Thanks Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
az eol Gabriel Leon Leyva Vor 12 Jahren Hi,We needed to use the latest trunk chat-portlet sooner than later, and as part of that, we had to make some modifications for it to work for us. Below they are described and included in a patch file, and hopefully these changes can be included/supported in the official 6.1 release whenever it comes out.Please note the patch file also includes some service generation code which is not different than the trunk. The primary changes are all in the jabber.* package.In general our use case is that we needed to use it with Google Apps corporate accounts. Our users have corresponding accounts in our google apps corporate account and there are more than one @domainname (sub-domains) under our google apps account so assumptions currently in the trunk about all user's screen names existing within one domain, or screen name reliance only, does not work with Smack -> Google Talk for a corporate account.Overall we are asking that configurable support for the changes we made be rolled into the planned mainline release of the chat-portlet so that we do not have to maintain our own branch of it.-------------------------------------------------------------OVERVIEW OF CHANGES WE MADE-------------------------------------------------------------(#1) Changed JabberImpl's sendMessage() to set the TO (destination user's) jabberId = the user's email address rather than just the screen name. Can an config option be added for this behavior?(i.e.) String jabberId = toUser.getEmailAddress();(#2) Altered JabblerImpl.connect()'s Smack ConnectionConfiguration to set the service name equal to the user's email domain (right side of @) which is what is needed to work with google apps accounts.Can an config option be added for this kind of behavior?ConnectionConfiguration config = getConnectionConfiguration();String serviceName = StringUtil.extractLast(user.getEmailAddress(), StringPool.AT);config.setServiceName(serviceName);connection = new XMPPConnection(config);(#3) Altered the JabberImp.connect()'s smack connection login call to pass email address instead of screen nameCan an config option be added for this kind of behavior? Likely could read from the same config for the above.connection.login(user.getEmailAddress(), password, PortletPropsValues.JABBER_RESOURCE);(#4) Adjusted JabberMessageListener.processMessage() to retrieve the sender user by email address rather than screen name due to screen names being different (potentially) than the email for the user (which must match the jabberid MINUS the /resource). This change also added a new method on the Jabber interface: public String getEmailAddress(String jabberIdWithResource); plus on the implementing classes. Again the use of looking up by email might need to be controlled by a config property.(#5) Adjusted the JabberImpl's getStatuses() method to fetch by email instead of screen name (same reasons as above) as well as catch Exceptions and do a null check in calls to "UserLocalServiceUtil.getUserByEmailAddress()" when a user returned by the XMPP server does not exist in the local liferay install. It seems legitimate that someone might connect this to an XMPP server where users in someone's roster are not in the local Liferay install. This should fail without error, (log/warn maybe) but not cause it to bomb out. Just filter the user from the roster returned. (i.e. _log.warn("XMPP Roster user: " + rosterEntry.getUser() + " not in local Liferay... skipping adding to chat roster..");)(#6) We front our liferay install via an SSO mechanism and have a custom AuthLogin hook implemented. Subsequently the LoginPostAction in com.liferay.chat.hook.events.LoginPostAction has no password available to us for Smack to consume in its login calls. We made a modification in our copy to fetch it via other means as Smack requires it. However it would be nice if the official chat-portlet release had access to the password OR provided another hook that would permit us to get it via another means available in our AuthLogin hook. Is the login.events.post configuration configurable outside of the portlet WAR? If so this may suffice.(#7) We backported this to run in 6.0 EE SP1. To do that we had to modify various timer/delay related JS calls in main.js to use AUI DelayedTask instead of the newer debounce methods. (#8) To work with google talk our portlet.properties ended up looking like thisjabber.enabled=truejabber.import.user.enabled=false jabber.host=talk.l.google.com jabber.port=5222jabber.resource=jabber.service.name=jabber.sock5.proxy.enabled=falsejabber.sock5.proxy.port=-1 Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen az eol az eol Vor 12 Jahren Couldn't attach patch files, please email me if you need them. Thanks Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
az eol az eol Vor 12 Jahren Couldn't attach patch files, please email me if you need them. Thanks Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Expedito Júnior Vor 12 Jahren Hi, Bruno! Great Work!I work at Câmara dos Deputados in Brazil and we are working hard on Liferay to get it working as soon! We are using spark (openfire server connected with MS Active Directory) as our instant messenger app. So we are trying to use chat-portlet to connect to our openfire server but having no success. Do you know if its possible to do this with Liferay 6.0.6?? If no, and using this trunk?Thank you! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Bruno Farache Expedito Júnior Vor 12 Jahren Oi Expedito! Essa integração foi incluída na Community Edition 6.1, que ainda não foi lançada. A versão Enterprise 6.0 já possui ela, no entanto. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Bruno Farache Expedito Júnior Vor 12 Jahren Oi Expedito! Essa integração foi incluída na Community Edition 6.1, que ainda não foi lançada. A versão Enterprise 6.0 já possui ela, no entanto. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Ken Sperow Vor 12 Jahren Looks good. Will the chat portlet support chat rooms or would users have to use desktop clients? I work for the National Weather Service in the US and we have a jabber server already running call NWSChat that we should be able to tie into, but we need the ability to have multi-user chats. Thanks! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen ken ken Ken Sperow Vor 12 Jahren do we have a version that runs on 6.0.6? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
ken ken Ken Sperow Vor 12 Jahren do we have a version that runs on 6.0.6? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Carlos Hernandez Vor 6 Jahren Does this work in DXP? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen