JBoss tools does not put impl classes on classpath for AS7

[henk53]

Using JBoss Tools 3.2m4 (isn't released, but somehow came with server runtime discovery in Eclipse 3.7sr1) and JBoss AS 7.02, it seems the implementation classes are not put on the classpath anymore.

Depending on the role of the developer, this is both a blessing and a curse.

It's a blessing, since 'ordinary' application developers can now not mistakingly depend on implementation classes.

It's a curse, since more experienced developers typically fix problems by stepping into the framework to see where exactly something goes wrong (one of the MAJOR benefits of open source software).

Without those classes present on the classpath, it will be very troublesome to get the right versions and then to attach the right source-code. This problem is like the source code that was missing in the JBoss AS 6 source download, but worse. Now not only the source code is missing, but the implementation is missing as well (in the IDE).

As a small example, suppose I expect there's a problem in say class ActionListenerImpl (because I see this at a crucial point in my stacktrace). I try to open this class using ctrl-shift-t.

With the JBoss AS 6 runtime, it shows that this class is in jsf-impl-2.0.3-b05.jar. When I open the class there's no source-attachment, but I have a lead that I can use to hunt the Internet for the source attachment.

With the JBoss AS 7 runtime, nothing...

Just nothing...

Nothing shows up...

So now I have to unpack all jars from the binary distribution of JBoss AS, do grepping on the filesystem, when I find the jar, copy it to my project, exclude it from source control, add it to the classpath, and -then- I can start hunting the Internet for the source attachment.

Basically, with every version of JBoss AS, it seems to get more difficult to easily step through the source code that makes up JBoss AS. Am I perhaps one of the very few developers who actually likes to step into the framework's source-code instead of treating it as a black-box?

Would it be possible to have an option somewhere so the runtime actually puts the implementation classes on the IDE's classpath?

[maxandersen]

I hear you

There is a war going on between the two world views of "full access/user responsible for not using the right API" vs "limited acces/platform responsible for not exposing the wrong API".

The problem is that the current notion in java world of runtimes and tooling doesn't provide a good mechanism to serve both sides well.

Personally i'm on your side of wishing transparency before limited access but also understand users are baffled/annoyed when we tell them they used internal API without realizing it.

I hope we can find a way to easily make easy debugging and introspection possible.

More suggestions and reason/arguments for both sides are very much welcome.

[henk53]

Max Rydahl Andersen wrote:

I hear you

More suggestions and reason/arguments for both sides are very much welcome.

Thanks for your understanding response!

It's maybe interesting to notice that both the JRE classpath container in Eclipse and the Glassfish one do expose the implementation classes.

I would say a good compromise is to install the hiding classpath container by default, but give users the option to either install the full one separately, or (maybe even better) let the user switch between limited and full by means of a property on the container.

Not sure if the last thing is easy to implement in Eclipse though. Classpath containers do have property pages when right clicking on them in e.g. the project explorer view, but they typically cause an other container to be used in .classpath (e.g. system default JRE vs a specific one).

At any length, that location would be the first place where I think users would look to change the behavior of a given container.

One step further, if JBoss tools knows about a limiting (API only) and full classpath container, it could potentially validate the code to see if classes are used in the project that are only in the full container and not in the limiting one or otherwise on the classpath. A warning could be flagged for that situation.

[henk53]

Max Rydahl Andersen wrote:

More suggestions and reason/arguments for both sides are very much welcome.

M5 has been released now, but it seems there has been no progress on this issue, has there?

Any chance you guys can still do something here before the GA?

It would really be a shame of the entire discussion we had over the past years to make source attachments easier, and now this finally seems to happen there is almost nothing left to attach the source to.

[maxandersen]

We will have something for GA on this.

Note, adding everything is not the solution.

p.s. all of AS7 jars are now mavenized so if you use gradle, ivy or mvn their auto-download source will actually work now

[snjeza]

Henk,

Could you try the following:

- install JBoss Tools 3.3.0M5

- install the JBoss Tools Source Lookup feature from http://anonsvn.jboss.org/repos/jbosstools/workspace/snjeza/org.jboss.tools.as.sourcelookup.updatesite/

- install the JBoss AS 7.x server and configure it

- double click the server in the Servers View and click the Open launch configuration link

- select the Source tab

- click the Add button and select the JBoss AS Source Container

- start the JBoss AS 7 server in the debug mode

- set a breakpoint somewhere or suspend some thread in the Debug view

The JBoss Tools Source Lookup plugin will download (if necessary) and open source file when the JVM faces the breakpoint or you suspend the thread.

This will work for JBoss AS 6.1 and JBoss AS 7.x servers.

Your suggestions are welcome.

[snjeza]

Henk,

You may want to take a look at https://community.jboss.org/community/tools/blog/2012/01/24/jboss-source-lookup

[henk53]

Snjezana Peco wrote:

Henk,

You may want to take a look at https://community.jboss.org/community/tools/blog/2012/01/24/jboss-source-lookup

Sorry for the late reply, I totally missed the previous post. Some of the things sound very good Especially the ability to see sources for those classes/jars that the server runtime providers can't/won't/didn't include.

If you forgive me for being too critical, there are maybe two things that might be slightly improved. The first one is about this point: "set up the central JBoss Maven repository as explained in"

Personally I like to avoid Maven as much as possible. None of my projects use Maven. I either just use the Eclipse builders and/or Ant. If a tool uses Maven under the cover, then that's an implementation detail I don't mind, but if I have to explicitly install and configure Maven then that's quite another thing. Maybe it's a personal awkward thing of me, but there might be more users who don't want to be explicitly confronted with Maven (I think surveys from Eclipse and Zeroturnaround revealed only ~50 of Java developers use Maven).

Another things concerns this point "you can add a Server Runtime container to the project's classpath (optional)". To me it was not 100% clear what this meant. Isn't this already possible without JBoss Tools, or does it mean that a source container can be added to the project's classpath?

The final piece of the puzzle is opening implementation classes that aren't included by default in the server runtime using ctrl-t and actually compiling your own code against those. I know that "normally" you shouldn't do this (for portable Java EE apps), but it can be very important for bug hunting and temporary workarounds.

Anyway, I'll try the feature tomorrow. Thanks again!

[henk53]

Max Rydahl Andersen wrote:

Note, adding everything is not the solution.

Max, just wondering what you exactly mean by this. Do you mean adding everything by default to the standard JBoss server runtime, or providing an optional JBoss server runtime that includes everything?

As mentioned, I agree that it might be a good idea to only provide API classes in the standard runtime (shield most developers from accidentally linking to implementation classes).

But if you mean the second thing, I don't see how not adding everything would not be a solution for advanced developers who simply need everything?

Currently the AS 6 runtime includes almost everything, but you guys have forgotten a few jars here and there and indeed me and some of the other developers on my team have run into problems missing exactly those (if I remember correctly, it was e.g. the timerservice in common/deploy/ and some Tomcat related classes). The workaround is to add those jars to your project's classpath, but don't export them to the deployment. This allows you to do ctrl-t, call hierarchies, etc. It's a bit of a hassle, as basically you do want to keep those jars out of version control, so you have uncommitted changes in your project all the time and have to redo this at every location you work.

The point is that there are always cases developers run into. I find it hard to think of any jar or class in JBoss that should always and permanently be 'hidden'.

[maxandersen]

henk de boer wrote:

Max Rydahl Andersen wrote:

Note, adding everything is not the solution.

Max, just wondering what you exactly mean by this. Do you mean adding everything by default to the standard JBoss server runtime, or providing an optional JBoss server runtime that includes everything?

"Adding everything by default" is what I mean and I also mean that we can't have a optional runtime that includes everything.

Simply because "include everything" => broken classpath.

As mentioned, I agree that it might be a good idea to only provide API classes in the standard runtime (shield most developers from accidentally linking to implementation classes).

But if you mean the second thing, I don't see how not adding everything would not be a solution for advanced developers who simply need everything?

Which jar with duplicate classes do you want to have to win ?

Currently the AS 6 runtime includes almost everything, but you guys have forgotten a few jars here and there and indeed me and some of the other developers on my team have run into problems missing exactly those (if I remember correctly, it was e.g. the timerservice in common/deploy/ and some Tomcat related classes). The workaround is to add those jars to your project's classpath, but don't export them to the deployment. This allows you to do ctrl-t, call hierarchies, etc. It's a bit of a hassle, as basically you do want to keep those jars out of version control, so you have uncommitted changes in your project all the time and have to redo this at every location you work.

Open jiras for jars we are missing and we'll add (especially for pre-AS7 ones where its almost "random" anyway

The point is that there are always cases developers run into. I find it hard to think of any jar or class in JBoss that should always and permanently be 'hidden'.

I agree - but adding jars onto the classpath is unfortunately not just about Ctrl+T working but it also affect junit launches and other things.

[henk53]

Max Rydahl Andersen wrote:

"Adding everything by default" is what I mean and I also mean that we can't have a optional runtime that includes everything.

Simply because "include everything" => broken classpath.

Hmmm, okay. I think I'm slowly starting to understand the issue (I'm a somewhat older guy, so those things take some time with me ). The point is thus that in reality there is a class loader hierarchy in place, where classes are shielded from each other. But Eclipse has no such notion, and will simply put everything on a flat classpath when "everything is included", right?

I agree - but adding jars onto the classpath is unfortunately not just about Ctrl+T working but it also affect junit launches and other things.

I understand this now. Thanks for pointing it out, Max!

What we maybe need is a system for decoupling class discovery (Ctrl+T) and introspection (type hierarchy, references, etc) from presence on the classpath. This is never going to be an easy thing of course and should maybe be solved at the Eclipse/JDT core. I'm imagining a system where a library container/server runtime has a large collection of classes in jars that it manages, with only a subset of those being put on the classpath by default and where the user can pick and choose additional jars.

In the case of Jboss, the server runtime would indeed only put the API classes on the classpath, but it would participate in Ctrl-T searches and respond to a query for say "FacesContextImpl" (even though that particular class isn't on the classpath). Double clicking on the search result would open the file with source visible, and if "link with editor" is enabled I would see the containing jar in the project explorer. Right clicking on said jar would enable me to directly add the jar to the classpath.

Could that theoretically work?

[henk53]

Just wondering, is there already some progress here?

[maxandersen]

Classpath containers doesn't work like you suggest unfortunately - they can't "extend" Ctrl+T without adding stuff to the actual classpath.

But:

Henk, go to Eclipse preferences, type "default classpath entries", locate JBoss 7.1 runtime and add modules/**/*.jar and you have all the jars you want.

Its not perfect (since its currently not possible to default to this) but we've provided this "loophole" until we get a way to avoid duplicate jars.

[henk53]

Max Rydahl Andersen wrote:

Classpath containers doesn't work like you suggest unfortunately - they can't "extend" Ctrl+T without adding stuff to the actual classpath.

Indeed, so what I meant that this should be addresssed with the core Eclipse JDT guys. Of course that won't be trivial, but if more people think that this is at least a good idea it might be worth a shot.

I'll try your workaround, thanks again!

[maxandersen]

I just realized there actually is a way to add non-classpath entries to the java search - PDE does this, so we should be able too also.

I've opened jira on https://issues.jboss.org/browse/JBIDE-11970 but this will not happen before next dev cycle.

thanks for persisting and making me remember this possible hack