to my jboss-app.xml, the second entry (not the first!) will show up in the 'Service Archives' box on the JBoss Server tab, with the warnings 'Service Archive should not be empty' and 'META-INF/myapp-jms-destination-service.xml is not a valid Service Archive.
I think both should be ignored - they are valid, & jboss does pick up the configuration correctly... (Leaving just one entry works correctly)
Another (unrelated) minor issue: when creating new Web/EJB/EAR modules for JBoss 3.2.x, the preselected version of the deployment descriptors is set to JBoss 4.
Otherwise, It-Works-Quite-Well-For-Me (tm)! thanks for a nice plugin! ;)
to my jboss-app.xml, the second entry (not the first!) will show up in the 'Service Archives' box on the JBoss Server tab, with the warnings 'Service Archive should not be empty' and 'META-INF/myapp-jms-destination-service.xml is not a valid Service Archive.
I think both should be ignored - they are valid, & jboss does pick up the configuration correctly... (Leaving just one entry works correctly)
The module element is used to deploy complete service archives (zipped directories with extension .sar), not for plain XML files. Therefore the message '... is not a valid Service Archive' is absolutely correct.
I have to check why the first one doesn't show up with the same message, there seems to be something wrong. (The message 'Service Archive should not be empty' is related to the first one, therefore it doesn't show up in the list.)
You can add plain XML files in the EJB Modules Settings, panel Deployment Descriptors. Additional XML files are treated by IDEA as Deployment Descriptors of type 'Additional Resource'.
Another (unrelated) minor issue: when creating new Web/EJB/EAR modules for JBoss 3.2.x, the preselected version of the deployment descriptors is set to JBoss 4.
Yes, I know. Unfortunately IDEA doesn't let me do something here. But at least it remembers your change as the default for the next module. :(
Slight correction: both error messages are related to the second entry, the first entry is completely ignored.
I can reproduce the different handling of two entries by first writing a module entry manually to jboss-app.xml and then duplicate that entry and change the service name. Is this approximately what you did?
(If I enter both entries manually then both get ignored by the plugin - it's a timing issue based on slow typing...)
After closing and reopening the project both entries should show up in the service list. Can you confirm that?
The module element is used to deploy complete service archives (zipped directories with extension .sar), not for plain XML files. Therefore the message '... is not a valid Service Archive' is absolutely correct. You can add plain XML files in the EJB Modules Settings, panel. Deployment Descriptors. Additional XML files are treated by IDEA as Deployment Descriptors of type 'Additional Resource'.
Well, it may be an unorthodox (or at the very least un(der)documented) use of the element, but it is the only way I can get JBoss to
pickup these 'service' definitions. (In my case, one creates a JMS
topic, the other a datasource)
Btw - they're configured in the EAR deployment descriptor as 'Additional
Resource's similar to what you describe. If I configure them in the way
you describe (with the EJB module) they're never noticed by JBoss.
If there's a 'correct' way of achieving this, I'd be glad to hear of it.
In the meantime, this does work rather well - it basically mimics the
directory structure in /deploy, but inside an .ear...
>>]]> descriptors is set to JBoss 4.
Yes, I know. Unfortunately IDEA doesn't let me do something here.
Ah, I C. Pity, but it's more of a gotcha than a problem, I guess.
> writing a module entry manually to jboss-app.xml and then duplicate > that entry and change the service name. Is this approximately what > you did?
More or less - the deployment descriptors are actually generated by an ant script. In fact, the whole project was built using Ant, but for debugging I needed to create the EAR module. That's when this issue popped up.
> After closing and reopening the project both entries should show up > in the service list. Can you confirm that?
No, the behaviour didn't change - I initially tried restarting IDEA a few times to get rid of the 'error message' for the second entry, but that didn't work. First one seemed to stay 'ok' - or at least didn't give an error message ;) However, that was in the 2242 build - in the 2244 build this seems to be fixed a single entry now also gives the error-message... (don't know how that's possible - I didn't change the plugin. Did create new caches, though)
Martin Fuhrer wrote:
I think I found a small SAR-ish issue with JBoss 3.2.5 as well: when I
add entries like this:
META-INF/myapp-hsql-ds.xml META-INF/myapp-jms-destination-service.xml ]]>
to my jboss-app.xml, the second entry (not the first!) will show up in
the 'Service Archives' box on the JBoss Server tab, with the warnings
'Service Archive should not be empty' and
'META-INF/myapp-jms-destination-service.xml is not a valid Service Archive.
I think both should be ignored - they are valid, & jboss does pick up
the configuration correctly...
(Leaving just one entry works correctly)
Another (unrelated) minor issue: when creating new Web/EJB/EAR modules
for JBoss 3.2.x, the preselected version of the deployment descriptors
is set to JBoss 4.
Otherwise, It-Works-Quite-Well-For-Me (tm)!
thanks for a nice plugin! ;)
Regards,
Edwin
The module element is used to deploy complete service archives (zipped directories with extension .sar), not for plain XML files. Therefore the message '... is not a valid Service Archive' is absolutely correct.
I have to check why the first one doesn't show up with the same message, there seems to be something wrong. (The message 'Service Archive should not be empty' is related to the first one, therefore it doesn't show up in the list.)
You can add plain XML files in the EJB Modules Settings, panel Deployment Descriptors. Additional XML files are treated by IDEA as Deployment Descriptors of type 'Additional Resource'.
Yes, I know. Unfortunately IDEA doesn't let me do something here. But at least it remembers your change as the default for the next module. :(
Slight correction: both error messages are related to the second entry, the first entry is completely ignored.
I can reproduce the different handling of two entries by first writing a module entry manually to jboss-app.xml and then duplicate that entry and change the service name. Is this approximately what you did?
(If I enter both entries manually then both get ignored by the plugin - it's a timing issue based on slow typing...)
After closing and reopening the project both entries should show up in the service list. Can you confirm that?
Martin Fuhrer wrote:
Well, it may be an unorthodox (or at the very least un(der)documented)
use of the element, but it is the only way I can get JBoss to pickup these 'service' definitions. (In my case, one creates a JMS topic, the other a datasource) Btw - they're configured in the EAR deployment descriptor as 'Additional Resource's similar to what you describe. If I configure them in the way you describe (with the EJB module) they're never noticed by JBoss. If there's a 'correct' way of achieving this, I'd be glad to hear of it. In the meantime, this does work rather well - it basically mimics the directory structure in /deploy, but inside an .ear... >>]]> descriptors is set to JBoss 4.
Ah, I C. Pity, but it's more of a gotcha than a problem, I guess.
> writing a module entry manually to jboss-app.xml and then duplicate
> that entry and change the service name. Is this approximately what
> you did?
More or less - the deployment descriptors are actually generated by an
ant script. In fact, the whole project was built using Ant, but for
debugging I needed to create the EAR module. That's when this issue
popped up.
> After closing and reopening the project both entries should show up
> in the service list. Can you confirm that?
No, the behaviour didn't change - I initially tried restarting IDEA a
few times to get rid of the 'error message' for the second entry, but
that didn't work. First one seemed to stay 'ok' - or at least didn't
give an error message ;)
However, that was in the 2242 build - in the 2244 build this seems to be
fixed a single entry now also gives the error-message... (don't know
how that's possible - I didn't change the plugin. Did create new caches,
though)
CU,
Edwin