Re: Not able to login to archiva using newly created user
On Fri, Feb 15, 2008 at 4:00 AM, Sunita Pahwa [EMAIL PROTECTED] wrote: I am using archiva 1.0.1 standalone version. When I created new user from 'User Management', On clicking 'create user' it gives following exception: The inability for admin-created users to log in is a known issue in the version of Redback that Archvia 1.0.1 uses. http://jira.codehaus.org/browse/MRM-584 You can click the Resend Validation button and have the user click the link in the email to validate. It's also possible to edit the database directly to flip the 'validated' bit. (The NoSuchPropertyException can safely be ignored.) -- Wendy
Not able to login to archiva using newly created user
I am using archiva 1.0.1 standalone version. When I created new user from 'User Management', On clicking 'create user' it gives following exception: 008-02-15 16:23:06,251 [SocketListener0-0] WARN com.opensymphony.xwork.util.Og lUtil - Caught OgnlException while setting property 'principal' on type ' com.o ensymphony.webwork.dispatcher.ServletActionRedirectResult'. gnl.NoSuchPropertyException: com.opensymphony.webwork.dispatcher.ServletActionR directResult.principal at ognl.ObjectPropertyAccessor.setProperty( ObjectPropertyAccessor.java:1 2) at com.opensymphony.xwork.util.OgnlValueStack$ObjectAccessor.setProperty OgnlValueStack.java:67) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:1656) at ognl.ASTProperty.setValueBody(ASTProperty.java:101) at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:177) at ognl.SimpleNode.setValue(SimpleNode.java:246) at ognl.Ognl.setValue(Ognl.java:476) at com.opensymphony.xwork.util.OgnlUtil.setValue(OgnlUtil.java:188) at com.opensymphony.xwork.util.OgnlUtil.internalSetProperty( OgnlUtil.jav :362) at com.opensymphony.xwork.util.OgnlUtil.setProperties(OgnlUtil.java :78) at com.opensymphony.xwork.util.OgnlUtil.setProperties(OgnlUtil.java :51) at com.opensymphony.xwork.ObjectFactory.buildResult( ObjectFactory.java:1 6) at org.codehaus.plexus.xwork.PlexusObjectFactory.buildResult (PlexusObjec Factory.java:166) at com.opensymphony.xwork.DefaultActionInvocation.createResult (DefaultAc ionInvocation.java:173) at com.opensymphony.xwork.DefaultActionInvocation.executeResult (DefaultA tionInvocation.java:310) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:208) at org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor intercept(SecureActionInterceptor.java:159) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterc ptor.intercept(PolicyEnforcementInterceptor.java:149) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.AutoLoginInterceptor.in ercept(AutoLoginInterceptor.java:156) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.ForceAdminUserIntercept r.intercept(ForceAdminUserInterceptor.java:76) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.EnvironmentCheckInterce tor.intercept(EnvironmentCheckInterceptor.java:122) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doInter ept(DefaultWorkflowInterceptor.java:175) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept( ethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept (Va idationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept( ethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (Around nterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (Around nterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (Around nterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept( ileUploadInterceptor.java:174) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (Around nterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at com.opensymphony.webwork.interceptor.debugging.DebuggingInterceptor.i tercept(DebuggingInterceptor.java:169) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (Around nterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionIn ocation.java:190) at
Re: Exposing artifacts other than jar and pom
On Fri, Feb 15, 2008 at 8:57 AM, Brown, Carlton [EMAIL PROTECTED] wrote: What component would that be under? Just leave it as 'unknown' if nothing looks relevant. We can update it later. Thanks! -- Wendy
Artifacts not being indexed
Hi, I've got a problem where an artifact downloaded to the filesystem cannot be browsed. There's some problem with either the database scanning or repository indexing. The maven metadata files are not being generated. The pom file appears to be good. How can I troubleshoot this problem and determine whether it's the database failing to pick it up, or archiva failing to index it, or something else? Would there be errors written to a log somewhere? I've checked archiva.log which shows nothing except the requests for the scanning and indexing tasks. This is a frequent problem I've been having, it would be good if there were some good diagnostics for indexing problems. -Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Artifacts not being indexed
-Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 1:17 PM To: archiva-users@maven.apache.org Subject: Re: Artifacts not being indexed On Fri, Feb 15, 2008 at 11:06 AM, Brown, Carlton [EMAIL PROTECTED] wrote: I've got a problem where an artifact downloaded to the filesystem cannot be browsed. There's some problem with either the database scanning or repository indexing. The maven metadata files are not being generated. The pom file appears to be good. By downloaded, do you mean you are using Archiva as a proxy? Or do you have an external process that is writing to the filesystem? External process writing to the filesystem. The first thing I'd track down is why there is no metadata file. There is a checkbox in the Archiva config that will make it create missing metadata files. Try checking that box and then clicking 'scan' and then 'update database'. Does it now show up in browse? It does not. That checkbox appears to be enabled by default, and I have been doing 'scan' and 'update database', so no luck there. Strangely, when this happens, the artifacts show up in a search, but you can't browse to them. I mean they don't show up under the /archiva/browse URL, you can use the /repository URL and see them there just fine. (I've seen it create missing metadata files. I'm less sure about its ability to repair broken ones.) It does create missing metadata files, but the process seems to be very hit-or-miss, and shows almost nothing in the way of useful feedback or diagnostics. Is there some other, more decisive manual way to force it to re-scan the entire filesystem and recreate the metadata files? - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Re: Artifacts not being indexed
On Fri, Feb 15, 2008 at 11:31 AM, Brown, Carlton [EMAIL PROTECTED] wrote: Is there some other, more decisive manual way to force it to re-scan the entire filesystem and recreate the metadata files? Sure. Stop Archiva, and delete both the Lucene index files and the Archiva database. Look for a .index directory at the top of your repository. Delete the whole directory, not just the contents. Likewise, delete the whole directory for the Derby database, which is usually in data/archiva/database. Re-start, and then scan and update (in that order.) When you say they can't be browsed, are you seeing an error message? I've had problems when I'm missing a parent pom in the repository. It will say it can't find the object model or some such thing. What version of Archiva are you using? Is it standalone (Plexus Appserver) or are you using the war file in Tomcat/Jetty/etc.? -- Wendy