Hi!
I'm now reviewing the new features from last week and like to get my head
around the new features.
I started alphabetically with the ClassDeactivator stuff and think I missed a
few things.
a.) the ClassDeactivator only contains getDeactivatedClasses()
This might be a problem if one
Another thing: the functionality whether a class is activated or not must be
available in our core-api module.
Otherwise any 3rd party Extension would need to import the core-impl as compile
dependency.
LieGrue,
strub
- Original Message -
From: Mark Struberg strub...@yahoo.de
To:
[
https://issues.apache.org/jira/browse/DELTASPIKE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reopened DELTASPIKE-24:
-
Assignee: Mark Struberg (was: Gerhard Petracek)
a review revealed the following
hi mark,
thx for starting the release-review as well.
@a)
imo that doesn't make sense at all. this mechanism is only for users and
add-ons and won't be used by deltaspike itself.
if something gets deactivated by one of both, it doesn't make sense to
re-activate it again because that would cause
[
https://issues.apache.org/jira/browse/DELTASPIKE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190671#comment-13190671
]
Gerhard Petracek commented on DELTASPIKE-24:
3rd party extensions can use
[
https://issues.apache.org/jira/browse/DELTASPIKE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated DELTASPIKE-24:
Attachment: DELTASPIKE-24.patch
please review this patch.
i know why you did it in this case - but in general: -1 for committing such
large changes in case of an ongoing discussion.
some hours ago i added a suggestion to [1] exactly for such cases.
regards,
gerhard
[1] http://s.apache.org/oo
2012/1/22 strub...@apache.org
Updated Branches:
sorry, didn't know you are still working on that stuff. It was marked as done
and while reviewing I spotted a few areas where I thought we can do this even
better.
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To:
yes - with ongoing discussion i talked about your initial mail (today).
we didn't agree on it.
regards,
gerhard
2012/1/22 Mark Struberg strub...@yahoo.de
sorry, didn't know you are still working on that stuff. It was marked as
done and while reviewing I spotted a few areas where I thought
the whole feature gets moved to the spi package and the helper to an util
sub-package.
otherwise we would have the helper in the api package and all other parts
which are related to it would be in the spi package.
regards,
gerhard
2012/1/22 Mark Struberg strub...@yahoo.de
Hi!
The
Hi!
We are currently in the preparation for a deltaspike-0.1 release.
But this also means that our new features - which are _all_ features now - need
a tight review!
I'd prefer if former Seam3 developers would review the CODI-influenced features
and vice versa in the next week.
I gonna take
+1
imo we should add the corresponding hints to the wiki. e.g. everything
v0.9.x might change fundamentally, if we find a better approach (e.g. based
on feedback provided by the community).
(+ we agreed on release early and often already. some parts which need
further discussions are known
[
https://issues.apache.org/jira/browse/DELTASPIKE-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190799#comment-13190799
]
Gerhard Petracek commented on DELTASPIKE-56:
+1 ! for moving this
Hey @all,
yesterday I had a deeper look at the BeanManagerProvider
implementation and found something that could be improved. I created
DELTASPIKE-56 (see [1]) for this but it turned out that we should
discuss this topic on the mailing list.
I saw that getBeanManager() may return null in some
I'd say we should throw an IllegalStateException.
IllegalStateException and not BeanManagerUnavailableException because I don't
like to have too many custom Exceptions if they don't carry business
information.
This is clearly a non-expected and non-recoverable situation, thus a
+1
But why do we need the manual setBeanManager public at all?
I'll go on and make it protected.
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Monday, January 23, 2012 7:56 AM
Subject: Re:
@mark:
you can ask the person who did it for myfaces codi (see [1]) :)
regards,
gerhard
[1] http://svn.apache.org/viewvc?view=revisionrevision=929170
2012/1/23 Mark Struberg strub...@yahoo.de
+1
But why do we need the manual setBeanManager public at all?
I'll go on and make it
17 matches
Mail list logo
