Based on my own doubts and Ingo's feedback I've decided to not base
OperationSetBasicInstantMessagingTransport on
OperationSetBasicInstantMessaging. Even though it doesn't make much
sense to implement BasicInstantMessagingTransport and not
BasicInstantMessaging. In theory we could at least query the
characteristics if not actually use the protocol, so I've decided to
extend OperationSet directly.
for querying protocol implementation for operational boundaries.
* Defined the Operation Set for querying transport operation.
* Also implemented the Operation Set in IRC protocol support.
* OTR plugin has been modified to take advantage of the newly defined
Operation Set and queries the protocol for input on building
fragmentation instructions. In case the protocol does not implement the
Operation Set, then it will fall back to OTR defaults.
Modifications include the following:
- Updated otr4j which includes support for fragmentation of outgoing
messages. The modifications to otr4j to enable outgoing message
fragmentation includes breaking the API such that we are able to
return more than 1 message after it has been transformed.
(Corresponding modifications have been made to
AbstractOperationSetBasicInstantMessaging to facilitate the new API.)
- Fixed IRC implementation for OperationSetInstantMessageTransform.
- Modified AbstractOperationSetBasicInstantMessaging to handle multiple
Events returning from a call to messageTransform.
- Modified OperationSetBasicInstantMessaging implementations to
correspond to changes in AbstractOSBIM.
- OTR plugin has been modified to implement the newly added
getFragmenterInstructions method which is used to query instructions
on desired fragmentation behaviour.
- As a temporary solution, a hard dependency has been added to IRC
library such that I'm able to test fragmentation behaviour in a real
use case until an OperationSet is defined that can be used to query
for Instant Messaging transport parameters necessary to determine
appropriate fragmentation instructions.
A NPE occurred occasionally when selecting an (arbitrary?) account for
which there was a presence popup menu is available. These popup menus
can be found within the global status popup menu for each of the
available (enabled) accounts.
The cause of the exception turned out to be the titleArea which holds
the account name and optional status message. I'm not sure what exactly
causes the NPE itself, but it might have to do with the size of the edit
pane and size of the content vs. the size of the menu.
The stack trace that would occur if on occasion this NPE would occur:
23:23:10.642 SEVERE: [35] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
java.lang.NullPointerException
at javax.swing.BoxLayout.checkRequests(BoxLayout.java:485)
at javax.swing.BoxLayout.preferredLayoutSize(BoxLayout.java:300)
at javax.swing.plaf.basic.DefaultMenuLayout.preferredLayoutSize(DefaultMenuLayout.java:60)
at java.awt.Container.preferredSize(Container.java:1788)
at java.awt.Container.getPreferredSize(Container.java:1773)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1653)
at java.awt.BorderLayout.preferredLayoutSize(BorderLayout.java:719)
at java.awt.Container.preferredSize(Container.java:1788)
at java.awt.Container.getPreferredSize(Container.java:1773)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1653)
at javax.swing.JRootPane$RootLayout.preferredLayoutSize(JRootPane.java:917)
at java.awt.Container.preferredSize(Container.java:1788)
at java.awt.Container.getPreferredSize(Container.java:1773)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1653)
at java.awt.BorderLayout.preferredLayoutSize(BorderLayout.java:719)
at java.awt.Container.preferredSize(Container.java:1788)
at java.awt.Container.getPreferredSize(Container.java:1773)
at java.awt.Window.pack(Window.java:809)
at javax.swing.Popup$HeavyWeightWindow.show(Popup.java:252)
at javax.swing.Popup.show(Popup.java:105)
at javax.swing.JPopupMenu.getPopup(JPopupMenu.java:834)
at javax.swing.JPopupMenu.setVisible(JPopupMenu.java:783)
at javax.swing.JPopupMenu.show(JPopupMenu.java:953)
at javax.swing.JMenu.setPopupMenuVisible(JMenu.java:351)
at javax.swing.JPopupMenu.menuSelectionChanged(JPopupMenu.java:1465)
at javax.swing.MenuSelectionManager.setSelectedPath(MenuSelectionManager.java:117)
at javax.swing.plaf.basic.BasicMenuUI.appendPath(BasicMenuUI.java:222)
at javax.swing.plaf.basic.BasicMenuUI.access$200(BasicMenuUI.java:49)
at javax.swing.plaf.basic.BasicMenuUI$Actions.actionPerformed(BasicMenuUI.java:280)
at javax.swing.Timer.fireActionPerformed(Timer.java:312)
at javax.swing.Timer$DoPostEvent.run(Timer.java:244)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
A more advanced pattern that tries to take quotes into account. In case
this pattern does not work, this commit can be reverted and instead a
simpler pattern is used that relies on html tags being opened and closed
with < and > brackets. It assumes that < and > are always part of HTML
tags so any textual (content) occurrence should be replaced with html
entities (escaping).