Re: Comments on GSOC2014 ReputationBox proposal
Hi All, After doing some background reading on Reputation object modeling [1], I have extended my class diagram to describe the reputation analysis model in my application : http://yuml.me/c97453ec An entity has a reputation which describes it's value. EmailContact, Email are the 2 entity objects in my application. Reputation is an interface implemented by ReputationObject class. Reputation has a particular context/domain in which it isearned (eCommerce, films, technical forums etc ), in this case the context is email communication. The reputation's value is represented by the ReputationValue object which is calculated based on a certain criteria (In my case the criteria are People associated with the email, topic and actions in the email). Criteria defines the required parameters and the ComputationAlgorithm to be used to calculate reputation value. The reputation value is calculated by the particular ComputationAlgorithm using the parameters given by the criteria. This is where the implementation specific stuff comes in for calculation. Mahout recommendation algorithms, Drools rules are implementations of such ComputationAlgorithms. @David, Dan I think above model defines the service contracts well for the domain model of my application. Suggestions are welcome as always. Thanks, Dileepa [1] Adrian Paschke, Rehab Alnemr, Christoph Meinel, The Rule Responder Distributed Reputation Management System for the Semantic Web On Thu, Mar 27, 2014 at 2:10 AM, David Tildesley davo...@yahoo.co.nzwrote: Hi Dileepa, Regardless of the implementation of the service, you should be able to determine the service contract which would allow you to model the domain. At the end of the day, the biggest influencer on domain shape is behaviour. Regards, David. On Thursday, 27 March 2014 9:15 AM, Dileepa Jayakody dileepajayak...@gmail.com wrote: Hi David, On Thu, Mar 27, 2014 at 1:13 AM, David Tildesley davo...@yahoo.co.nz wrote: Now we are getting somewhere. Why do you want the domain to supply the keywords to the reputation analysis component? Do you allow the end user to define these keywords? If not then do they change all the time and you need an admin role to be constantly updating them? If not then why not load them as a static property file when Mahout starts? And if the keywords are allowed to change does that mean that all emails and contacts must be rescored? Thanks for your suggestions. I haven't yet designed the ReputationAnalysisService functions. I will have to do some background research on Mahout/weka and Drools expert [1] (as Oscar suggested I will also consider Drools expert for this component) to answer your queries precisely. At the moment, I have the idea to perform the email analysis process as below; 1. An initial email analysis process will be carried out to process past emails in the user's inbox and build up a reputation index (a regression model to rate each email based on reputation). 2. Then using that regression model predict reputation of new emails. I'm currently doing some reading on available ML libraries like Mahout, weka and also RulesEngines like Drools in order to design this component. Your suggestions are also welcome.. [1] https://www.jboss.org/drools/drools-expert If the score for a contact is based on a history of their email scores then what holds this history? (hopefully you are going to tell me that Mahout/Hadoop) does and therefore the domain does not care. David. On Thursday, 27 March 2014 12:24 AM, Dileepa Jayakody dileepajayak...@gmail.com wrote: Hi David, On Wed, Mar 26, 2014 at 4:03 PM, David Tildesley davo...@yahoo.co.nz wrote: Hi Dileepa, I see. Then the domain will perhaps have some object representing ReputationScore with a method such as calculateEmailReputationScore and calculateEmailContactReputationScore with the implementation of the methods based on Mahout and injected via a domain service. So it's the same deal no matter how you want to reword it - the complexity of the score calculation is not in the ISIS domain but in the Mahout implementation. Yes, the domain service (ReputationAnalysisService) will call out a Mahout recommender process to give the reputation score of the new email. So what information do you need to feed these two methods in order to do the calculation? I'm planning to feed people (to, cc, from), topic and actions (keywords such as meeting, project, important etc) mentioned in the email to perform reputation calculation. David. On Wednesday, 26 March 2014 11:09 PM, Dileepa Jayakody dileepajayak...@gmail.com wrote: Hi David, On Wed, Mar 26, 2014 at 3:22 PM, David Tildesley davo...@yahoo.co.nz wrote: Hi David, On Wednesday, 26 March 2014 8:49 PM, Dileepa Jayakody dileepajayak...@gmail.com wrote: Hi Dan, David and all, Above class diagram
Jenkins build became unstable: isis-core-ubuntu ยป Isis RestfulObjects Viewer TCK tests #982
See https://builds.apache.org/job/isis-core-ubuntu/org.apache.isis.viewer$isis-viewer-restfulobjects-tck/982/
Jenkins build became unstable: isis-core-ubuntu #982
See https://builds.apache.org/job/isis-core-ubuntu/982/
[jira] [Created] (ISIS-758) Auditing should be able to cope with a change to a property where the referenced object has been deleted.
Jeroen van der Wal created ISIS-758: --- Summary: Auditing should be able to cope with a change to a property where the referenced object has been deleted. Key: ISIS-758 URL: https://issues.apache.org/jira/browse/ISIS-758 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.4.0 Reporter: Jeroen van der Wal Assignee: Dan Haywood Fix For: core-1.4.2 For example, doing a cascade delete of Parent -* Child. Here, the Parent and each of the Children will be audited, and in the case of Child, its parent reference is changing from (parent) to null. However, as the parent itself is deleted, trying to generate its toString() (when using JDO object store) is causing an exception. The fix is to grab the toString of the object when the objects are enlisted into the transaction, before they are deleted. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ISIS-758) Auditing should be able to cope with a change to a property where the referenced object has been deleted.
[ https://issues.apache.org/jira/browse/ISIS-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13957721#comment-13957721 ] ASF subversion and git services commented on ISIS-758: -- Commit 8c45cc01b16cc95474894dc1a1033871a7e56500 in isis's branch refs/heads/master from [~jcvanderwal] [ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=8c45cc0 ] ISIS-758: auditing should handle deleted objects. Also: - better exception handling within ObjectContracts for getValueOf(...). Auditing should be able to cope with a change to a property where the referenced object has been deleted. - Key: ISIS-758 URL: https://issues.apache.org/jira/browse/ISIS-758 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.4.0 Reporter: Jeroen van der Wal Assignee: Dan Haywood Fix For: core-1.4.2 For example, doing a cascade delete of Parent -* Child. Here, the Parent and each of the Children will be audited, and in the case of Child, its parent reference is changing from (parent) to null. However, as the parent itself is deleted, trying to generate its toString() (when using JDO object store) is causing an exception. The fix is to grab the toString of the object when the objects are enlisted into the transaction, before they are deleted. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (ISIS-759) Transient errors being logged as result of incorrect call to sendRedirect; not sure why, need diagnostics.
Dan Haywood created ISIS-759: Summary: Transient errors being logged as result of incorrect call to sendRedirect; not sure why, need diagnostics. Key: ISIS-759 URL: https://issues.apache.org/jira/browse/ISIS-759 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.4.0 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: core-1.4.2 For now, just introduce a new filter which will log the request URL whenever an exception propogates out. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (ISIS-760) IllegalStateException when commands/audit enabled in Estatio and failing to persist the Oid of a view model.
Jeroen van der Wal created ISIS-760:
---
Summary: IllegalStateException when commands/audit enabled in
Estatio and failing to persist the Oid of a view model.
Key: ISIS-760
URL: https://issues.apache.org/jira/browse/ISIS-760
Project: Isis
Issue Type: Bug
Reporter: Jeroen van der Wal
Assignee: Dan Haywood
Priority: Critical
There are two separate issues here:
- first is that the auditing service's column for storing OIDs isn't long
enough for view models.
- the second is that, given this then causes the xactn to be aborted, that it
throws an IllegalStateException for any subsequent interaction with the system.
The only fix is to restart the server. See details below
The reason for the second issue is that the previous session does not close
correctly. This is because of an exception being thrown in
PersistenceSession#close:
PersistenceSession.completeCommandIfConfigured() line: 418
PersistenceSession.closeServices() line: 399
PersistenceSession.close() line: 372
IsisSessionDefault.close() line: 119
IsisContextThreadLocal(IsisContext).closeSessionInstance() line: 219
WebRequestCycleForIsis.onEndRequest(RequestCycle) line: 134
This in turn is because of an attempt to complete any pending command (per the
CommandJdo service) on a xactn that has already been aborted.
The fix, I think, is simple enough; add a guard...
private void completeCommandIfConfigured() {
// NEW CODE START
if(getTransactionManager().getTransaction().getState().isComplete()) {
// can't do anything, since already complete (possibly aborted)
return;
}
// NEW CODE END
final CommandContext commandContext =
getServiceOrNull(CommandContext.class);
if(commandContext != null) {
final CommandService commandService =
getServiceOrNull(CommandService.class);
if(commandService != null) {
final Command command = commandContext.getCommand();
commandService.complete(command);
}
}
}
~~
to reproduce:
with estatio demo data
find invoices for status new
choose oxford
approve all.
A server restart was required.
{code}
java.lang.IllegalStateException
Session already open and context not configured for autoclose
org.apache.isis.core.runtime.system.context.IsisContext#applySessionClosePolicy(IsisContext.java:186)
org.apache.isis.core.runtime.system.context.IsisContextThreadLocal#openSessionInstance(IsisContextThreadLocal.java:148)
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis#onBeginRequest(WebRequestCycleForIsis.java:81)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:65)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:61)
org.apache.wicket.util.listener.ListenerCollection#notify(ListenerCollection.java:80)
org.apache.wicket.request.cycle.RequestCycleListenerCollection#onBeginRequest(RequestCycleListenerCollection.java:60)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:65)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:61)
org.apache.wicket.util.listener.ListenerCollection#notify(ListenerCollection.java:80)
org.apache.wicket.request.cycle.RequestCycleListenerCollection#onBeginRequest(RequestCycleListenerCollection.java:60)
org.apache.wicket.request.cycle.RequestCycle#processRequest(RequestCycle.java:213)
org.apache.wicket.request.cycle.RequestCycle#processRequestAndDetach(RequestCycle.java:289)
org.apache.wicket.protocol.http.WicketFilter#processRequestCycle(WicketFilter.java:259)
org.apache.wicket.protocol.http.WicketFilter#processRequest(WicketFilter.java:201)
org.apache.wicket.protocol.http.WicketFilter#doFilter(WicketFilter.java:282)
org.apache.catalina.core.ApplicationFilterChain#internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain#doFilter(ApplicationFilterChain.java:210)
org.apache.shiro.web.servlet.AbstractShiroFilter#executeChain(AbstractShiroFilter.java:449)
org.apache.shiro.web.servlet.AbstractShiroFilter$1#call(AbstractShiroFilter.java:365)
org.apache.shiro.subject.support.SubjectCallable#doCall(SubjectCallable.java:90)
org.apache.shiro.subject.support.SubjectCallable#call(SubjectCallable.java:83)
org.apache.shiro.subject.support.DelegatingSubject#execute(DelegatingSubject.java:383)
org.apache.shiro.web.servlet.AbstractShiroFilter#doFilterInternal(AbstractShiroFilter.java:362)
org.apache.shiro.web.servlet.OncePerRequestFilter#doFilter(OncePerRequestFilter.java:125)
[jira] [Updated] (ISIS-760) IllegalStateException when commands/audit enabled in Estatio and failing to persist the Oid of a view model.
[
https://issues.apache.org/jira/browse/ISIS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-760:
Description:
There are two separate issues here:
- first is that the auditing service's column for storing OIDs isn't long
enough for view models.
- the second is that, given this then causes the xactn to be aborted, that it
throws an IllegalStateException for any subsequent interaction with the system.
The only fix is to restart the server. See details below
The reason for the second issue is that the previous session does not close
correctly. This is because of an exception being thrown in
PersistenceSession#close:
PersistenceSession.completeCommandIfConfigured() line: 418
PersistenceSession.closeServices() line: 399
PersistenceSession.close() line: 372
IsisSessionDefault.close() line: 119
IsisContextThreadLocal(IsisContext).closeSessionInstance() line: 219
WebRequestCycleForIsis.onEndRequest(RequestCycle) line: 134
This in turn is because of an attempt to complete any pending command (per the
CommandJdo service) on a xactn that has already been aborted
private void completeCommandIfConfigured() {
final CommandContext commandContext =
getServiceOrNull(CommandContext.class);
if(commandContext != null) {
final CommandService commandService =
getServiceOrNull(CommandService.class);
if(commandService != null) {
final Command command = commandContext.getCommand();
commandService.complete(command);
}
}
}
So, when closing the session, need to take this into account. Should propogate
exception if any arises, but still ensure that the persistence session is
closed for next-time around.
~~
to reproduce:
with estatio demo data
find invoices for status new
choose oxford
approve all.
A server restart was required.
{code}
java.lang.IllegalStateException
Session already open and context not configured for autoclose
org.apache.isis.core.runtime.system.context.IsisContext#applySessionClosePolicy(IsisContext.java:186)
org.apache.isis.core.runtime.system.context.IsisContextThreadLocal#openSessionInstance(IsisContextThreadLocal.java:148)
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis#onBeginRequest(WebRequestCycleForIsis.java:81)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:65)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:61)
org.apache.wicket.util.listener.ListenerCollection#notify(ListenerCollection.java:80)
org.apache.wicket.request.cycle.RequestCycleListenerCollection#onBeginRequest(RequestCycleListenerCollection.java:60)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:65)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:61)
org.apache.wicket.util.listener.ListenerCollection#notify(ListenerCollection.java:80)
org.apache.wicket.request.cycle.RequestCycleListenerCollection#onBeginRequest(RequestCycleListenerCollection.java:60)
org.apache.wicket.request.cycle.RequestCycle#processRequest(RequestCycle.java:213)
org.apache.wicket.request.cycle.RequestCycle#processRequestAndDetach(RequestCycle.java:289)
org.apache.wicket.protocol.http.WicketFilter#processRequestCycle(WicketFilter.java:259)
org.apache.wicket.protocol.http.WicketFilter#processRequest(WicketFilter.java:201)
org.apache.wicket.protocol.http.WicketFilter#doFilter(WicketFilter.java:282)
org.apache.catalina.core.ApplicationFilterChain#internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain#doFilter(ApplicationFilterChain.java:210)
org.apache.shiro.web.servlet.AbstractShiroFilter#executeChain(AbstractShiroFilter.java:449)
org.apache.shiro.web.servlet.AbstractShiroFilter$1#call(AbstractShiroFilter.java:365)
org.apache.shiro.subject.support.SubjectCallable#doCall(SubjectCallable.java:90)
org.apache.shiro.subject.support.SubjectCallable#call(SubjectCallable.java:83)
org.apache.shiro.subject.support.DelegatingSubject#execute(DelegatingSubject.java:383)
org.apache.shiro.web.servlet.AbstractShiroFilter#doFilterInternal(AbstractShiroFilter.java:362)
org.apache.shiro.web.servlet.OncePerRequestFilter#doFilter(OncePerRequestFilter.java:125)
org.apache.catalina.core.ApplicationFilterChain#internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain#doFilter(ApplicationFilterChain.java:210)
org.apache.catalina.core.StandardWrapperValve#invoke(StandardWrapperValve.java:225)
org.apache.catalina.core.StandardContextValve#invoke(StandardContextValve.java:123)
