[JBoss JIRA] Created: (JBAS-5646) @EJB does not work in servlet
by Rick Vederman (JIRA)
@EJB does not work in servlet
-----------------------------
Key: JBAS-5646
URL: http://jira.jboss.com/jira/browse/JBAS-5646
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.CR1
Environment: JBOSS trunk revision 74818 on both Windows 2000SP4 and Linux Fedora 8 (64-bit) with 32-bit JDK 1.5.0.14 (on both Windows and Linux)
Reporter: Rick Vederman
This was not an issue in 5.0.0.Beta4. I pulled the trunk to get the fix for another bug and this cropped up. Basically, I declare an interface POJO and prefix it with @Remote. I then declare a stateless EJB which implements that interface and prefix it with @Stateless. Finally, I create a servlet and prefix an attribute declaration of the interface type using @EJB. None of the annotations have any parameters.
See the Forum reference for the log dump (first post) as well as the java code (third post). I apologize if this is a duplicate...I see some other issues which look close, but I was not sure.
Work-around:
Add 'mappedName="EJB3Test1/CoverageWCBean/remote"' to the @EJB annotation in the servlet. This gets me past the "java.lang.IllegalStateException: Resolution should not happen via injection container" problem, but then this problem crops up:
23:41:28,159 ERROR [FieldBeanProperty] failed to set value jboss.j2ee:ear=EJB3Test.ear,jar=EJB3TestEJB.jar,name=CoverageWCBean,service=EJB3 on field private ic.poc.wc.CoverageWC EJB3TestServlet.wc
java.lang.IllegalArgumentException
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
This problem is then worked around by setting CallByValue=true in the Naming service (jboss-service.xml) and then it works (EJBTHREE-983 might be related to this problem). Note that I tested this in GlassFish and it all works fine with just the annotations without any parameters as it did under 5.0.0.Beta4.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[JBoss JIRA] Created: (JBAS-4028) nosuchmethoderror
by tony anecito (JIRA)
nosuchmethoderror
-----------------
Key: JBAS-4028
URL: http://jira.jboss.com/jira/browse/JBAS-4028
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Windows 2000 Professional JDK 1.6.0
Reporter: tony anecito
21:10:46,843 ERROR [[/invoker]] Exception sending context initialized event to l
istener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigure
Listener
java.lang.NoSuchMethodError: javax.servlet.ServletContext.getContextPath()Ljava/
lang/String;
at com.sun.faces.config.WebConfiguration.getServletContextName(WebConfig
uration.java:191)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[JBoss JIRA] Created: (JBAS-5325) Out of Memory error: Cannot start new thread. SpyJMSException
by aneesh vasanthan (JIRA)
Out of Memory error: Cannot start new thread. SpyJMSException
-------------------------------------------------------------
Key: JBAS-5325
URL: http://jira.jboss.com/jira/browse/JBAS-5325
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.2RC1
Environment: Windows, jboss 4.0.2
Reporter: aneesh vasanthan
Priority: Critical
Hi ,
we are using jboss4.0.2 as our application server. we are facing a major problem in jms connection. It happens very frequently. After a restart will be fine for sometime n again it crashes.The exception trace is as shown below. expecting ur eteemed reply.
Application server: jboss 4.0.2
Application deployed in : jboss\server\default
2008-03-18 15:03:48,328 DEBUG [org.apache.coyote.tomcat5.CoyoteAdapter] Requested cookie session id is 639091685F164A589266650426F9B40F
2008-03-18 15:14:02,234 DEBUG [org.apache.coyote.tomcat5.CoyoteAdapter] Requested cookie session id is 639091685F164A589266650426F9B40F
2008-03-18 19:22:29,234 WARN [org.jboss.mq.Connection] Connection failure:
org.jboss.mq.SpyJMSException: Exiting on unexpected error in read task; - nested throwable: (java.lang.reflect.UndeclaredThrowableException)
at org.jboss.mq.Connection.asynchFailure(Connection.java:429)
at org.jboss.mq.il.uil2.UILClientILService.asynchFailure(UILClientILService.java:147)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleStop(SocketManager.java:398)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.run(SocketManager.java:342)
at java.lang.Thread.run(Thread.java:536)
Caused by: java.lang.reflect.UndeclaredThrowableException
... 4 more
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start(Native Method)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.addThread(PooledExecutor.java:520)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.execute(PooledExecutor.java:880)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.run(SocketManager.java:296)
... 1 more
2008-03-18 19:27:29,234 WARN [org.jboss.mq.Connection] Connection failure:
org.jboss.mq.SpyJMSException: Connection Failed; - nested throwable: (java.io.IOException: ping timeout.)
at org.jboss.mq.Connection.asynchFailure(Connection.java:429)
at org.jboss.mq.Connection$PingTask.run(Connection.java:1378)
at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364)
at java.lang.Thread.run(Thread.java:536)
Caused by: java.io.IOException: ping timeout.
at org.jboss.mq.Connection$PingTask.run(Connection.java:1370)
... 2 more
2008-03-18 19:32:29,250 WARN [org.jboss.mq.Connection] Connection failure:
org.jboss.mq.SpyJMSException: Connection Failed; - nested throwable: (java.io.IOException: ping timeout.)
at org.jboss.mq.Connection.asynchFailure(Connection.java:429)
at org.jboss.mq.Connection$PingTask.run(Connection.java:1378)
at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364)
at java.lang.Thread.run(Thread.java:536)
Caused by: java.io.IOException: ping timeout.
at org.jboss.mq.Connection$PingTask.run(Connection.java:1370)
... 2 more
2008-03-18 19:37:29,265 WARN [org.jboss.mq.Connection] Connection failure:
org.jboss.mq.SpyJMSException: Connection Failed; - nested throwable: (java.io.IOException: ping timeout.)
at org.jboss.mq.Connection.asynchFailure(Connection.java:429)
at org.jboss.mq.Connection$PingTask.run(Connection.java:1378)
at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364)
at java.lang.Thread.run(Thread.java:536)
Caused by: java.io.IOException: ping timeout.
at org.jboss.mq.Connection$PingTask.run(Connection.java:1370)
... 2 more
2008-03-18 19:42:29,281 WARN [org.jboss.mq.Connection] Connection failure:
org.jboss.mq.SpyJMSException: Connection Failed; - nested throwable: (java.io.IOException: ping timeout.)
at org.jboss.mq.Connection.asynchFailure(Connection.java:429)
at org.jboss.mq.Connection$PingTask.run(Connection.java:1378)
at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364)
at java.lang.Thread.run(Thread.java:536)
Caused by: java.io.IOException: ping timeout.
at org.jboss.mq.Connection$PingTask.run(Connection.java:1370)
... 2 more
2008-03-18 19:47:29,296 WARN [org.jboss.mq.Connection] Connection failure:
org.jboss.mq.SpyJMSException: Connection Failed; - nested throwable: (java.io.IOException: ping timeout.)
at org.jboss.mq.Connection.asynchFailure(Connection.java:429)
at org.jboss.mq.Connection$PingTask.run(Connection.java:1378)
at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364)
at java.lang.Thread.run(Thread.java:536)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[JBoss JIRA] Created: (JBAS-5576) Internationalisation (i18n) patch for web- and jmx-console
by Sean Flanigan (JIRA)
Internationalisation (i18n) patch for web- and jmx-console
----------------------------------------------------------
Key: JBAS-5576
URL: http://jira.jboss.com/jira/browse/JBAS-5576
Project: JBoss Application Server
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: JMX/Web Console
Affects Versions: JBossAS-5.0.0.CR1
Environment: Developed and tested under Red Hat Enterprise Linux 5.1
Reporter: Sean Flanigan
Assigned To: Darran Lofthouse
Attachments: jboss_console_i18n.patch
G'day all,
I'm part of the Red Hat internationalisation team, and I've been working on internationalising the JBoss consoles (web and JMX, not the new admin-console). I was initially working against EAP 4.3, but we decided that we should be following the standard practice of starting with jboss.org, and later putting it into jboss.com releases (like the Fedora->Red Hat process). So I have ported my i18n work to the consoles in AS 5. Fortunately for me, these consoles haven't changed much in years.
I am attaching a patch with my internationalisation changes. I'm still waiting on some actual translations from the localisation team, but in the meantime I have generated a simple pseudolocalisation for the locale 'xxx'. If you run the consoles and select the 'xxx' locale, any _static_ text which is still in English but doesn't have lots of "x"s is probably an internationalisation bug. (Dynamically generated text such as MBean information or System properties will not be translated, but labels and headers should be. Note also that the applet will appear in the default language of the server, not the locale of the browser-user. At least for now.)
It's not included in this patch, but I have also written an Ant task (Regex2PotTask) which can extract English strings from JSPs which use the scheme described below, and an Ant build script which can run Regex2Pot to extract English, and later convert translated PO files into ResourceBundles (using the native GNU gettext utility "msgcat"). For now, internationalisation is a step which is separate from the build process, and my Ant script doesn't even live inside the jbossas directory tree.
Perhaps internationalisation should be kept separate from development concerns. As I said above, "msgcat" is a native utility. I believe Cygwin has a version of msgcat, but I'm not sure how well it would fit into the JBoss build. So integrating string extraction and conversion might be a lot of work. I would appreciate any advice. Or even some help!
Known issues:
1. String extraction and conversion is separate from the JBoss build process. This may or may not be a bad thing.
2. String conversion is not pure Java - it requires "msgcat" from the GNU gettext utilities. It should be possible to write a pure-Java replacement. This would probably be a requirement if we wanted to integrate i18n into the JBoss build.
3. The console applet is always in the server's default locale. At present, a lot of the strings shown in the applet are generated in the server, so the applet is forced to use the server's locale in all cases for consistency. I think the strings in question are transferred over JMX, so I'm a little afraid of breaking the JMX semantics. I could either add a Locale parameter to all of the affected JMX calls, assuming I can find them, or perhaps try to defer the ResourceBundle lookup until the last minute, on the client-side. It may not be worth it, since I suspect the average JBoss installation will only be administered in a single language.
4. JBoss AS's log messages and error messages are still in English. That's another project!
Regards,
Sean.
Technical explanation follows:
Technical details:
The JSPs are internationalised with the help of an entity resolver for the unified expression language (EL). The approach was partially inspired by the Seam i18n mechanism, and looks like this:
<title>JBoss Management Console - Server Information</title>
becomes:
<title>${messages["JBoss Management Console - Server Information"]}</title>
The entity resolver also supports MessageFormat arguments:
<h1><center>${messages["J2EE Application ''{0}''"][appName]}</center></h1>
For plain-Java code called by the JSPs (or embedded in scriptlets), there are some facade classes in front of ResourceBundle, whose main purpose is to handle missing resources/bundles more appropriately. These facades are in the classes org.jboss.console.I18n and org.jboss.jmx.console.I18n, along with a servlet filter, the entity resolver and other helpers in the package org.jboss.varia.i18n.
Technical rationale:
I really, really tried to use a standard mechanism for internationalising plain-old-JSPs, particularly JSTL, but in the end I had to make something which was inspired by the Seam i18n mechanism: an EL entity resolver which looks up ResourceBundles and formats messages with dynamic values.
I had a few main goals:
1. make things easy for programmers: don't make the code hard to read or maintain.
2. fit in with Red Hat's translation workflow: we need to be able to extract English text to GNU "gettext" POT files.
3. no cheating: don't add scriptlets to the JSPs
4. don't break JBoss!
For point 1, I think it's very important to keep the English text in the source code, which is where developers are used to seeing it.
Externalising the English text into ResourceBundles, with artificial keys like "label.OK" is definitely the default option in Java, encouraged by Sun's JavaDocs, but it is fairly unusual in open-source internationalisation outside Java-land. Managing artificial string keys (creating, purging, ...) is quite difficult in a closed corporate setting, and even harder in the case of distributed development. I know IDEs like Eclipse have tooltip support for looking up ResourceBundles, but only if you fit into the Eclipse i18n scheme. Unfortunately, the Eclipse i18n scheme is a little too closely-coupled to Eclipse's needs. (For instance, it doesn't really support the idea of a server whose clients are using different locales.)
For point 2, Red Hat's translation team is used to working with "gettext" POT/PO files, with translation editors and other infrastructure which process them. Gettext also provides a number of command-line utilities which help with merging and cleaning translation/PO files. The approach I chose *does not* use gettext at runtime, nor depend on gettext jars, but it does allow for gettext POT files to be extracted from the source code, and to generate ordinary ResourceBundles (.properties) from the translated PO files.
As for point 4, I mentioned that the i18n effort was initially intended for EAP 4.3. This is part of the reason I avoided adding runtime dependencies.
Re: Testing - where possible, I have tested things myself, but I don't have the expertise to exercise the consoles fully. In particular, I couldn't get the JMS-related pages to work, even without i18n changes - they seem to depend on extra JMS jars being available; even then I would need to create JBoss MQ channels before the page will render without errors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[JBoss JIRA] Created: (JBAOP-573) Created Interceptor name is assumed to not change for a given scenario
by Flavia Rainone (JIRA)
Created Interceptor name is assumed to not change for a given scenario
----------------------------------------------------------------------
Key: JBAOP-573
URL: http://jira.jboss.com/jira/browse/JBAOP-573
Project: JBoss AOP
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.CR9
Reporter: Flavia Rainone
Method ClassInstanceAdvisor.removeInterceptorStack() invokes create on each InterceptorFactory of the stack so it can find the name of the interceptors to remove.
This method assumes that the name of the interceptor it is creating is the same name of the interceptor it must remove. However, the definition of the name of an interceptor is up to the internal workings of the interceptor implementation:
public MyInterceptor implements Interceptor
{
public static int count = 0;
String name;
public MyInterceptor()
{
this.name = "Interceptor number " + count ++
}
...
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
