2126 Changes to Web App
I took a look at 2126 changes. I don't have a particular opinion of whether that's good or bad yet, specifically when it comes to context.
It seems that the context was moved to be setup on a per module basis. On one hand that's cool, on the other that means that if you have multiple modules you can start all of them in different contexts at the same time, while that's cool, who does that? Who tests all their apps at the same time with one Tomcat startup?
Like I said I don't hate it, it just caught me by surprise, and was wondering what others though. The potentials are interesting, the problems that can come up are also interesting.
That said, thanks for moving all those crazy fields to IDE setup.
There is still a VM Parameters field, is that still there because you don't want the pane to look empty? Is there a reason that's not with advanced because it seems that it fits within the same context (no pun intended) of what the advanced field is doing.
Thanks for the hard work.
R
Please sign in to leave a comment.
One of the developers here has 4 modules. All webapps. There is a main
webapp that sends users to the other webapps depending on what they are
trying to do. This should suit her fine.
Norris Shelton
Sun Certified Java Programmer
Robert S. Sfeir wrote:
>I took a look at 2126 changes. I don't have a particular opinion of whether that's good or bad yet, specifically when it comes to context.
>
>It seems that the context was moved to be setup on a per module basis. On one hand that's cool, on the other that means that if you have multiple modules you can start all of them in different contexts at the same time, while that's cool, who does that? Who tests all their apps at the same time with one Tomcat startup?
>
>Like I said I don't hate it, it just caught me by surprise, and was wondering what others though. The potentials are interesting, the problems that can come up are also interesting.
>
>That said, thanks for moving all those crazy fields to IDE setup.
>
>There is still a VM Parameters field, is that still there because you don't want the pane to look empty? Is there a reason that's not with advanced because it seems that it fits within the same context (no pun intended) of what the advanced field is doing.
>
>Thanks for the hard work.
>
>R
>
I see, real interesting scenario. Thanks! Now it's clear that this is very useful. I might try to harness it to have a module which contains links to all my portlets, and I can just click on a choice to jump modules from the web browser and test them as needed.
Hum. Cool.
Thanks
R
That is very similar to how hers works. She has a main webapp that is
their "home". This is where user administration occurs, etc. Then the
users can click on various links to access functionality (reports,
scheduled items, etc). These take them to separate applications that
perform the specific operations requested.
The person who originally designed the apps is long gone. I would like
to pick their mind to see what they were thinking.
Norris Shelton
Sun Certified Java Programmer
Robert S. Sfeir wrote:
>I see, real interesting scenario. Thanks! Now it's clear that this is very useful. I might try to harness it to have a module which contains links to all my portlets, and I can just click on a choice to jump modules from the web browser and test them as needed.
>
>Hum. Cool.
>
>Thanks
>R
>
Not sure how this feature works yet since I haven't tried the EAP's since 4.0 was released, but I can see this feature being extremely useful for running something like a JSR-168 portal server and the portlet apps as individual modules. This would allow debugging all the way through the lifecycle of a portal server. You will probably see more of this type of stuff in the future.