[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100363#comment-14100363 ] Romain Manni-Bucau commented on DELTASPIKE-647: --- we should enhance and use commons-proxy imho since we own the code and don't need any license check AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-687) Let users disable Query Method Expressions
[ https://issues.apache.org/jira/browse/DELTASPIKE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100419#comment-14100419 ] Thomas Hug commented on DELTASPIKE-687: --- Never mind, found your message on the user list (http://mail-archives.apache.org/mod_mbox/deltaspike-users/201408.mbox/%3C53EFE6FF.2080104%40gmail.com%3E) DS Data currently doesn't collect delegates, so the assumtion is that if it's not a @Query, not a concrete method and not a method expression, it's a delegate. It would be cleaner to actually collect all delegates during startup and then get to correct method type instead of disabling method expressions. Will give it a look. Let users disable Query Method Expressions -- Key: DELTASPIKE-687 URL: https://issues.apache.org/jira/browse/DELTASPIKE-687 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Affects Versions: 1.0.1 Reporter: Dominik Obermaier Assignee: Thomas Hug While Query Method Expressions are very useful, it would be great to disable this feature globally or on a per-method basis if this automatic implementation is not desired. The following approaches could be worth investigating: - Disable the Query Method Expressions feature globally with the apache-deltaspike.properties - Introduce a new annotation to mark methods for getting ignored by the Query Method Expression Parser -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-687) Let users disable Query Method Expressions
[ https://issues.apache.org/jira/browse/DELTASPIKE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100481#comment-14100481 ] Thomas Hug commented on DELTASPIKE-687: --- You can also go the other way around and change the method expression prefix (see http://deltaspike.apache.org/data#method-prefix) instead of your delegate prefix. Although this might look weird too. I was digging already into Data internals with my earlier description. It basically drills down to delegates not being recognized in all cases and the execution takes the method expression path instead of ending up in the delegate. So... Actually it's a bug :-) Let users disable Query Method Expressions -- Key: DELTASPIKE-687 URL: https://issues.apache.org/jira/browse/DELTASPIKE-687 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Affects Versions: 1.0.1 Reporter: Dominik Obermaier Assignee: Thomas Hug While Query Method Expressions are very useful, it would be great to disable this feature globally or on a per-method basis if this automatic implementation is not desired. The following approaches could be worth investigating: - Disable the Query Method Expressions feature globally with the apache-deltaspike.properties - Introduce a new annotation to mark methods for getting ignored by the Query Method Expression Parser -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release of Apache DeltaSpike 1.0.2
+1 Em 8/17/14, 10:15, Gerhard Petracek escreveu: Hi, I was running the needed tasks to get the 10th release of Apache DeltaSpike out. The artifacts are deployed to Nexus [1] (and [2]). The tag is available at [3] and will get pushed to the ASF repository once the vote passed. Please take a look at the 1.0.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachedeltaspike-1013 [2] https://repository.apache.org/content/repositories/orgapachedeltaspike-1013/org/apache/deltaspike/deltaspike-project/1.0.2/deltaspike-project-1.0.2-source-release.zip [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.0.2 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
[jira] [Created] (DELTASPIKE-691) Weld 2.x support
Alexandr Smirnov created DELTASPIKE-691: --- Summary: Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Smirnov updated DELTASPIKE-691: Component/s: Data-Module Environment: arquillian-weld-se-embedded-1.1 unit test Affects Version/s: 1.0.1 Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100667#comment-14100667 ] Gerhard Petracek commented on DELTASPIKE-647: - only +1 if we can shade it in and there is a clear advantage over the owb-proxies which are highly optimized. AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100681#comment-14100681 ] Thomas Andraschko commented on DELTASPIKE-647: -- Can we reuse the owb-proxy logic? Whats the advantage of plain asm vs commons-poxy-asm? AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-660) OSGi support for DeltaSpike Data and its dependencies
[ https://issues.apache.org/jira/browse/DELTASPIKE-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100695#comment-14100695 ] Ioan Eugen Stan commented on DELTASPIKE-660: I've tried this, the osgi headers are ok. You can try this patch with the pax-cdi samples feature from [1] . More details here https://groups.google.com/forum/#!topic/ops4j/-TwZmxYqY8Q [1] https://github.com/ops4j/org.ops4j.pax.cdi/tree/PAXCDI-108 OSGi support for DeltaSpike Data and its dependencies - Key: DELTASPIKE-660 URL: https://issues.apache.org/jira/browse/DELTASPIKE-660 Project: DeltaSpike Issue Type: New Feature Affects Versions: 1.0.0 Reporter: Harald Wellmann Assignee: Charles Moulliard Goal: Users can work with DeltaSpike Data in OSGi applications, using Pax CDI. Some DeltaSpike modules already have OSGi manifest headers (see DELTASPIKE-210), others don't. There is a working test case in Pax CDI which wraps DeltaSpike JARs on the fly, adding all missing headers: https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/itest/src/it/itest-cdi10/src/test/java/org/ops4j/pax/cdi/test/TransactionalTest.java -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100697#comment-14100697 ] Gerhard Petracek commented on DELTASPIKE-647: - i haven't looked at the details so far, however, owb-proxies should be more to the point we need (including interceptors). AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-691. - Resolution: Won't Fix please file an issue for weld. all needed methods are part of javax.enterprise.inject.spi.Bean since cdi 1.0. since cdi 1.1 some methods were extracted to javax.enterprise.inject.spi.BeanAttributes which is the base-interface for javax.enterprise.inject.spi.Bean. Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [data] dto and isNew
So isNew is broken for openjpa and one should live with it? This will
basically make deltaspike data not usable because you kinda need merge to
work properly...
On 17 June 2014 19:11, Thomas Hug thomas@gmail.com wrote:
Actually the simple mapper is doing that since the last update, just to
find the entity based on the PK so you receive an attached entity (also
valid for chained mappers, when injected)
BTW, if you need something different in save, you can still define your own
reusable repository methods:
http://deltaspike.apache.org/data.html#extensions
(just don't name it save ;-)
On Tue, Jun 17, 2014 at 4:41 PM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Yes, but that s not an issue since you can get it injected
Le lundi 16 juin 2014, Karl Kildén karl.kil...@gmail.com a écrit :
But then I need to use the entityManager in the mapper or am I missing
something?
On 16 June 2014 11:17, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Yes you need to merge it but the responsability is yours (user) IMO.
Le 16 juin 2014 09:56, Karl Kildén karl.kil...@gmail.com a écrit
:
Hrmm maybe I mixed things up now.
If you have a relationship to another pre existing entity can it be
detached when you save? All I am really looking for is the groupId
to
be
updated but maybe JPA can't determine this in a good way. And
updating
the
entity itself is solved by including it as an argument to the
mapper,
all
though I am a wondering if that solution is optimal.
Romain and Thomas, your comments on the best way to handle
relationships
in
the Mapper? If the entity has not changed then you can just use
user.getGroup() but as I described previously this is wrong when the
group
has changed.
On 16 June 2014 10:34, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Cause mapping can be done through several transactions (think
jaxrs)
so
it
would be wrong. PersistenceUtil has some good things to gey id or
null
if
new but IIRC some impl are broken.
Le 16 juin 2014 09:31, Thomas Andraschko
andraschko.tho...@gmail.com
a
écrit :
Why don't we use entityManager#contains instead of checking the
ID?
2014-06-16 10:22 GMT+02:00 Karl Kildén karl.kil...@gmail.com:
Hi,
On could argue that the real problem is that the algorithm
that
decides
if
it should be a save or persist. It uses some portable way of
deciding
this
that requires the entity to be managed.
That algorithm could be improved in each project.
@Override
@RequiresTransaction
public E save(E entity)
{
if (context.isNew(entity))
{
entityManager().persist(entity);
return entity;
}
return entityManager().merge(entity);
}
I would say that overriding this method would solve
EntityExistsException
in a cleaner way. For this project I have no natural keys
only
generated
long so it would be a cheap and easy way to fix it... This is
fully
sufficient for me:
@Override
@RequiresTransaction
public E save(E entity)
{
BaseEntity e = (BaseEntity) entity;
if (e.getId == 0)
{
entityManager().persist(entity);
return entity;
}
return entityManager().merge(entity);
}
If not overridden then what happens if the group has changed
in
my
example,
you are supposed to use entityManager and find it?
Maybe the API should provide something like the utility
method I
proposed
then... I will explain it a little better. All you need to do
is
inject
the
groupMapper or whatever mapper you need. To get the group if
it
changed
you
simply call fetch with a new Group instance, the DTO with the
new
information and the groupMapper. Why send in new group
instance?
Well
one
could also send in Group.class and use a reflection to create
a
new
group
if needed. But new Group() vs Group.class I actually prefer
the
first
because it avoids reflection. Because the new Group() argument
also
allows
for getClass() the entityManager has all the info required
except
the
id
but that is no problem since we also send in the mapper with
the
handy
#getPrimaryKey
method.
Group g = fetch (new Group(), user.getGroup(), groupMapper);
public Entity, Dto Entity fetch(Entity entity, Dto dto,
SimpleQueryInOutMapperBaseEntity, Dto
Re: DeltaSpike docs plan
Thanks, once more, John, +1 to consider this a binding vote. Btw, Do you need any help with CMS? Em 8/17/14, 18:29, John D. Ament escreveu: Also, I created a JIRA ticket to cover the donation. All commits related to the donation should include DELTASPIKE-690 in the commit message, for tracking purposes, ideally. The JIRA can be found at [1]. - John [1]: https://issues.apache.org/jira/browse/DELTASPIKE-690 On Sun, Aug 17, 2014 at 5:26 PM, John D. Ament john.d.am...@gmail.com wrote: All, Just wondering, can we consider this a binding vote? Just want to make sure I have the right links in place. John On Mon, Aug 11, 2014 at 12:04 PM, John D. Ament john.d.am...@gmail.com wrote: +1 as well. I can push this folder in to master after 1.0.2 is release, so as to not mess up Gerhard. On Mon, Aug 11, 2014 at 11:56 AM, Jason Porter lightguard...@gmail.com wrote: +1 from me. — Sent from Mailbox On Mon, Aug 11, 2014 at 9:54 AM, Rafael Benevides benevi...@redhat.com wrote: I ran the PoC and I do really thing that it works for DeltaSpike (considering that there's no restriction on CMS). Can I give a green sign to Michelle start the docs refactoring (as planned) using Asciidoctor? I think that she and her team can work on its own repository and them move it in one big shot once that we have all requirements setup. Wdyt ? Em 8/11/14, 8:17, John D. Ament escreveu: @mark That's what I based it on actually. On Mon, Aug 11, 2014 at 12:44 AM, Mark Struberg strub...@yahoo.de wrote: You can look at batchee. Romain configured offline doc (with markdown, but could also be asciidoc) and mvn scm-publish LieGrue, strub On Sat, 9/8/14, John D. Ament john.d.am...@gmail.com wrote: Subject: Re: DeltaSpike docs plan To: deltaspike dev@deltaspike.apache.org Date: Saturday, 9 August, 2014, 15:54 Actually, from digging around their code, might have an easier solution, so long as everyone agrees. I have a small POC setup here: https://github.com/johnament/deltaspike/commit/402becc0e450e551570107a1661d39e9eb6a43cb I setup a local VM w/ a SVN repo to test it out. Basically, we can generate the asciidoc locally using mvn site, then run mvn site-deploy to move the rendered files to staging. Once done, login to CMS and promote to prod. The only change would be to get infra to switch our script to use the shell option. It does put the rendering process on whoever is writing the docs, but since it's using the java plugin and jruby, nothing should need to be downloaded separately to machines. On Fri, Aug 8, 2014 at 1:55 PM, Rafael Benevides benevi...@redhat.com wrote: I remember that someone said that CMS already supports remote repositories. Can't we start by having this documents moved soon while we discuss about the asciidoc rendering ? Em 8/8/14, 10:53, Gerhard Petracek escreveu: @john: the infra team is usually not the blocking part (if there is no significant technical issue and they don't get a new heavy part to maintain). regards, gerhard 2014-08-08 15:37 GMT+02:00 John D. Ament john.d.am...@gmail.com: I think we need to convince infra@ that these are all must needed features. From looking at the code behind CMS, it would appear that it's the one calling markdown based on the imports in our files. Unless we want to do something crazy like render asciidoc in markdown format, then hand that over for rendering.. Still would need to convince that pulling from git over the svn site is ideal as well. John On Fri, Aug 8, 2014 at 9:03 AM, Rafael Benevides benevi...@redhat.com wrote: Em 8/8/14, 6:49, Pete Muir escreveu: On 7 Aug 2014, at 18:47, Rafael Benevides benevi...@redhat.com wrote: Before we have a deal with Michelle's team about these content changes, I think we should close the two other definitions: - docs location: move to deltaspike sources, create a new repository, other? +1 to move to sources +1 to move to sources and -docs format: markdown or asciidoc +1 for asciidoc. +1 for asciidoc However I believe we also need agree on: * add support for asciidoc to Apache CMS * add support for importing external repo to Apache CMS so that the docs can still be build as part of the website. From what people have said in the past, both are possible, if someone (e.g. Rafael ;-) can spend a couple of days doing it. Definitely I would like to help/handle that. I believe that both (asciidoc support + importing external repo) will bring open doors to
Re: [data] dto and isNew
well we have to make it working with openjpa by default. We should
also introduce an interface the entity can implement to say if it is
new or not (testing business id typically)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-08-18 18:08 GMT+02:00 Karl Kildén karl.kil...@gmail.com:
So isNew is broken for openjpa and one should live with it? This will
basically make deltaspike data not usable because you kinda need merge to
work properly...
On 17 June 2014 19:11, Thomas Hug thomas@gmail.com wrote:
Actually the simple mapper is doing that since the last update, just to
find the entity based on the PK so you receive an attached entity (also
valid for chained mappers, when injected)
BTW, if you need something different in save, you can still define your own
reusable repository methods:
http://deltaspike.apache.org/data.html#extensions
(just don't name it save ;-)
On Tue, Jun 17, 2014 at 4:41 PM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Yes, but that s not an issue since you can get it injected
Le lundi 16 juin 2014, Karl Kildén karl.kil...@gmail.com a écrit :
But then I need to use the entityManager in the mapper or am I missing
something?
On 16 June 2014 11:17, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Yes you need to merge it but the responsability is yours (user) IMO.
Le 16 juin 2014 09:56, Karl Kildén karl.kil...@gmail.com a écrit
:
Hrmm maybe I mixed things up now.
If you have a relationship to another pre existing entity can it be
detached when you save? All I am really looking for is the groupId
to
be
updated but maybe JPA can't determine this in a good way. And
updating
the
entity itself is solved by including it as an argument to the
mapper,
all
though I am a wondering if that solution is optimal.
Romain and Thomas, your comments on the best way to handle
relationships
in
the Mapper? If the entity has not changed then you can just use
user.getGroup() but as I described previously this is wrong when the
group
has changed.
On 16 June 2014 10:34, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Cause mapping can be done through several transactions (think
jaxrs)
so
it
would be wrong. PersistenceUtil has some good things to gey id or
null
if
new but IIRC some impl are broken.
Le 16 juin 2014 09:31, Thomas Andraschko
andraschko.tho...@gmail.com
a
écrit :
Why don't we use entityManager#contains instead of checking the
ID?
2014-06-16 10:22 GMT+02:00 Karl Kildén karl.kil...@gmail.com:
Hi,
On could argue that the real problem is that the algorithm
that
decides
if
it should be a save or persist. It uses some portable way of
deciding
this
that requires the entity to be managed.
That algorithm could be improved in each project.
@Override
@RequiresTransaction
public E save(E entity)
{
if (context.isNew(entity))
{
entityManager().persist(entity);
return entity;
}
return entityManager().merge(entity);
}
I would say that overriding this method would solve
EntityExistsException
in a cleaner way. For this project I have no natural keys
only
generated
long so it would be a cheap and easy way to fix it... This is
fully
sufficient for me:
@Override
@RequiresTransaction
public E save(E entity)
{
BaseEntity e = (BaseEntity) entity;
if (e.getId == 0)
{
entityManager().persist(entity);
return entity;
}
return entityManager().merge(entity);
}
If not overridden then what happens if the group has changed
in
my
example,
you are supposed to use entityManager and find it?
Maybe the API should provide something like the utility
method I
proposed
then... I will explain it a little better. All you need to do
is
inject
the
groupMapper or whatever mapper you need. To get the group if
it
changed
you
simply call fetch with a new Group instance, the DTO with the
new
information and the groupMapper. Why send in new group
instance?
Well
one
could also send in Group.class and use a reflection to create
a
new
group
if needed. But new Group() vs Group.class I actually prefer
the
first
because it avoids reflection. Because the new Group() argument
also
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101007#comment-14101007 ] Romain Manni-Bucau commented on DELTASPIKE-647: --- @Gerhard: do we shade javassist today? I'm -1 to shade it since we'll depend on [proxy] API but not the impl (asm, javassist, cglib...). This will be up to the user (and one advantage is to not import 10 proxying libs!). asm code is pretty much the same as OWB one (actually the same as openejb). -1000 to reimplement it again in DS which is not the place to get proxies (once again [proxy] is the place - if it is not enough for DS need we can enhance it pretty quickly) AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101081#comment-14101081 ] Gerhard Petracek commented on DELTASPIKE-647: - no we don't shade javassist. if the only choice which really works is commons-proxy-asm, i don't see a reason why we should add an abstraction-layer which just can be used with one impl. AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101084#comment-14101084 ] Romain Manni-Bucau commented on DELTASPIKE-647: --- cause that's not the only solution (cglib should work) and cause this feature is blur enough to work in most cases and be enough for some part of users. AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101100#comment-14101100 ] Mark Struberg commented on DELTASPIKE-647: -- I'm for commons-proxy or an own ASM impl as well. We cannot use the OWB code 1:1 at least. In OWB we do much more optimizations which are not usable in a more generic way. E.g. we cache the created class directly in our ProducerT resp BeanT. When you create dynamic classes you always have to solve the ugly problem with serialization. And this is why we store it directly in our BeanT (or a wrapper for 3rd party Beans). This allows us to do much more optimizations which work even if you have a managed bean + 3 different producer methods (using different qualifiers) for the same bean class. But in DS we just cannot use this trick as we are not so deep inside the container. Thus we need to use much more generic proxies... AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101109#comment-14101109 ] Gerhard Petracek commented on DELTASPIKE-647: - if we can't use those optimizations, we have to think about the interceptors topic. if there is also no difference, i'm ok with commons-proxy. AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101157#comment-14101157 ] Alexandr Smirnov commented on DELTASPIKE-691: - But this exception mean, that libraries are not binary compatible. And the reason is that deltaspike depends on geronimo-jcdi_1.0_spec which is not binary compatible with cdi-api 1.1/1.2 from Jboss. Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101174#comment-14101174 ] Gerhard Petracek commented on DELTASPIKE-691: - it should be compatible which is the case for most parts since our whole test-suite gets executed with weld 1.x and 2.x - see https://builds.apache.org/view/A-D/view/DeltaSpike/ we could do the same trick as for jsf 2.2. please create a new task for a detailed check (compatibility with cdi 1.1 and not weld2). Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-692) workaround for tests which don't use optional classes
Gerhard Petracek created DELTASPIKE-692: --- Summary: workaround for tests which don't use optional classes Key: DELTASPIKE-692 URL: https://issues.apache.org/jira/browse/DELTASPIKE-692 Project: DeltaSpike Issue Type: Improvement Components: Scheduler, Tests Affects Versions: 1.0.2 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.0.3 Attachments: DELTASPIKE-692.patch some ee-servers have issues with optional classes. org.quartz.Job is optional and not needed by the current tests. however, we have to add this class, to avoid that such servers fail. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-691. - Resolution: Not a Problem Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reopened DELTASPIKE-691: - Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101264#comment-14101264 ] Alexandr Smirnov commented on DELTASPIKE-691: - Exactly, I mean that. You compile (using OWB profile) against the api (geronimo cdi api 1.0) which is not binary compatible with the another api (jboss cdi api 1.2). That is why you have another profile in parent-code pom to run test in Weld. Unfortunately (for me) only the code compiled with default profile is deployed to maven central. So I have to build deltaspike myself with activated Weld profile and deploy it to our local repository. No problem, I can do it. But I would like to create issue on this point, so we have artifacts in maven central built with Weld profile activated. Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101285#comment-14101285 ] Alexandr Smirnov commented on DELTASPIKE-691: - https://issues.apache.org/jira/browse/DELTASPIKE-693 Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-693) Deploy the deltaspike version built with Weld maven profile into maven central
[ https://issues.apache.org/jira/browse/DELTASPIKE-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Smirnov updated DELTASPIKE-693: Description: Only deltaspike built with a default profile OWB deployed to maven central. Weld users have to build deltaspike they self (with activated Weld profile ). was: Only deltaspike built with a default profile OWN deployed to maven central. Weld users have to build deltaspike they self (with activated Weld profile ). Deploy the deltaspike version built with Weld maven profile into maven central -- Key: DELTASPIKE-693 URL: https://issues.apache.org/jira/browse/DELTASPIKE-693 Project: DeltaSpike Issue Type: Wish Components: Build Affects Versions: 1.0.1, 1.0.2 Reporter: Alexandr Smirnov Only deltaspike built with a default profile OWB deployed to maven central. Weld users have to build deltaspike they self (with activated Weld profile ). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101364#comment-14101364 ] Gerhard Petracek commented on DELTASPIKE-691: - please check your setup again. i added a partial bean (- BeanBuilder#create gets triggered) to https://github.com/os890/ee6-ds-demo/tree/in-memory and deployed it to wildfly 8.1 (which uses weld2) and everything works fine (i dropped the local maven repo to check that everything gets used from maven-central). Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-693) Deploy the deltaspike version built with Weld maven profile into maven central
[ https://issues.apache.org/jira/browse/DELTASPIKE-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101368#comment-14101368 ] Gerhard Petracek commented on DELTASPIKE-693: - please check your setup again. i deployed https://github.com/os890/ee6-ds-demo/tree/in-memory to wildfly 8.1 and everything works fine (i dropped the local maven repo to ensure that everything gets used from maven-central). Deploy the deltaspike version built with Weld maven profile into maven central -- Key: DELTASPIKE-693 URL: https://issues.apache.org/jira/browse/DELTASPIKE-693 Project: DeltaSpike Issue Type: Wish Components: Build Affects Versions: 1.0.1, 1.0.2 Reporter: Alexandr Smirnov Only deltaspike built with a default profile OWB deployed to maven central. Weld users have to build deltaspike they self (with activated Weld profile ). -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release of Apache DeltaSpike 1.0.2
+1— Sent from Mailbox On Sun, Aug 17, 2014 at 7:16 AM, Gerhard Petracek gpetra...@apache.org wrote: Hi, I was running the needed tasks to get the 10th release of Apache DeltaSpike out. The artifacts are deployed to Nexus [1] (and [2]). The tag is available at [3] and will get pushed to the ASF repository once the vote passed. Please take a look at the 1.0.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachedeltaspike-1013 [2] https://repository.apache.org/content/repositories/orgapachedeltaspike-1013/org/apache/deltaspike/deltaspike-project/1.0.2/deltaspike-project-1.0.2-source-release.zip [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.0.2 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of Apache DeltaSpike 1.0.2
+1 On Mon, Aug 18, 2014 at 7:31 PM, Jason Porter lightguard...@gmail.com wrote: +1— Sent from Mailbox On Sun, Aug 17, 2014 at 7:16 AM, Gerhard Petracek gpetra...@apache.org wrote: Hi, I was running the needed tasks to get the 10th release of Apache DeltaSpike out. The artifacts are deployed to Nexus [1] (and [2]). The tag is available at [3] and will get pushed to the ASF repository once the vote passed. Please take a look at the 1.0.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachedeltaspike-1013 [2] https://repository.apache.org/content/repositories/orgapachedeltaspike-1013/org/apache/deltaspike/deltaspike-project/1.0.2/deltaspike-project-1.0.2-source-release.zip [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.0.2 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
[jira] [Commented] (DELTASPIKE-691) Weld 2.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101873#comment-14101873 ] Alexandr Smirnov commented on DELTASPIKE-691: - You are right, sorry. And thank you for your help. I appreciate it so much. The wrong dependency in my case comes from myfaces-api 2.3, not from deltaspike. myfaces has geronimo-jcdi_1.0_spec in compiled scope. I have to manually extract it. I will write to myfaces project. Weld 2.x support Key: DELTASPIKE-691 URL: https://issues.apache.org/jira/browse/DELTASPIKE-691 Project: DeltaSpike Issue Type: Wish Components: Data-Module Affects Versions: 1.0.1 Environment: arquillian-weld-se-embedded-1.1 unit test Reporter: Alexandr Smirnov java.lang.IncompatibleClassChangeError: Class org.apache.deltaspike.core.util.bean.ImmutablePassivationCapableBean does not implement the requested interface javax.enterprise.inject.spi.BeanAttributes at org.jboss.weld.bean.attributes.ExternalBeanAttributesFactory.validateStereotypes(ExternalBeanAttributesFactory.java:75) When trying to start with Weld 2.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DELTASPIKE-693) Deploy the deltaspike version built with Weld maven profile into maven central
[ https://issues.apache.org/jira/browse/DELTASPIKE-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Smirnov closed DELTASPIKE-693. --- Deploy the deltaspike version built with Weld maven profile into maven central -- Key: DELTASPIKE-693 URL: https://issues.apache.org/jira/browse/DELTASPIKE-693 Project: DeltaSpike Issue Type: Wish Components: Build Affects Versions: 1.0.1, 1.0.2 Reporter: Alexandr Smirnov Only deltaspike built with a default profile OWB deployed to maven central. Weld users have to build deltaspike they self (with activated Weld profile ). -- This message was sent by Atlassian JIRA (v6.2#6252)
