+1 only once.
On Sun, Feb 27, 2011 at 7:36 PM, Mark Struberg wrote:
> hi folks!
>
> Since I'm tired of waiting for my EE stack to startup because each and
> every library implements it's own classpath scanner over and over again, I
> thought about introducing a proposal for a framework which al
I think it should be enough if the classscanner implementation itself shades
any such 3rd party jar into a inner dependency.
My main focus currently is to design the API flexible enough to allow all
necessary use cases to work.
LieGrue,
strub
--- On Sun, 2/27/11, Jan-Kees van Andel wrote:
> F
[
https://issues.apache.org/jira/browse/OWB-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf updated OWB-534:
---
Attachment: OWB-534.zip
The example application.
Shows the bug (on default)
and has (as describ
[
https://issues.apache.org/jira/browse/OWB-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1291#comment-1291
]
Matthias Weßendorf commented on OWB-534:
Attached is a simple example. It uses my "ab
[
https://issues.apache.org/jira/browse/OWB-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1288#comment-1288
]
Matthias Weßendorf commented on OWB-534:
Using a simple DAO (all in one class - no ab
[
https://issues.apache.org/jira/browse/OWB-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1287#comment-1287
]
Matthias Weßendorf commented on OWB-534:
Stack trace:
Caused by: java.lang.NullPoin
Injection of @PersistenceContext does not work with abstract/base classes
-
Key: OWB-534
URL: https://issues.apache.org/jira/browse/OWB-534
Project: OpenWebBeans
Issue T
+1 for repackaging it instead of an additional dependency.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/2/27 Jan-Kees van Andel
> +1, although I think Jar hell is a real
+1, although I think Jar hell is a real issue. Think about libraries like
cglib, asm or commons-*** and the pain they sometimes cause.
But we can easily work around it, for example by packaging all
using-frameworks as uber-jars and renaming
the "org.apache.commons.classscan" packages to something
Hi Jan-Kees!
Txs for this info!
Of course, I think the downside of getting another dependency to myfaces would
highly be outvalued by the benefit we'd gain from it :)
LieGrue,
strub
--- On Sun, 2/27/11, Jan-Kees van Andel wrote:
> From: Jan-Kees van Andel
> Subject: Re: Classpath Scanner pr
Hey Mark,
About the JSR proposal. I've actually been talking to some Oracle folks
about this idea some (like 3?) years ago. They didn't really like it, since
the classpath is only a VM implementation detail.
I proposed it, because back then there were already rumours about module
systems and writi
Hi Ivan!
Yes, I already prepared for the addition of a xbean-finder based ClassScanner
implementation. But since I didn't reach David yesterday and I personally don't
know xbean-finder well enough, I just started hacking on a scannotation based
one (similar to the one we use in OpenWebBeans).
Totally agree the idea, in Geronimo, it is definitely an issue, as many
components need to scan the target application, and we are trying to improve
this, e,g. In the xbean-finder, we use some filter to limit the scanning
scope. Also, we hope to have a sharable annotation scanning tool, and open a
hi folks!
Since I'm tired of waiting for my EE stack to startup because each and every
library implements it's own classpath scanner over and over again, I thought
about introducing a proposal for a framework which allows to first register
'ScanJobs' and then just does all the necessary classpa
14 matches
Mail list logo
