Feedback on enterprise application development is needed!

JSP-related discussion should be kept here.

EJB-related discussion should be kept here.

Struts-related discussion should be kept here.

Hibernate-related thread

Compilation/deployment-related discussion should be kept here.

Hibernate-related discussion should be kept here.

J2EE servers integration-related discussion should be kept here.

Other frameworks-related discussion should be kept here.

Webservices-related discussion should be kept here.

Erroneous post, please ignore.

HTML authoring-related discussion should be kept here.

Other topics discussion should be kept here.

http://www.intellij.net/forums/thread.jsp?forum=27&thread=155898#4911190

.... is nice, for certain JSPs and ways to write them, but it makes writing JSPs that can't
be reformatted for whatever reason a pain. I believe "correctly" reformatting JSPs - other
than most Java code - is inherently impossible, thus there should be a way to edit JSPs
without the formatter's "smartness" on how to indent lines and where to put the caret.

http://www.jetbrains.net/jira/browse/IDEA-3955

For an example why reformatting a manually formatted JSP file is impossible, please see
this: http://www.jetbrains.net/jira/browse/IDEABKL-3268

Sascha

XML/JSP: Provide tag-coloring depending on namespace

http://www.jetbrains.net/jira/browse/IDEA-5292

All I want is a richer, fully documented, easier to use OpenAPI. One that allows me to build a framework-specific runtime model for the current project, and validate all involved elements -- some sort of "compiler" that knows what the java compiler would let pass, but that would cause an error/problem at runtime. Of course, this isn't limited to java files at all; in fact, most of the runtime model would be built from framework-specific XML files.

In other words, I need to:

- Validate java classes in a framework-specific manner. currently possible with a LocalInspectionTool.
- Validate xml files in a framework-specific manner. currently possible with a LocalInspectionTool.
- Provide custom code completion for java and xml files. currently not possible, AFAIK.
- Provide custom navigation between classes/xml files/etc. currently not currently possible, AFAIK.
- Add more actions to some refactorings. For example, when renaming a Tapestry page class, all references to the class should be renamed too -- and what constitutes references to this class, and how to rename them, should be determined by the plugin. currently not possible, AFAIK

I'm sure I could think of plenty of other things once me or someone else start developing a complex plugin to integrate something like Tapestry or Spring.

J2EE servers integration-related discussion should be kept here.

WebLogic Integration & CMP Ejb problem

http://www.jetbrains.net/jira/browse/IDEA-3953

We're using a web UI toolkit called Bindows.

It is a very rich OO toolkit that allows developing a pure browser
application (no plug-ins needed) that is as rich as desktop apps with a
much simpler and ordered development model of OO controls and event
driven flow (as opposed to page based).

Our application is a classic client-server application with a Bindows
UI, XML-RPC API (for which there is full support in Bindows as well as
SOAP) and on the server Jetty with Apache XML-RPC.

Since Bindows is a JavaScript toolkit, Revamped JavaScript support would
be very useful, with inter-file and OO awareness, as right now I can't
refactor class names, class function names, etc.

The next step would be a UI builder, but I acknowledge it may be too
specialized.

Amnon

We use Jetty as our servlet container (small, simple, fast).

It seems I can't easily integrate with it as a J2EE server so we just
run it as a normal Java app.

Any plans to more easily integrate with it?

Amnon

Well you asked so I'll put it in here and see what happens.

One of the main issues I find difficult to work with with Spring is the sheer
number of xml information you have to put in. Often it's really hard to
see which bean is used by which other bean, or which controller has a parent
of controller x. It's hard to navigate these XML files and see what's happening.

Further sometimes when you refactor, you forget that a bean is no longer
in use, so when you remove it, you also have to remember that it exists in
the spring descriptors and you end up having to chase down startup errors
etc... It would make my work easier if in general when I do refactoring,
if you understood spring well enough that you also recommended that I also
remove that bean, and that particular bean also has other elements relating
to it, and pin point the location graphically, not just highlight the XML.

I use Spring's AOP a little, still learning its value. It would be great
if IDEA somehow helped me along with shortcuts for pointcuts etc...

Thanks
R

Hello Mike,

MA> Webservices-related discussion should be kept here.


Good question. The answer is yes please :)

I think there was a discussion a while back about having even basic web service
generation. In other words integrate, intelligently like idea usually does,
wsdl2java and java2wsdl in a way that would help me create the services quickly
and generate a package for my users which I can deploy to my site so people
can start generating the stubs off of my wsdl and doing their work.

I am not exactly sure how to go about this, since I usually do this manually,
but I know NetBeans has a way to do it, and so does Sun Studio Creator.
I think NetBeans' way of doing it seems easy, but I'm not in Netbeans long
enough to really judge it.

R

I can't say this enough times: I am getting really sick and tired of having
to switch app servers for every run config. If I have a run config right
now, to create a new one, I need to also change the module's default app
server. That needs to be redesigned. I should be able to pick an app server
run config and just run my module with it. Plain and simple. I shouldn't
have to go editing anything else and remembering the different places where
this might make a difference, and when I switch from Tomcat to JBoss or Resin,
then I also lose the jboss config files, which I have to resetup all over
again once I change to another app server. That's really really really really
annoying.

R

http://www.jetbrains.net/jira/browse/IDEA-1651

I have not developed any EJB's, but I have worked on a couple of
projects and have set-up IJ to build .ear files for three projects. IJ
is actually the most flexible of the editors we have here (IJ, JBuilder,
Eclipse and maybe NetBeans). However, there is some room for
improvement. The modules could be a little smarter. If I have a web
module, it's most likely going to be dependent on the EJB module. If I
create a web module and there is an EJB module, it should prompt me.
The same goes for if I create an EJB module and I already have a web module.

EJB 3 support is a must. We are going to deploy JBoss 4.03 as soon as we
can get it tested.

Also, when editing the code, it should make some assumptions. If I am
using an object of type abc and there is an abcEntity (or whatever the
naming convention is), it should give me a way to navigate directly to
the object instead of taking me to the I/F when I CTRL-click it. That
would be sweet.



Mike Aizatsky (JetBrains) wrote:

EJB-related discussion should be kept here.

Struts is the most widely used web framework. Look at the Struts
plugin. It does almost everything that needs to be done. Some cool
stuff would be intentions on form objects. If I create a path (abc.do)
and it does not exist, prompt me to map a new Struts action.


Mike Aizatsky (JetBrains) wrote:

Struts-related discussion should be kept here.

I would love an awesome interface in IntelliJ for working with Spring
projects.

so +5 for that



"Robert Sfeir" <nomail@jetbrains.com> wrote in message
news:7c2dbfd120d518c7994124d4c260@news.jetbrains.com...

Well you asked so I'll put it in here and see what happens.

>

One of the main issues I find difficult to work with with Spring is the
sheer number of xml information you have to put in. Often it's really
hard to see which bean is used by which other bean, or which controller
has a parent of controller x. It's hard to navigate these XML files and
see what's happening.

>

Further sometimes when you refactor, you forget that a bean is no longer
in use, so when you remove it, you also have to remember that it exists in
the spring descriptors and you end up having to chase down startup errors
etc... It would make my work easier if in general when I do refactoring,
if you understood spring well enough that you also recommended that I also
remove that bean, and that particular bean also has other elements
relating to it, and pin point the location graphically, not just highlight
the XML.

>

I use Spring's AOP a little, still learning its value. It would be great
if IDEA somehow helped me along with shortcuts for pointcuts etc...

>

Thanks
R

>

The EJB deployment view really needs to look exactly like the file that
will be build, including manifest files, etc. The hardest thing about
EJB development is configuring it correctly. Right now, we have to
build the .ear, then open it and see if everything is where is should
be. Rebuild, re-open. It takes forever. It would be really nice if I
could change a configuration, then switch to deployment view and see the
difference that it made. Currently only the war has a good deployment
view, but it never gets the manifest when in an .ear.

Mike Aizatsky (JetBrains) wrote:

Compilation/deployment-related discussion should be kept here.

http://www.jetbrains.net/jira/browse/IDEA-4535

Norris Shelton wrote:

The EJB deployment view really needs to look exactly like the file
that will be build, including manifest files, etc. The hardest thing
about EJB development is configuring it correctly. Right now, we have
to build the .ear, then open it and see if everything is where is
should be. Rebuild, re-open. It takes forever. It would be really
nice if I could change a configuration, then switch to deployment view
and see the difference that it made. Currently only the war has a
good deployment view, but it never gets the manifest when in an .ear.

>

Mike Aizatsky (JetBrains) wrote:

>> Compilation/deployment-related discussion should be kept here.

+1, but OpenAPI first must be extended in some ways:

http://www.jetbrains.net/jira/browse/IDEA-624
http://www.jetbrains.net/jira/browse/IDEA-4592
http://www.jetbrains.net/jira/browse/IDEABKL-3176
http://www.jetbrains.net/jira/browse/IDEADEV-2335
http://www.jetbrains.net/jira/browse/IDEADEV-2447
http://www.jetbrains.net/jira/browse/IDEABKL-3482

some of them overlap ;)

http://www.jetbrains.net/jira/browse/IDEA-3941

None of our apps have the style sheet declared in the individual JSPs.
It's usually declared in a single wrapper page. Make the style sheet
property look-up work like the .properties lookup.

Mike Aizatsky (JetBrains) wrote:

JSP-related discussion should be kept here.