Re: framework snapshot

2010-07-27 Thread Toni Menzel
Why isn't there a CI Build publishing the snapshots continuously ?

On Tue, Jul 27, 2010 at 7:03 PM, Richard S. Hall  wrote:
>  On 7/26/10 18:01, Jarek Gawor wrote:
>>
>> Hi,
>>
>> Can someone please publish latest snapshot of the framework module?
>
> Published framework, main, and main.distribution...
>
> -> richard
>
>> Thanks,
>> Jarek
>



-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org     - New Energy for OSS Communities - Open
Participation Software.


Re: fileinstall 3.1.0 release?

2010-07-27 Thread Sanjeeb Sahoo

Hi,

So far I have not got  a reply to my earlier request. Does anyone object 
to making a release of 3.1.0 off trunk?


Thanks,
Sahoo
On Thursday 22 July 2010 05:20 AM, Sanjeeb Sahoo wrote:

Hi,

Is anyone planning to cut fileinstall 3.1.0 release anytime in near 
future? I would like a newer version of fileinstall in order to 
benefit from FELIX-1657.


Thanks,
Sahoo




Re: framework snapshot

2010-07-27 Thread Richard S. Hall

 On 7/26/10 18:01, Jarek Gawor wrote:

Hi,

Can someone please publish latest snapshot of the framework module?


Published framework, main, and main.distribution...

-> richard


Thanks,
Jarek


Re: Web Console 3.1.2

2010-07-27 Thread Felix Meschberger
Hi,

On 12.07.2010 14:45, Charles Moulliard wrote:
> Hi,
> 
> When the release 3.1.2 of Web Console is planned (end of July, Augustus,
> ) ?

I don't think there are concrete plans for a concrete date. I have
recently been looking at the open issues and from what I remeber, we can
surely cut a release sometime soon.

WDYT ?

Regards
Felix


> 
> Kind regards,
> 
> Charles Moulliard
> 
> Senior Enterprise Architect (J2EE, .NET, SOA)
> Apache Camel - ServiceMix Committer
> ~~~
> Blog : http://cmoulliard.blogspot.com |  Twitter :
> http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard
> 


[jira] Resolved: (FELIX-2486) ClassLoaderJavaClassDescription.isA does not work under certain circumstances

2010-07-27 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved FELIX-2486.
--

Resolution: Fixed

Fixed by implementing ClassLoaderJavaClassDescriptor.isA(String) using 
Class.isAssignableFrom(Class) in Rev. 979703.

> ClassLoaderJavaClassDescription.isA does not work under certain circumstances
> -
>
> Key: FELIX-2486
> URL: https://issues.apache.org/jira/browse/FELIX-2486
> Project: Felix
>  Issue Type: Bug
>  Components: Maven SCR Plugin
>Affects Versions:  maven-scr-plugin-1.4.4
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For:  maven-scr-plugin-1.4.6
>
>
> Consider two bundles B1 and B2. B1 provides an abstract component AC1. This 
> abstract component declares itself to implement Service S by means of
>@scr.service interface="S"
> No AC1 does not itself implement S but it extends a baseclass which in turn 
> implements S.
> This bundle B1 builds perfectly and the SCR plugin generates the descriptor 
> for the abstract component.
> Now, B2 provides a concrete component CC2 extending AC1. B2 fails to build 
> while trying to generate the SCR descriptor.
> The reason for this is, that while generating descriptor for CC2, the exsting 
> service descriptor for AC1 is validated, particularly the service element. 
> This element is checked in the context of the abstract AC1 component class 
> internally represented by a ClassLoaderJavaClassDescriptor instance. To 
> verify the interface, the isA(String) method is called.
> This is where the problem occurrs: The ClassLoaderJavaClassDescriptor.isA 
> method only considers the interfaces directly implemented by the class but 
> not any interfaces implemented by the parent class. Moreover, this 
> implementation does not allow for classes (as opposed to interfaces) to be 
> used as service interface name.
> The fix is probably to use Class.isAssignableFrom to implement the isA method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FELIX-2486) ClassLoaderJavaClassDescription.isA does not work under certain circumstances

2010-07-27 Thread Felix Meschberger (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892779#action_12892779
 ] 

Felix Meschberger commented on FELIX-2486:
--

A concrete situation from the Sling project:

   Bundle B1 has:

   /**
* @scr.component metatype="no" abstract="yes"
* @scr.service interface="javax.servlet.Servlet"
*/
   public abstract class AbstractComponent extends HttpServlet {}

   Bundle B2 has:

   /**
* @scr.component metatype="no"
*/
   public class Component extends AbstractComponent {}

While building the SCR descriptors for B2 the AbstractComponent fails to 
validate the exported interface.

> ClassLoaderJavaClassDescription.isA does not work under certain circumstances
> -
>
> Key: FELIX-2486
> URL: https://issues.apache.org/jira/browse/FELIX-2486
> Project: Felix
>  Issue Type: Bug
>  Components: Maven SCR Plugin
>Affects Versions:  maven-scr-plugin-1.4.4
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For:  maven-scr-plugin-1.4.6
>
>
> Consider two bundles B1 and B2. B1 provides an abstract component AC1. This 
> abstract component declares itself to implement Service S by means of
>@scr.service interface="S"
> No AC1 does not itself implement S but it extends a baseclass which in turn 
> implements S.
> This bundle B1 builds perfectly and the SCR plugin generates the descriptor 
> for the abstract component.
> Now, B2 provides a concrete component CC2 extending AC1. B2 fails to build 
> while trying to generate the SCR descriptor.
> The reason for this is, that while generating descriptor for CC2, the exsting 
> service descriptor for AC1 is validated, particularly the service element. 
> This element is checked in the context of the abstract AC1 component class 
> internally represented by a ClassLoaderJavaClassDescriptor instance. To 
> verify the interface, the isA(String) method is called.
> This is where the problem occurrs: The ClassLoaderJavaClassDescriptor.isA 
> method only considers the interfaces directly implemented by the class but 
> not any interfaces implemented by the parent class. Moreover, this 
> implementation does not allow for classes (as opposed to interfaces) to be 
> used as service interface name.
> The fix is probably to use Class.isAssignableFrom to implement the isA method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (FELIX-2486) ClassLoaderJavaClassDescription.isA does not work under certain circumstances

2010-07-27 Thread Felix Meschberger (JIRA)
ClassLoaderJavaClassDescription.isA does not work under certain circumstances
-

 Key: FELIX-2486
 URL: https://issues.apache.org/jira/browse/FELIX-2486
 Project: Felix
  Issue Type: Bug
  Components: Maven SCR Plugin
Affects Versions:  maven-scr-plugin-1.4.4
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For:  maven-scr-plugin-1.4.6


Consider two bundles B1 and B2. B1 provides an abstract component AC1. This 
abstract component declares itself to implement Service S by means of
   @scr.service interface="S"
No AC1 does not itself implement S but it extends a baseclass which in turn 
implements S.

This bundle B1 builds perfectly and the SCR plugin generates the descriptor for 
the abstract component.

Now, B2 provides a concrete component CC2 extending AC1. B2 fails to build 
while trying to generate the SCR descriptor.

The reason for this is, that while generating descriptor for CC2, the exsting 
service descriptor for AC1 is validated, particularly the service element. This 
element is checked in the context of the abstract AC1 component class 
internally represented by a ClassLoaderJavaClassDescriptor instance. To verify 
the interface, the isA(String) method is called.

This is where the problem occurrs: The ClassLoaderJavaClassDescriptor.isA 
method only considers the interfaces directly implemented by the class but not 
any interfaces implemented by the parent class. Moreover, this implementation 
does not allow for classes (as opposed to interfaces) to be used as service 
interface name.

The fix is probably to use Class.isAssignableFrom to implement the isA method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FELIX-2485) Improve the performance of the manipulator on large files

2010-07-27 Thread Clement Escoffier (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892686#action_12892686
 ] 

Clement Escoffier commented on FELIX-2485:
--

Fixed in trunk

> Improve the performance of the manipulator on large files
> -
>
> Key: FELIX-2485
> URL: https://issues.apache.org/jira/browse/FELIX-2485
> Project: Felix
>  Issue Type: Improvement
>  Components: iPOJO
>Reporter: Clement Escoffier
>Assignee: Clement Escoffier
> Fix For: iPOJO-1.8.0
>
>
> The manipulator manipulates jar files. To achieve this task the jar files is 
> firs tunzipped and then recreated. During this re-jarization, the performance 
> of the class / files copies can be improved by using a buffered copy.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (FELIX-2485) Improve the performance of the manipulator on large files

2010-07-27 Thread Clement Escoffier (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Clement Escoffier resolved FELIX-2485.
--

Resolution: Fixed

> Improve the performance of the manipulator on large files
> -
>
> Key: FELIX-2485
> URL: https://issues.apache.org/jira/browse/FELIX-2485
> Project: Felix
>  Issue Type: Improvement
>  Components: iPOJO
>Reporter: Clement Escoffier
>Assignee: Clement Escoffier
> Fix For: iPOJO-1.8.0
>
>
> The manipulator manipulates jar files. To achieve this task the jar files is 
> firs tunzipped and then recreated. During this re-jarization, the performance 
> of the class / files copies can be improved by using a buffered copy.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (FELIX-2485) Improve the performance of the manipulator on large files

2010-07-27 Thread Clement Escoffier (JIRA)
Improve the performance of the manipulator on large files
-

 Key: FELIX-2485
 URL: https://issues.apache.org/jira/browse/FELIX-2485
 Project: Felix
  Issue Type: Improvement
  Components: iPOJO
Reporter: Clement Escoffier
Assignee: Clement Escoffier
 Fix For: iPOJO-1.8.0


The manipulator manipulates jar files. To achieve this task the jar files is 
firs tunzipped and then recreated. During this re-jarization, the performance 
of the class / files copies can be improved by using a buffered copy.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.