chaning seam version

[whitty69]

I am running into a problem with the tools 3.Alpha and seam 2.1 in ganymede.

Due to a problem I found in seam 2.1.0CR1 I am currently getting nightly builds quite regularly to test the fix.

After I download, add and change my project to use the new seam version I can't get the tools to update the ear libraries to the new version. I have tried to remove the older seam versions from the list, Manually replace files in eracontents folder and I have looked for any config files containing a reference to the older version and if possible manually updating the path. None of this helped.

Is there something I can do that will fix this problem?

I would expect this to be done when I hit the apply button after changing the seam-runtime in the project properties.

Thanks in advance.
Peter

[maxandersen]

We don't manage your jars, we just give you an initial start.

Updating the jars and apropriate config files you have is the way to update to a new version of any framework (not just Seam ;)

[whitty69]

This isn't about 'Managing my Jars', it's all about managing jars referenced by plugins and referenced runtimes.

Again:
The project was pointing to the jboss-seam.jar of the original seam runtime after it was generated using the tools. Is was not possible to fix it without actually removing the old folder and then copying the files into the EarContant folder manually as well as manually removing references from the workbench.xml file.

As far as I see it; and I don't mind being wrong; if a tool/plugin maintains references to jar's in a runtime folder and said plugin lets you update/change the runtime, then said plugin should also update it's references to jars in runtime.

Manually editing config files of eclipse isn't really normal behaviour.

Last but not least: I think the JBOss tools are great and I wouldn't like to be without them ;-)

Thanks.
Peter.

[maxandersen]

hmmm....we try to avoid create projects that points "deeply" into the plugins/runtimes - exactly to avoid this issue.

If we do that that is a bug.

Which classpath container points to a jboss-seam.jar not inside your project ?

Which config files are you talking about ?

[whitty69]

The config file from eclipse was the workbench.xml.

I have an ear, ejb and my war projects which were generated using the eclipse seam project tool. the ejb and war have their dynamically generated web app libraries classpath entries. these pointed to the jboss-seam.jar in the seam runtime folder which I used during generation.

This was fixed by copying the jboss-seam.jar to the EarContent folder of the ear project, removing the old runtime and references in the eclipse workspaces workbench.xml file.

After all that and restarting eclipse, the web app libraries folder pointed to the ear' EarContent folder.

I may have done something wrong in the past that caused this sate I am not 100% sure.

Thanks.
Peter.

[maxandersen]

which workbench.xml are you editing ? What is the full path to it ?

There should be *zero* reason to adjust this file.

[whitty69]

I was stuck for solutions so i did a file search for all files in my workspace that contained the path entry I wanted to get rid of and found it in the workbench.xml situated in [path to workspace]\'.metadata\.plugins\org.eclipse.ui.workbench'. I changed the entries to the new path and that was all.

I was trying only to find where it was stuck and don't make a habit of changing these kind of files: In fact having to change it was what prompted me to post the topic here.

[maxandersen]

what exactly did you find in that workbench.xml ?

Nothing of this should be related to you updating the jars?

[whitty69]

I found entries like this:

<input factoryID="org.eclipse.jdt.ui.ClassFileEditorInputFactory" org.eclipse.jdt.ui.ClassFileIdentifier="=lineManager/D:\/javatools\/jboss-seam-2.1.1-SNAPSHOT\/lib\/jboss-seam.jar<org.jboss.seam.servlet(SeamFilter.class"/>

and

<editor factoryID="org.eclipse.jdt.ui.ClassFileEditorInputFactory" id="org.eclipse.jdt.ui.ClassFileEditor" org.eclipse.jdt.ui.ClassFileIdentifier="=lineManager/D:\/javatools\/jboss-seam-2.1.1-SNAPSHOT\/lib\/jboss-seam.jar<org.jboss.seam.web(ExceptionFilter.class"/>


As I said, I was getting desperate and looking for any 'possible' cause/solution. I don't even know if this made a difference.

I do not make a habit of editing such files; but as I have previously said, I could not get the reference to jboss-seam.jar file to change even after removing all references to the old seam version from my working environment. There was no direct way of editing it because it was referenced dynamically. As the saying goes:Desperate times lead to desperate measures

I do not know if this really a bug or just me being to dumb to switch a runtime. Whichever of the two(probably the latter you are probably thinking) it should as far as I am concerned be possible to change the seam runtime and have the default file be replaced in the project. As far as I am aware, the seam-ge update does just that when run from the command line.

Cheers.
Peter.

[maxandersen]

Those two entries is just the cache/memory for the workbench of you opening SeamFilter.class and ExceptionFilter.class in the editor area so it would open these when you restart eclipse.

These have nothing to do with your projects understanding on whic libs it is using.

[whitty69]

do you have any idea then as to where this 'ghost' reference was stored?

I searched through all project files(incl hidden and system) to find any containing the incorrect path and found none either in my workspace or the eclipse application folders. Does the seam plugin store information anywhere outside of those two environments or in a binary files of any kind?

any way: I have managed somehow to get it to work as I said above. Thanks for all your advice and help.

[maxandersen]

could it be that something was holding on to the old jars ? i.e. a running jboss's classloader ?

[whitty69]

no jboss wasn't running.

I actually did the runtime firts thing before anything else this morning.

I really searched everywhere I could think of to see where it came from.
It wasn't added as library, user library or any other manual means of attaching jars to the project. It was refernced dynamically via some strange logic. May something in the eclipse Web Tool Kit.

Again thanks.

[rob.stryker]

As I understand it, workbench.xml only is in charge of recording which files, views, editors, etc are open upon startup, or which ones were opened upon close.

Basically, the workbench.xml is just saying "the file opened is x, and it is found in jar y".

If you open your workspace, close *all* editors, and then re-open your workspace, you should find that those entries in your workbench.xml no longer exist.

I suspect strongly that the linemanager portion of the entries is received from the classpath of the project when you opened the file.