[iPOJO] Non-primitive typed properties and constructors
Dear iPOJO developers, I've stumbled upon a situation with fields in components that are annotated with @Property but are of non-primitive and non-String type. iPOJO has the nice feature that you still can provide default values and configurations as Strings and it will try to find an appropriate String constructor for that object. This is done in the Property class [1], starting from line 436 (v1.12.0). However, it will only look for the one constructor with a single String argument and ignore constructors with the Object argument. For example, I often have joda-time Duration and DateTime objects as configurations. Those only have Object constructors which still parse Strings properly. Wouldn't it be a nice feature if the Property class could fall back and try the Object constructor when no String constructor could be found? At the moment I have to make them String properties and parse those into shadow members upon activation, which is a little cumbersome. For my own types, I'd be able to add a String constructor, but since this is an external library, a cannot do that as easily. Please let me know what you think of it and if there are any connected issues I'd have to think of, and I'd happily provide a patch / pull request. Should I open an issue on github or Jira? Kind regards, Benjamin [1] http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.ipojo/1.12.0/org/apache/felix/ipojo/util/Property.java#436
[jira] [Commented] (FELIX-4565) Occasional ArrayIndexOutOfBoundException in iPOJO's ProvidedServiceHandler
[
https://issues.apache.org/jira/browse/FELIX-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258357#comment-14258357
]
Benjamin Debeerst commented on FELIX-4565:
--
Sorry, I am currently not in the office and will be back on January 5, 2015.
Please note, your email has not been forwarded.
In urgent cases please contact:
For issues regarding the WEMAG project: Niels Majer (niels.ma...@younicos.com).
For issues regarding the UKPN project and other topics: Udo Berninger
(udo.bernin...@younicos.com).
Let the fossils rest in peace.
Benjamin Debeerst
Occasional ArrayIndexOutOfBoundException in iPOJO's ProvidedServiceHandler
--
Key: FELIX-4565
URL: https://issues.apache.org/jira/browse/FELIX-4565
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-runtime-1.11.2
Environment: Karaf 2.3.3 / Windows 7 64 bit
Reporter: Benjamin Debeerst
Assignee: Clement Escoffier
Fix For: ipojo-runtime-1.12.1
I have an iPOJO (1.11.2) component using the @ServiceController annotation to
control the service publishing. Most of the time this works perfectly fine,
but occasionally I get an ArrayIndexOutOfBoundsException.
{code}
java.lang.ArrayIndexOutOfBoundsException: 4
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__M_onSet(ProvidedServiceHandler.java:416)[83:org.apache.felix.ipojo:1.11.2]
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.onSet(ProvidedServiceHandler.java)[83:org.apache.felix.ipojo:1.11.2]
at
org.apache.felix.ipojo.InstanceManager.onSet(InstanceManager.java:1401)[83:org.apache.felix.ipojo:1.11.2]
[..] (My own code following, where the service controller
boolean is manipulated)
{code}
Unfortunately I cannot share the consumer code nor reproduce the problem. I
looked into [iPOJOs
code|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.ipojo/1.11.2/org/apache/felix/ipojo/handlers/providedservice/ProvidedServiceHandler.java#416]
to see what's going on, and there we have:
{code}
for (int j = 0; j svc.getProperties().length; j++) { Property prop =
svc.getProperties()[j];
[...]
}
{code}
Which looks like a proper race condition to me, if svc.getProperties()
changes its value in the meantime because of missing synchronizations. I
don't see any synchronizations there, but I also don't know if they would be
appropriate in the first place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4565) Occasional ArrayIndexOutOfBoundException in iPOJO's ProvidedServiceHandler
[
https://issues.apache.org/jira/browse/FELIX-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14119675#comment-14119675
]
Benjamin Debeerst commented on FELIX-4565:
--
Is there a way to see the commits/diff that belonged to this fix?
Occasional ArrayIndexOutOfBoundException in iPOJO's ProvidedServiceHandler
--
Key: FELIX-4565
URL: https://issues.apache.org/jira/browse/FELIX-4565
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-runtime-1.11.2
Environment: Karaf 2.3.3 / Windows 7 64 bit
Reporter: Benjamin Debeerst
Assignee: Clement Escoffier
Fix For: ipojo-runtime-1.12.1
I have an iPOJO (1.11.2) component using the @ServiceController annotation to
control the service publishing. Most of the time this works perfectly fine,
but occasionally I get an ArrayIndexOutOfBoundsException.
{code}
java.lang.ArrayIndexOutOfBoundsException: 4
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__M_onSet(ProvidedServiceHandler.java:416)[83:org.apache.felix.ipojo:1.11.2]
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.onSet(ProvidedServiceHandler.java)[83:org.apache.felix.ipojo:1.11.2]
at
org.apache.felix.ipojo.InstanceManager.onSet(InstanceManager.java:1401)[83:org.apache.felix.ipojo:1.11.2]
[..] (My own code following, where the service controller
boolean is manipulated)
{code}
Unfortunately I cannot share the consumer code nor reproduce the problem. I
looked into [iPOJOs
code|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.ipojo/1.11.2/org/apache/felix/ipojo/handlers/providedservice/ProvidedServiceHandler.java#416]
to see what's going on, and there we have:
{code}
for (int j = 0; j svc.getProperties().length; j++) { Property prop =
svc.getProperties()[j];
[...]
}
{code}
Which looks like a proper race condition to me, if svc.getProperties()
changes its value in the meantime because of missing synchronizations. I
don't see any synchronizations there, but I also don't know if they would be
appropriate in the first place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-4565) Occasional ArrayIndexOutOfBoundException in iPOJO's ProvidedServiceHandler
Benjamin Debeerst created FELIX-4565:
Summary: Occasional ArrayIndexOutOfBoundException in iPOJO's
ProvidedServiceHandler
Key: FELIX-4565
URL: https://issues.apache.org/jira/browse/FELIX-4565
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-runtime-1.11.2
Environment: Karaf 2.3.3 / Windows 7 64 bit
Reporter: Benjamin Debeerst
I have an iPOJO (1.11.2) component using the @ServiceController annotation to
control the service publishing. Most of the time this works perfectly fine, but
occasionally I get an ArrayIndexOutOfBoundsException.
{code}
java.lang.ArrayIndexOutOfBoundsException: 4
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__M_onSet(ProvidedServiceHandler.java:416)[83:org.apache.felix.ipojo:1.11.2]
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.onSet(ProvidedServiceHandler.java)[83:org.apache.felix.ipojo:1.11.2]
at
org.apache.felix.ipojo.InstanceManager.onSet(InstanceManager.java:1401)[83:org.apache.felix.ipojo:1.11.2]
[..] (My own code following, where the service controller
boolean is manipulated)
{code}
Unfortunately I cannot share the consumer code nor reproduce the problem. I
looked into [iPOJOs
code|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.ipojo/1.11.2/org/apache/felix/ipojo/handlers/providedservice/ProvidedServiceHandler.java#416]
to see what's going on, and there we have:
{code}
for (int j = 0; j svc.getProperties().length; j++) { Property prop =
svc.getProperties()[j];
[...]
}
{code}
Which looks like a proper race condition to me, if svc.getProperties() changes
its value in the meantime because of missing synchronizations. I don't see any
synchronizations there, but I also don't know if they would be appropriate in
the first place.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933001#comment-13933001
]
Benjamin Debeerst commented on FELIX-4455:
--
Yes, I recompiled with {{mvn clean package}} each time. I used manipulator
version 1.11.1 (maven plugin), but the same also happenend for 1.10.1.
The project on GitHub is a proper maven project, so it should be possible to
simply build and run it.
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi
container, the component outputs
ComponentWithoutDefaultConstructor: activating!
null
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should
not be possible to create such an invalid object instance. I don't know much
about the reflection APIs or byte code manipulation though.
I have put a sample maven project on GitHub[1], which can be built and
droppped into a fresh Karaf container + iPOJO, which shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1.
[1] https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933001#comment-13933001
]
Benjamin Debeerst edited comment on FELIX-4455 at 3/13/14 8:36 AM:
---
Yes, I recompiled with {{mvn clean package}} each time. I used manipulator
version 1.11.1 (maven plugin), but the same also happenend for 1.10.1.
The [project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample]
is a proper maven project, so it should be possible to simply clone, build and
run it.
was (Author: benjamindebeerst):
Yes, I recompiled with {{mvn clean package}} each time. I used manipulator
version 1.11.1 (maven plugin), but the same also happenend for 1.10.1.
The project on GitHub is a proper maven project, so it should be possible to
simply build and run it.
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi
container, the component outputs
ComponentWithoutDefaultConstructor: activating!
null
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should
not be possible to create such an invalid object instance. I don't know much
about the reflection APIs or byte code manipulation though.
I have put a sample maven project on GitHub[1], which can be built and
droppped into a fresh Karaf container + iPOJO, which shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1.
[1] https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933073#comment-13933073
]
Benjamin Debeerst commented on FELIX-4455:
--
I would expected iPOJO to do either of the following:
# Raise an error (preferrably at manipulation/compile time), that a required
(default) constructor is missing to perform field injection of properties and
referenced services
# Generate the default constructor, but _without skipping field instantiation_.
The last part is the most important thing. I implemented a component with an
internal field, carefully making sure that field can never be null - among
others by instantiating at declaration. But then I throw the component into the
runtime and at once get unexpected NPEs, because in some unknown way, iPOJO
instantiated the class but not it's fields.
If I define a class like this:
{code}
@Component
public class MyClass {
private String internal = Default;
}
{code}
I expect that any fresh class instance has a non-null {{internal}} field -
provided the constructor does not overwrite the default value.
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi
container, the component outputs
ComponentWithoutDefaultConstructor: activating!
null
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should
not be possible to create such an invalid object instance. I don't know much
about the reflection APIs or byte code manipulation though.
I have put a sample maven project on GitHub[1], which can be built and
droppped into a fresh Karaf container + iPOJO, which shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1.
[1] https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933190#comment-13933190
]
Benjamin Debeerst commented on FELIX-4455:
--
I'm good with both solutions.
But:
{quote}
it processes the class as usual: build a new default constructor from scratch,
and doing this, it misses the assignment
{quote}
Isn't this wrong for the usual case as well? I think it should definitely
consider default assignments of fields whenever constructors are generated.
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi
container, the component outputs
ComponentWithoutDefaultConstructor: activating!
null
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should
not be possible to create such an invalid object instance. I don't know much
about the reflection APIs or byte code manipulation though.
I have put a sample maven project on GitHub[1], which can be built and
droppped into a fresh Karaf container + iPOJO, which shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1.
[1] https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933359#comment-13933359
]
Benjamin Debeerst commented on FELIX-4455:
--
Okay, I understand.
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi
container, the component outputs
ComponentWithoutDefaultConstructor: activating!
null
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should
not be possible to create such an invalid object instance. I don't know much
about the reflection APIs or byte code manipulation though.
I have put a sample maven project on GitHub[1], which can be built and
droppped into a fresh Karaf container + iPOJO, which shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1.
[1] https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931583#comment-13931583
]
Benjamin Debeerst commented on FELIX-4455:
--
Then I get {{createInstance - Cannot invoke the constructor (method not
found)}} and {{Cannot create a POJO instance, the POJO constructor cannot be
found}}.
Full stack:
{code}
2014-03-12 10:38:51,156 | ERROR | pool-1-thread-1 | ipojo-constructor
| 91 - com.example.ipojo-constructor - 1.0.0.SNAPSHOT | [ERROR] :
[com.example.ComponentWithoutDefaultConstructor-0] createInstance - Cannot
invoke the constructor (method not found) :
com.example.ComponentWithoutDefaultConstructor.init(org.apache.felix.ipojo.InstanceManager,
null)
java.lang.NoSuchMethodException:
com.example.ComponentWithoutDefaultConstructor.init(org.apache.felix.ipojo.InstanceManager,
null)
at java.lang.Class.getConstructor0(Class.java:2800)[:1.7.0_25]
at java.lang.Class.getDeclaredConstructor(Class.java:2043)[:1.7.0_25]
at
org.apache.felix.ipojo.InstanceManager.createObject(InstanceManager.java:703)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:923)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:156)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:536)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:418)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:179)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:319)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:240)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:312)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:306)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:114
[84:org.apache.felix.ipojo:1.11.1]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_25]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_25]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_25]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_25]
at java.lang.Thread.run(Thread.java:724)[:1.7.0_25]
2014-03-12 10:38:51,156 | ERROR | pool-1-thread-1 | ipojo-constructor
| 91 - com.example.ipojo-constructor -1.0.0.SNAPSHOT | [ERROR]
com.example.ComponentWithoutDefaultConstructor : Cannot create a POJO instance,
the POJO constructor cannot be found
{code}
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi
container, the component outputs
ComponentWithoutDefaultConstructor: activating!
null
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
[jira] [Created] (FELIX-4455) Missing default constructor creates invalid class instances
Benjamin Debeerst created FELIX-4455:
Summary: Missing default constructor creates invalid class
instances
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.11.1, ipojo-manipulator-1.10.1
Reporter: Benjamin Debeerst
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
{code}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
{code}
ComponentWithoutDefaultConstructor: activating!
null
{code}
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put [a sample maven project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample],
which can be built and droppped into a fresh Karaf container + iPOJO, which
shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Debeerst updated FELIX-4455:
-
Description:
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
ComponentWithoutDefaultConstructor: activating!
null
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put a sample maven project on GitHub[1], which can be built and droppped
into a fresh Karaf container + iPOJO, which shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1.
[1] https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample
was:
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
{code}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
{code}
ComponentWithoutDefaultConstructor: activating!
null
{code}
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put [a sample maven project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample],
which can be built and droppped into a fresh Karaf container + iPOJO, which
shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default
[jira] [Updated] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Debeerst updated FELIX-4455:
-
Description:
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
{code}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
{code}
ComponentWithoutDefaultConstructor: activating!
null
{code}
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put [a sample maven project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample],
which can be built and droppped into a fresh Karaf container + iPOJO, which
shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1
was:
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
{code}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
{code}
ComponentWithoutDefaultConstructor: activating!
null
{code}
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put [a sample maven project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample],
which can be built and droppped into a fresh Karaf container + iPOJO, which
shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property
