You can embed the dependency jar as it is without unpacking the jar file. One of the jars is singed. Thats why you get this exception.
On Mon, Apr 6, 2015 at 11:14 AM, Niranda Perera <nira...@wso2.com> wrote: > Hi Sameera, > > Noted. > > returning back to where this issue occurred initially, when I include the > dependencies in the spark component, in the server start up, there was a > "java.lang.SecurityException: class "javax.servlet.FilterRegistration"'s > signer information does not match signer information of other classes in > the same package" exception for the classes that came from the jars > included as dependencies. > > just wondering if you have any idea why such an exception might occur? > > rgds > > On Mon, Apr 6, 2015 at 10:43 AM, Sameera Jayasoma <same...@wso2.com> > wrote: > >> Hi Niranda, >> >> On Mon, Apr 6, 2015 at 10:25 AM, Niranda Perera <nira...@wso2.com> wrote: >> >>> Hi Sameera, >>> >>> I agree with you on the compilation scenario. It was mistake on my part. >>> >>> But recently I came across with this issue. Pls consider the following >>> scenario. >>> >>> a non-OSGI jar say, 'foo.jar' depends on the 'a.jar' and 'b.jar' which >>> are OSGI bundles. >>> >>> foo (non-OSGI) >>> |_ a (OSGI) >>> |_ b (OSGI) >>> >>> I OSGIfy foo.jar designating a & b as import-packages to make the >>> "foo-orbit.jar". >>> >>> when I compile my component using foo-orbit.jar it compiles without an >>> issue. but when I run the unit tests of the component, in the run-time I >>> encounter classnotfound exceptions in the classes of a.jar and b.jar. so, I >>> have to specify a and b as dependencies in the component along with the >>> foo-orbit. >>> when I compile the component using the original foo, compilation and >>> testing (run-time) happens seamlessly without having to specify a & b >>> dependencies individually. >>> Is this the expected behavior? >>> >> >> This is exactly the expected behavior. You need to declare all the >> dependencies of a component in the pom.xml for compilation and testing. All >> the dependencies of a carbon component should be OSGi bundles. There are >> few exceptions though. >> >> Thanks, >> Sameera. >> >>> >>> this issue occurred to me while I was testing the spark components with >>> the spark orbits. and the classnotfound exceptions are thrown in the spark >>> server start-up. >>> >>> Gokul also told me that he encountered a similar problem with the hadoop >>> client orbit. >>> >>> look forward to know your thoughts in this regard. >>> >>> rgds >>> >>> >>> On Wed, Mar 25, 2015 at 4:36 PM, Sameera Jayasoma <same...@wso2.com> >>> wrote: >>> >>>> We are in the process of getting rid of transitive dependencies from >>>> orbits, carbon components etc. >>>> >>>> If your component requires the original Spark libraries for compilation >>>> then there are obvious issues in your Spark orbit bundle. A component >>>> should be able compile using orbits and other component dependencies. If >>>> this is not possible, then your component dependencies are not properly >>>> "OSGified" >>>> >>>> A component shouldn't depend on transitive dependencies. Thats the >>>> plan. If you see issues with this approach, please explain. >>>> >>>> Thanks, >>>> Sameera. >>>> >>>> >>>> >>>> On Tue, Mar 24, 2015 at 11:00 AM, Gokul Balakrishnan <go...@wso2.com> >>>> wrote: >>>> >>>>> Hi Kernel team, >>>>> >>>>> Any idea on $subject? Shouldn't the transitive dependencies of the >>>>> orbit bundle be visible to the component referring to the bundle at >>>>> compile >>>>> time? Should we just refer to the 3rd party jar (the orbit bundle is >>>>> wrapping) in the component and use the orbit in the feature, or should we >>>>> use the orbit bundle for both? Would be great if you could clarify. >>>>> >>>>> Thanks, >>>>> >>>>> On 23 March 2015 at 14:59, Niranda Perera <nira...@wso2.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> As of the current orbit bundle guideline [1], we have to mark the >>>>>> dependencies as optional. I believe this results in transitive >>>>>> dependencies >>>>>> of that particular bundle not being exposed. >>>>>> >>>>>> Because of this, I have experienced compilation failures, when I put >>>>>> orbit bundles as component dependencies. >>>>>> For an example, in carbon analytics components, when I import >>>>>> spark-core orbit, I encsounter dependency errors (But when I import the >>>>>> original spark dependency this does not occur) >>>>>> >>>>>> so, is it a good practice for us to say that, orbit bundles should be >>>>>> used in the runtime, where as in the compile time, use the original jars? >>>>>> essentially, is it okay to include original jars in the components >>>>>> and only include orbits in the features? (because earlier, I was under >>>>>> the >>>>>> impression that, once an orbit bundle is created, it should be used BOTH >>>>>> in >>>>>> the components and in the feature) >>>>>> >>>>>> would be great if you could clarify this matter. >>>>>> >>>>>> rgds >>>>>> >>>>>> [1] >>>>>> https://docs.google.com/a/wso2.com/document/d/1I3nWPnG6139YobZzQWPFOUxYEmHxqf9ieWykmQupPtc/edit# >>>>>> >>>>>> -- >>>>>> *Niranda Perera* >>>>>> Software Engineer, WSO2 Inc. >>>>>> Mobile: +94-71-554-8430 >>>>>> Twitter: @n1r44 <https://twitter.com/N1R44> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> Dev@wso2.org >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Balakrishnan Gokulakrishnan* >>>>> Software Engineer, >>>>> WSO2, Inc. http://wso2.com >>>>> Mob: +94 77 593 5789 | +1 650 272 9927 >>>>> >>>> >>>> >>>> >>>> -- >>>> Sameera Jayasoma, >>>> Software Architect, >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: same...@wso2.com >>>> blog: http://blog.sameera.org >>>> twitter: https://twitter.com/sameerajayasoma >>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>> Mobile: 0094776364456 >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> >>> >>> >>> -- >>> *Niranda Perera* >>> Software Engineer, WSO2 Inc. >>> Mobile: +94-71-554-8430 >>> Twitter: @n1r44 <https://twitter.com/N1R44> >>> >> >> >> >> -- >> Sameera Jayasoma, >> Software Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: same...@wso2.com >> blog: http://blog.sameera.org >> twitter: https://twitter.com/sameerajayasoma >> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >> Mobile: 0094776364456 >> >> Lean . Enterprise . Middleware >> >> > > > -- > *Niranda Perera* > Software Engineer, WSO2 Inc. > Mobile: +94-71-554-8430 > Twitter: @n1r44 <https://twitter.com/N1R44> > -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://blog.sameera.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
