Mailing-List: contact ace-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ace-dev@incubator.apache.org
Date: Tue, 7 Jun 2011 20:35:58 +0000 (UTC)
From: "Karl Pauls (JIRA)" <jira@apache.org>
To: ace-dev@incubator.apache.org
Message-ID: 
 <952632896.1259.1307478958811.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <674362994.263.1307362678868.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (ACE-149) Upload of two bundles with same bsn &
 version, but different jar name, breaks artifact column
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ACE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045617#comment-13045617 ] 

Karl Pauls commented on ACE-149:
--------------------------------

After looking into this a bit more I don't think there is an easy fix for it. We seem to have failed to find a well working unique identity schema that we apply consistently across our handling of artifacts. Unfortunately, this adds up to the problem we see. In a nutshell, the ui uses the name of the artifact as id, the artifact repo uses the url, the helpers some combinations out of symbolic name, version, and url, and the obr does use a combination out of the file name and the symbolic name and version. On top, this obviously only applies to bundles and other artifacts are handled differently. So what happens is that while a duplicated bundle gets added to the obr, you can't see it afterwords in the repository.xml and worth, the ui will get it from the artifact repo but as the name is the same it gets back a null from the table lookup -- hence, the exception.

I assigned the issue to me for now and will try to come-up with a better way to handle the identities and implement it. However, its going to take me while. For now, there is a workaround namely, delete one of the jars from the "store" folder that the obr uses to put the bundles in. That should make things work again (again, i'll try to get back to this asap).

> Upload of two bundles with same bsn & version, but different jar name, breaks artifact column
> ---------------------------------------------------------------------------------------------
>
>                 Key: ACE-149
>                 URL: https://issues.apache.org/jira/browse/ACE-149
>             Project: Ace
>          Issue Type: Bug
>          Components: Web UI
>    Affects Versions: 0.8.0
>            Reporter: Angelo van der Sijpt
>            Assignee: Karl Pauls
>
> Scenario:
> - upload a bundle,
> - click 'store',
> - upload the same bundle, but with a different jar name,
> - click 'store', click 'retrieve'
> This 'breaks' the artifact column in such a way that no new bundles can be added anymore.
> com.vaadin.event.ListenerMethod$MethodException
> Cause: java.lang.NullPointerException
> 	at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:510)
> 	at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:162)
> 	at com.vaadin.ui.AbstractComponent.fireEvent(AbstractComponent.java:1166)
> 	at com.vaadin.ui.Button.fireClick(Button.java:380)
> 	at com.vaadin.ui.Button.changeVariables(Button.java:196)
> 	at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariableBurst(AbstractCommunicationManager.java:1297)
> 	at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariables(AbstractCommunicationManager.java:1217)
> 	at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(AbstractCommunicationManager.java:733)
> 	at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:296)
> 	at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:483)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> 	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
> 	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:389)
> 	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:64)
> 	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> 	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
> 	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.handle(HttpServiceContext.java:111)
> 	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:64)
> 	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> 	at org.mortbay.jetty.Server.handle(Server.java:326)
> 	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
> 	at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879)
> 	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
> 	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
> 	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> 	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
> 	at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)
> Caused by: java.lang.NullPointerException
> 	at org.apache.ace.webui.vaadin.VaadinClient$12.add(VaadinClient.java:587)
> 	at org.apache.ace.webui.vaadin.VaadinClient$12.populate(VaadinClient.java:560)
> 	at org.apache.ace.webui.vaadin.VaadinClient.updateTableData(VaadinClient.java:1047)
> 	at org.apache.ace.webui.vaadin.VaadinClient.access$1500(VaadinClient.java:128)
> 	at org.apache.ace.webui.vaadin.VaadinClient$9.buttonClick(VaadinClient.java:499)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:490)
> 	... 26 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira