You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jacek Laskowski <ja...@laskowski.net.pl> on 2008/12/25 01:19:11 UTC
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
On Thu, Dec 25, 2008 at 1:14 AM, Jacek Laskowski (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/OPENEJB-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659174#action_12659174 ]
>
> Jacek Laskowski commented on OPENEJB-980:
> -----------------------------------------
>
> Created a junit test to spur some discussion on how it should be implemented (and invite more contributors). I don't know how to search for (sub)classes that inherit from the one found (with finder.findAnnotatedClasses(ApplicationException.class)) so I'll follow up on it in dev@openejb mailing list. Everybody's invited.
Hi,
Does anyone know the answer? I'd love fixing it (or providing a
configuration switch to allow for such an extension to EJB3), but
dunno how to find relevant classes. I've got BusinessException.class
(from finder.findAnnotatedClasses(ApplicationException.class)) and am
now wondering how to get at ValueRequiredException.class. Help
appreciated.
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Wed, Jan 7, 2009 at 3:27 AM, David Blevins <da...@visi.com> wrote:
> When shading a package (changing the package name via byte code
> manipulation) you need to update the code in the package (ASM) and the code
> that refers to that package (xbean-finder).
Ah, right. So when shading asm in XBean as a separate module, say
xbean-asm-shaded, asm shading is needed only and whenever asm is
declared as dependency it should be changed to xbean-asm-shaded,
shouldn't it? What was the following for?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<unzip
src="${project.build.directory}/asm-finder-${pom.version}.jar"
dest="${project.build.directory}/classes" />
</tasks>
</configuration>
</execution>
</executions>
</plugin>
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by David Blevins <da...@visi.com>.
On Jan 6, 2009, at 2:48 PM, Jacek Laskowski wrote:
> On Mon, Dec 29, 2008 at 6:50 PM, David Blevins
> <da...@visi.com> wrote:
>
>> That's the way we had it originally, but we ended up shading it to
>> get rid
>> of the ASM dependency:
>>
>> https://issues.apache.org/jira/browse/OPENEJB-892
>>
>> Might be nice to have a shaded version come out of xbean instead of
>> us doing
>> it here.
>
> Why was xbean-finder shaded too?
When shading a package (changing the package name via byte code
manipulation) you need to update the code in the package (ASM) and the
code that refers to that package (xbean-finder).
-David
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Mon, Dec 29, 2008 at 6:50 PM, David Blevins <da...@visi.com> wrote:
> That's the way we had it originally, but we ended up shading it to get rid
> of the ASM dependency:
>
> https://issues.apache.org/jira/browse/OPENEJB-892
>
> Might be nice to have a shaded version come out of xbean instead of us doing
> it here.
Why was xbean-finder shaded too?
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by David Blevins <da...@visi.com>.
On Dec 29, 2008, at 2:33 PM, Jacek Laskowski wrote:
> On Mon, Dec 29, 2008 at 6:50 PM, David Blevins
> <da...@visi.com> wrote:
>
>> Might be nice to have a shaded version come out of xbean instead of
>> us doing
>> it here.
>
> If you tell me what is needed actually I'll go for it. The pom.xml of
> the former deps/asm dir would be enough I guess. The missing piece
> (beside the magic of maven-shade-plugin) is how to execute it during
> the build which I hope finding it out from the pom.xml.
Easiest way would be to copy the deps/asm-finder dir from the 3.1 tag
and update the versions.
-David
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Mon, Dec 29, 2008 at 6:50 PM, David Blevins <da...@visi.com> wrote:
> Might be nice to have a shaded version come out of xbean instead of us doing
> it here.
If you tell me what is needed actually I'll go for it. The pom.xml of
the former deps/asm dir would be enough I guess. The missing piece
(beside the magic of maven-shade-plugin) is how to execute it during
the build which I hope finding it out from the pom.xml.
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by David Blevins <da...@visi.com>.
On Dec 29, 2008, at 4:39 AM, Jacek Laskowski wrote:
> They're nowhere to be found (they're in repo directory which
> was removed about a month ago) and I'm stuck how to proceed.
I think you mean the deps/ dir. We can just add the deps/asm-finder/
pom.xml back in and re-shade the new xbean-finder version with asm.
> I think
> the only option is to remove the shaded asm/xbean modules from the
> dependencies and rely on regular xbean modules again. Any issues with
> it?
That's the way we had it originally, but we ended up shading it to get
rid of the ASM dependency:
https://issues.apache.org/jira/browse/OPENEJB-892
Might be nice to have a shaded version come out of xbean instead of us
doing it here.
-David
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Mon, Dec 29, 2008 at 5:36 AM, David Blevins <da...@visi.com> wrote:
> Just commented on that JIRA issue. The long and short is that it would be a
> non-compliant feature. That's fine, we have plenty of them, but it would
> have to be off by default.
Thanks. That reflects my sentiments as well.
> As far as how to implement it, we'd need to beef up the ClassFinder so that
> it can find subclasses of other classes. From there it would be easier to
> implement though still might have holes as you aren't guaranteed to find all
> subclasses of a class if those classes are packaged in other archives.
I've already changed ClassFinder and committed it to XBean
3.5-SNAPSHOT. It's not on as openejb relies on shaded asm/xbean
modules. They're nowhere to be found (they're in repo directory which
was removed about a month ago) and I'm stuck how to proceed. I think
the only option is to remove the shaded asm/xbean modules from the
dependencies and rely on regular xbean modules again. Any issues with
it?
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by David Blevins <da...@visi.com>.
On Feb 13, 2009, at 3:55 PM, Jacek Laskowski wrote:
> On Sat, Feb 14, 2009 at 12:19 AM, David Blevins <david.blevins@visi.com
> > wrote:
>
>> So, Geoff, congratulations! You helped change the very spec itself
>> for the
>> better. Thanks again for taking the time to file the JIRA. You
>> never know
>> where these things can lead :)
>
> So how can we go about it? Should we stop changing XBean to
> automagically do what the annotation will do with @Inherited? What's
> the change then so OpenEJB obeys the rule?
Not sure. Seems we might have to do all the work on our end
considering something declared as an application exception via the
deployment descriptor will also need to have the inheritance enforced.
Initially it might really be as simple as checking if the exception is
listed in the DeploymentInfo like we do now, and then just check for
the super class of that exception if the answer comes back no.
That wouldn't support the inheritance=false case, but it's not really
critical initially IMHO.
-David
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not
being inherited
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Sat, Feb 14, 2009 at 12:19 AM, David Blevins <da...@visi.com> wrote:
> So, Geoff, congratulations! You helped change the very spec itself for the
> better. Thanks again for taking the time to file the JIRA. You never know
> where these things can lead :)
So how can we go about it? Should we stop changing XBean to
automagically do what the annotation will do with @Inherited? What's
the change then so OpenEJB obeys the rule?
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by David Blevins <da...@visi.com>.
On Dec 28, 2008, at 8:36 PM, David Blevins wrote:
> The long and short is that it would be a non-compliant feature.
> That's fine, we have plenty of them, but it would have to be off by
> default.
Update on this one. I brought this up to the group and proposed a new
'inherited' attribute that could be set to true or false. The group
consensus so far is that in 3.1 the @ApplicationException annotation
will be treated as inherited by default with the option to shut that
off on a case by case basis.
So, Geoff, congratulations! You helped change the very spec itself
for the better. Thanks again for taking the time to file the JIRA.
You never know where these things can lead :)
-David
Re: [jira] Commented: (OPENEJB-980) @ApplicationException is not being inherited
Posted by David Blevins <da...@visi.com>.
On Dec 24, 2008, at 4:19 PM, Jacek Laskowski wrote:
> On Thu, Dec 25, 2008 at 1:14 AM, Jacek Laskowski (JIRA) <jira@apache.org
> > wrote:
>>
>> [ https://issues.apache.org/jira/browse/OPENEJB-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659174
>> #action_12659174 ]
>>
>> Jacek Laskowski commented on OPENEJB-980:
>> -----------------------------------------
>>
>> Created a junit test to spur some discussion on how it should be
>> implemented (and invite more contributors). I don't know how to
>> search for (sub)classes that inherit from the one found (with
>> finder.findAnnotatedClasses(ApplicationException.class)) so I'll
>> follow up on it in dev@openejb mailing list. Everybody's invited.
>
> Hi,
>
> Does anyone know the answer? I'd love fixing it (or providing a
> configuration switch to allow for such an extension to EJB3), but
> dunno how to find relevant classes. I've got BusinessException.class
> (from finder.findAnnotatedClasses(ApplicationException.class)) and am
> now wondering how to get at ValueRequiredException.class. Help
> appreciated.
Just commented on that JIRA issue. The long and short is that it
would be a non-compliant feature. That's fine, we have plenty of
them, but it would have to be off by default.
As far as how to implement it, we'd need to beef up the ClassFinder so
that it can find subclasses of other classes. From there it would be
easier to implement though still might have holes as you aren't
guaranteed to find all subclasses of a class if those classes are
packaged in other archives.
-David