Return-Path: X-Original-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4E5D5E7FF for ; Tue, 22 Jan 2013 14:38:32 +0000 (UTC) Received: (qmail 6486 invoked by uid 500); 22 Jan 2013 14:38:32 -0000 Delivered-To: apmail-incubator-deltaspike-dev-archive@incubator.apache.org Received: (qmail 6344 invoked by uid 500); 22 Jan 2013 14:38:31 -0000 Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: deltaspike-dev@incubator.apache.org Delivered-To: mailing list deltaspike-dev@incubator.apache.org Received: (qmail 6323 invoked by uid 99); 22 Jan 2013 14:38:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jan 2013 14:38:30 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gnodet@gmail.com designates 209.85.212.181 as permitted sender) Received: from [209.85.212.181] (HELO mail-wi0-f181.google.com) (209.85.212.181) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jan 2013 14:38:24 +0000 Received: by mail-wi0-f181.google.com with SMTP id hq4so5966269wib.14 for ; Tue, 22 Jan 2013 06:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=Uaqf7hJFEm9jYwCqE2bdyN4QGr4vjCzLWGG9Mz9ucUQ=; b=slD/r0IihL8Lp/c4fWiW4UOGeglBV5EU12jtvpUA6wlGwZdwMOPjwBxmDZdMynneRl Ou6ql+U3RmSl6xV4HBDXwziIWo8TJ2iJn9JXX4HXyHc+tQjy0jA6aXbNXSRG8V/D7xUX WxWkHHIEdkfnqYZxeTdYTAiPovXjAIDzUf7EojSxenHHbE2df5qP2h+sg0sKW/Mg89oX odVceeVMhcDao5rOaCNlnQ/j9Atow6IQgNznOLTXmxDfkVIA3fu+hKWxg4cQDVgiNcfR 9vanQLx5cuZ9zWhNXnmpu1ABK0YV2NnRXCpaKf3eu0lpxW6QoOjhqARTUrAB2SKl2SNB hEGA== MIME-Version: 1.0 X-Received: by 10.180.20.138 with SMTP id n10mr26321656wie.0.1358865484329; Tue, 22 Jan 2013 06:38:04 -0800 (PST) Received: by 10.216.66.73 with HTTP; Tue, 22 Jan 2013 06:38:04 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Jan 2013 15:38:04 +0100 Message-ID: Subject: Re: Running deltaspike example in OSGi From: Guillaume Nodet To: deltaspike-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=bcaec53d5b257db28504d3e18689 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec53d5b257db28504d3e18689 Content-Type: text/plain; charset=ISO-8859-1 Yes, they are discovered correctly. It really comes down to the fact that in OSGi, the classloader of the bundle can not really see the META-INF folders of other bundles, so the deltaspike extensions can't be seen. I'm working on a patch for weld-osgi that will use the required bundles, and we can improve further on top of it. On Tue, Jan 22, 2013 at 2:58 PM, John D. Ament wrote: > Guillaume, > > Well, as a first stab did you try enabling the extensions in your bundle to > see if that works? > > > On Tue, Jan 22, 2013 at 8:00 AM, Guillaume Nodet wrote: > > > Definitely, that's why I was thinking about using a declarative way to > > "enable" extensions using the Require-Bundle header. It could be using > > something else, but I agree we need a declarative way and we can't enable > > all extensions. > > > > The problem in OSGi is that the classloader is much more constrained than > > in a usual JSE environment, and the classloader does not see other > bundle's > > content. > > I'll definitely move the discussion on the jira and the weld mailing > list. > > I initially started here because I thought it was a DeltaSpike problem, > > but it now seems rather to be a weld-osgi problem. > > > > > > On Tue, Jan 22, 2013 at 1:31 PM, John D. Ament > >wrote: > > > > > HI Guillaume, > > > > > > Perhaps it's best to move this discussion over to the weld forums > > > https://community.jboss.org/en/weld?view=discussions > > > However, I think perhaps doing this could cause some issues (potential > > > security problems). Think about this. If Weld added every extension > it > > > found that you were dependent on, who's to say you wouldn't > accidentally > > > activate a malicious extension? I have a similar project structure, > > except > > > we're using Seam 3 and JBoss Modules. You can activate all of the > > > extensions you want if you just list them in your module's > > > META-INF/services/javax.enterprise.inject.spi.Extension. This is a > more > > > portable solution when you're not putting your dependencies in your > bean > > > archive. (Now granted I'm not 100% sure this fixes your specific > issue, > > > have to look at how this extension is built to ensure it's not > expecting > > to > > > be in the bean archive). > > > > > > John > > > > > > > > > On Tue, Jan 22, 2013 at 5:50 AM, Guillaume Nodet > > wrote: > > > > > > > No, it's actually more complicated than that I think. > > > > The findEntries does not take Require-Bundle into account. > > > > I've raised https://issues.jboss.org/browse/WELD-1309 > > > > > > > > We could leverage Require-Bundle and add the extensions in required > > > bundles > > > > to the cdi container, but I'm not sure Require-Bundle is the best > way. > > > The > > > > reason is that Require-Bundle has a real OSGi purpose and there may > be > > > > cases where you need a Require-Bundle without wanting this side > effect. > > > > Maybe a specific manifest header would be better, or even use the > OSGi > > > > registry to expose Extension as OSGi services for bundles that act as > > > > extensions libraries such as Deltaspike. > > > > > > > > > > > > On Tue, Jan 22, 2013 at 11:33 AM, Charles Moulliard < > ch007m@gmail.com > > > > >wrote: > > > > > > > > > Guillaume, > > > > > > > > > > Problem should be fixed in weld-osgi project where we should > replace > > > > > bundle.getResources() with > > > > > bundle.findEntries(). > > > > > > > > > > > > > > > On Tue, Jan 22, 2013 at 10:42 AM, Guillaume Nodet < > gnodet@gmail.com> > > > > > wrote: > > > > > > > > > > > @Charles, I'm trying to deploy the jse-example from the > deltaspike > > > > source > > > > > > code > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-deltaspike/tree/master/deltaspike/examples/jse-examples > > > > > > > > > > > > @Romain I'll double check, but given this is the only bit in the > > > > example > > > > > > that does not work, i don't think it's a classloader issue. > > > > > > I've debugged a bit and the problem seems to come from the fact > > that > > > > the > > > > > > deltaspike extensions are not loaded correctly. > > > > > > I think this is because weld-osgi uses the bundle.getResources() > > > > instead > > > > > of > > > > > > bundle.findEntries() to discover extensions. > > > > > > In my case, in order to have the deltaspike extensions loaded, I > > > added > > > > a > > > > > > Require-Bundle header on the test bundle to point to the > deltaspike > > > > > > implementation bundle. > > > > > > Unfortunately, getResources() uses the class space and thus the > > > > > deltaspike > > > > > > META-INF/services/javax.enterprise.inject.spi.Extension is > shadowed > > > by > > > > > the > > > > > > one in the bundle. > > > > > > > > > > > > Am I doing something wrong with the Require-Bundle or is that a > bug > > > in > > > > > > weld-osgi ? > > > > > > I'd be happy to provide a patch for any issue. > > > > > > > > > > > > > > > > > > On Tue, Jan 22, 2013 at 9:42 AM, Romain Manni-Bucau > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > can you check in the Validator the classloader(s) of > > > @ConfigProperty? > > > > > > > wonder if both (scanned one from weld and the one from the app) > > > > aren't > > > > > > > different. > > > > > > > > > > > > > > 2013/1/22 Guillaume Nodet > > > > > > > > > > > > > > > ConfigProperty > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Romain Manni-Bucau* > > > > > > > *Twitter: @rmannibucau * > > > > > > > *Blog: **http://rmannibucau.wordpress.com/*< > > > > > > > http://rmannibucau.wordpress.com/> > > > > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > > > > > > > *Github: https://github.com/rmannibucau* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > ------------------------ > > > > > > Guillaume Nodet > > > > > > ------------------------ > > > > > > Blog: http://gnodet.blogspot.com/ > > > > > > ------------------------ > > > > > > FuseSource, Integration everywhere > > > > > > http://fusesource.com > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Charles Moulliard > > > > > Apache Committer / Sr. Enterprise Architect (RedHat) > > > > > Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com > > > > > > > > > > > > > > > > > > > > > -- > > > > ------------------------ > > > > Guillaume Nodet > > > > ------------------------ > > > > Blog: http://gnodet.blogspot.com/ > > > > ------------------------ > > > > FuseSource, Integration everywhere > > > > http://fusesource.com > > > > > > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > FuseSource, Integration everywhere > > http://fusesource.com > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com --bcaec53d5b257db28504d3e18689--