On 12/23/2015 06:22 PM, Dan Haywood wrote:
Um, fixed.

The DomainAppAppManifest had the security module commented out (I was using
it for a demo, must've pushed it like that...).  Do a git pull and it
should work.
The application does work now. Will try to reproduce the issue.

Alternatively, if you run with
the DomainAppAppManifestWithFixturesBypassSecurity, then any user/password
will work.

We generally run the app from the IDE (IntelliJ), using the
org.apache.isis.WebServer utility class, which recognizes --manifest flag
and others to specify the app manifest [1], [2]

HTH
Dan


[1] http://isis.apache.org/guides/ugbtb.html#_ugbtb_deployment_cmd-line
[2] http://imgur.com/tyvuWtG



On 23 December 2015 at 16:42, Erik de Hair <e.deh...@pocos.nl> wrote:

On 12/23/2015 05:37 PM, Dan Haywood wrote:

try either:

- domainapp-admin/pass
- isis-module-security-admin/pass

Dan

Both result in an exception. Does it matter how to start the application?
I did a "mvn jetty:run -D jetty.port=9090".

Caused by: java.lang.NullPointerException
         at
org.isisaddons.module.security.shiro.IsisModuleSecurityRealm$1.lookupUser(IsisModuleSecurityRealm.java:155)
         at
org.isisaddons.module.security.shiro.IsisModuleSecurityRealm$1.execute(IsisModuleSecurityRealm.java:146)
         at
org.isisaddons.module.security.shiro.IsisModuleSecurityRealm$1.execute(IsisModuleSecurityRealm.java:143)
         at
org.apache.isis.core.runtime.system.transaction.IsisTransactionManager.executeWithinTransaction(IsisTransactionManager.java:216)
         at
org.isisaddons.module.security.shiro.IsisModuleSecurityRealm.doExecute(IsisModuleSecurityRealm.java:226)
         at
org.isisaddons.module.security.shiro.IsisModuleSecurityRealm.execute(IsisModuleSecurityRealm.java:217)
         at
org.isisaddons.module.security.shiro.IsisModuleSecurityRealm.lookupPrincipal(IsisModuleSecurityRealm.java:143)
         at
org.isisaddons.module.security.shiro.IsisModuleSecurityRealm.doGetAuthenticationInfo(IsisModuleSecurityRealm.java:82)
         at
org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)
         at
org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:180)
         at
org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:267)
         at
org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)


On 23 December 2015 at 16:35, Erik de Hair <e.deh...@pocos.nl> wrote:

Hi Martin,
I tried to use the quickstart-app to reproduce the issue but I can't
login
with the provided username/password combination. I looks like the
credentials are correct in the AdminUser-fixture script. Do I need to
start
the user seed somehow?

Erik


On 12/11/2015 04:33 PM, Erik de Hair wrote:

On 12/09/2015 08:31 PM, Martin Grigorov wrote:
Hi Erik,
What kind of button is this ?
To me it looks like this is the "OK" button from the
ActionParametersFormPanel.java, i.e. the OK button for a Modal window
where
you enter the parameters for an @Action

(org.apache.isis.viewer.wicket.ui.components.actions.ActionParametersFormPanel.ActionParameterForm#addButtons).


Line"boolean succeeded =
actionExecutor.executeActionAndProcessResults(target, form);" is
responsible to call your action method. I don't see how this code will
be
executed if there is an error like the one below.

Please try to reproduce it in a mini app.

Ok, I'll try to do that.
Thank you!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Wed, Dec 9, 2015 at 8:53 AM, Erik de Hair <e.deh...@pocos.nl>
wrote:

Hi Martin,

On 12/04/2015 02:15 PM, Martin Grigorov wrote:

Hi Erik,

On Fri, Dec 4, 2015 at 2:50 PM, Erik de Hair <e.deh...@pocos.nl>
wrote:

ListenerInvocationNotAllowedExceptionBehavior rejected interface

invocation. Component: [AjaxButton [Component id = okButton]]
Behavior:
org.apache.wicket.ajax.markup.html.form.AjaxButton$1@7585b8c9
Listener:
[RequestListenerInterface name=IBehaviorListener, method=public
abstract
void org.apache.wicket.behavior.IBehaviorListener.onRequest()]


org.apache.wicket.RequestListenerInterface#invoke(RequestListenerInterface.java:237)


This exception means that Wicket cannot execute #onSubmit() method
for

this
AjaxButton because the button is either disabled or invisible.

So, the button is rendered by Isis/Wicket and *after* that its
usability
(visibility and/or enable) is being changed. Clicking on it in the UI
makes
a call to the server but Wicket refuses to execute the method.

It does actually completely execute the method.

So you think this could occur when an action is executed for which the
button would be rendered (enabled) before the method was executed, but
would be disabled/hidden after method execution because of changed
object
state?

We will need a mini application that reproduces the problem to be able

to
help you.

If you expect the above assumption is correct I wil try to reproduce

that
scenario.


Martin Grigorov

Wicket Training and Consulting
https://twitter.com/mtgrigorov





Reply via email to