Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <sco...@jb...> - 2005-07-25 20:54:46
|
I'm not sure what you mean by a single UserInputPanel. The userInputSpec.xml resource can point to whatever you want as this is just a resource mapping. From the jbossas installer:
| <res id="userInputSpec.xml" src="@{jboss.build}/install/userInputSpec.xml"/>
|
The userInputSpec.xml can have any number of panels defined. The jbossas install version currently defines 3:
| <userInput>
| <!-- Server configuration name panel -->
| <panel order="0">
| <field type="title" align="right"
| txt=" Configuration Name" bold="true" size="2"
| id="configName"
| icon="/images/search.png"
| />
| <field type="text" variable="SERVER_CONFIG">
| <description align="left" txt="The jboss server/xxx configuration name, e.g., default, all"
| id="serverConfigName.text"/>
| <spec txt="Name:" id="text.label" size="32" set="default"/>
| </field>
| <field type="divider" align="center"/>
| <field type="staticText" align="left"
| txt="Note: Using a configuration name other than 'default' will require use of -c name to select the configuration" />
| </panel>
|
| <!-- JMX Security Panel -->
| <panel order="1">
| <field type="title" align="right"
| txt=" JMX Security" bold="true" size="2"
| id="jmxSecurity"
| icon="/images/lock.png"
| />
|
| <!-- JMX interface security -->
| <field type="staticText" align="left"
| txt="This section allows you to control whether the JMX interfaces are secured"
| id="jmxSecurityText"/>
| <field type="check" variable="secureJmxConsole">
| <!--
| <description align="left" txt="Should the jmx-console.war be secured?"
| id="secureJmxConsole"/>
| -->
| <spec txt="Secure jmx-console.war" id="secureJmxConsole" true="true" false="false"
| set="false"/>
| </field>
| <field type="check" variable="secureWebConsole">
| <spec txt="Secure web-console.war" id="secureWebConsole" true="true" false="false"
| set="false"/>
| </field>
| <field type="check" variable="secureJmxConnector">
| <spec txt="Secure jmx-invoker-service" id="secureJmxConnector" true="true" false="false"
| set="false"/>
| </field>
|
| <!-- The JAAS security domain names (without the java:/jaas prefix) -->
| <field type="divider" align="center"/>
| <field type="text" variable="jmxConsoleDomain">
| <description align="left" txt="The JAAS security domain name for the jmx-console.war"
| id="jmxConsoleDomain.text"/>
| <spec txt="Enter security-domain:" id="text.label" size="32" set="jmx-console"/>
| </field>
| <field type="text" variable="webConsoleDomain">
| <description align="left" txt="The JAAS security domain name for the web-console.war"
| id="webConsoleDomain.text"/>
| <spec txt="Enter security-domain:" id="text.label" size="32" set="web-console"/>
| </field>
| </panel>
|
| <!-- Keystore password -->
| <panel order="2">
| <!-- url encryption key-->
| <field type="staticText" align="left"
| txt="This key can be some arbitrary text. It will be used to encrypt the parameters sent on the url."
| id="staticText.text"/>
|
| <field type="rule" variable="urlEncryptionKey">
| <description align="left"
| txt="Alphanumeric key used to encrypt the url (max 10) e.g ebiKey007"
| id="description.rule.1"/>
| <spec txt="Key to encrypt url:" layout="AN:12:10"/>
| <validator class="com.izforge.izpack.util.NotEmptyValidator"
| txt="The encryption key can only be alphanumeric chars upto length 10"/>
| </field>
| </panel>
| </userInput>
|
only 2 of which are included in the install.xml configuration:
| <!--
| The panels section.
| We indicate here which panels we want to use. The order will be respected.
| -->
| <panels>
| <panel classname="HelloPanel"/>
| <!-- Display the release readme panel -->
| <panel classname="HTMLInfoPanel"/>
| <!-- Display the LGPL panel -->
| <panel classname="LicencePanel"/>
| <!-- Display an installation location panel -->
| <panel classname="TargetPanel"/>
| <!-- Display an installation group selection panel -->
| <panel classname="InstallationGroupPanel"/>
| <!-- Display a pack selection panel -->
| <panel classname="PacksPanel"/>
| <!-- UserInputPanel#0 - server config name -->
| <panel classname="UserInputPanel"/>
| <!-- UserInputPanel#1 - jmx security -->
| <panel classname="UserInputPanel"/>
| <!-- Display a summary of the packs to install -->
| <panel classname="SummaryPanel"/>
| <!-- Do the install -->
| <panel classname="InstallPanel"/>
| <panel classname="SimpleFinishPanel"/>
| </panels>
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886486#3886486
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886486
|
|
From: <aco...@jb...> - 2005-07-25 20:49:44
|
Excellent! i would also like mail listener chains processing the initial input stream, etc. There should be multiple points in which you can plug in chains. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886485#3886485 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886485 |
|
From: mikezzz <nu...@jb...> - 2005-07-25 20:43:19
|
...everything else is a nail :-). Quick suggestion regarding delivery. I would like to remove the different delivery MDB implementations and replace them with a single DeliveryMDB. Remote, Local, MailingList and WhateverElse delivery would be handled by MailListener chains. We would configure an number of different DeliveryMDBs instances each with associated to a queue and the appropriate chain. Basically moving the functionality of the MDBs into MailListeners, increasing reuse..etc..etc. Also allows us to place relevant actions within the appropriate chains (e.g. SPAM filtering on the local delivery chain). Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886483#3886483 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886483 |
|
From: mikezzz <nu...@jb...> - 2005-07-25 20:31:58
|
We definitely want to do Virtual Domains: http://jira.jboss.com/jira/browse/JBMAIL-40 What you have specified has merit and in concept is largely how would invisage it working (Andy speak up I am talking nonsense). However we would probably use MBeans to perform the configuration. The Realm (or DomainGroup or whatever you would like to call the logical aggregation of domains) would reference configured instances of the appropriate User Repository and Mailbox Manager. This would allow reuse instances across different realms. Rather than have the concept of a Realm Manager we would probably use a MailListener Chain ("RoutingChain" perhaps) would would have references to all of the Realms and associated delivery queues (either one listener per domain or a single listener that references all of the domains). The SMTP protocol would the push the mail to the RoutingChain which deliver it to the approriate local domain(s) and/or pass it to the remote delivery queue. Protocols like POP would probably be bound to a single Realm and lookup the associated User Repository and Mailbox Manager. Interestingly enough probabaly 85% of the code to make this happen are already there. Its mostly a case sorting out configuration. Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886482#3886482 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886482 |
|
From: <aco...@jb...> - 2005-07-25 20:18:49
|
Hi all, I'm working on converting the install to izPack (http://www.izforge.com/izpack/) instead of our own effort, Cheese. In order to do this, I need a rather annoying limitation eliminated. Presently, the UserInputPanel requires a resource which can only be named userInputPanel.xml. This means there can only be one UserInputPanel. That is pretty much a non-starter for us. Someone posted some ideas here (http://openfacts.berlios.de/index-en.phtml?title=IzPack/Panels) and the code (I looked at it) seems straight forward. Likely, this will involve discussion and collaboration with the izPack guys. I have other work to do in order to get us there, but if no one steps up in a few days I'll do it myself. Next, we'll need ways to dynamically disable form controls (at least) or skip panels in the event a user doesn't ask for something (like SSL). That could be a bit more work (and is more GUI). Thanks, Andy View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886481#3886481 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886481 |
|
From: <cle...@jb...> - 2005-07-25 19:57:43
|
Can you the WAR in a fresh-copy of JBoss? You can use the SAR in whatever application server you like, as you need it to profile your application inside Jboss, but I guess it would be better to use a fresh copy. (NO messy with struts). Clebert View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886479#3886479 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886479 |
|
From: wytten <nu...@jb...> - 2005-07-25 19:48:24
|
With RC2, the profiled app delivers the correct markup, but when I go to the jboss-profiler web application and submit the name of the capture directory, I get a blank page, instead of the expected form where you choose the process id. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886477#3886477 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886477 |
|
From: <aco...@jb...> - 2005-07-25 19:12:06
|
We've done some performance testing pre-M1 but nothing recent so nothing va= lid. That will be a major goal of M4 is to make SpecJ happy. Pure numbers= benchmarks are irrelevant because it is highly dependent on DB used, size = of mails, hardware and network. So the numbers are never particularly good= unless all variables except one are equivilent. Needless to say, public b= enchmarking doesn't work that way. Since we may work with the James guys i= n some areas, its unlikely I'll publish competitive to JAMES benchmarks jus= t to antagonize them. It will come down to: if you want an apache style pr= oject with apache style support and you like or don't dislike JAMES's appro= ach, use JAMES. If you want the "professional open source" style support, = like or dont' dislike our approach, use JBMS. Likely we'll make ease of in= stallation and ease of management a core advantage as well (not sure if the= y're working on it). In the end performance will be a matter of what you'r= e able to achieve with a capital vs hardware. We aim high and I think we'l= l beat Exchange and Domino easily in this area (read: they're really slow a= nd bloated). when finished, I suspect we'll beat postfix in this area (cop= ies stuff around alot). We may beat others in some scenarios but its possi= ble that a db backed mail server can't play as amusingly well in benchmarks= as a file backed one (even if the db backed one scales up better). Not to= say we can't create "fun for benchmarks" configs but frankly it won't be s= omething I spend any time on (only real world). =20 However, JAMES and JBMS currently have a major bottleneck: JavaMail sucks. = We'll need to address this. I approached JAMES on collaboration here but = most folks seemed disinterested in that part. If that is the case we'll li= kely create a LGPL reimpelmentation once we're further along. At that poin= t JAMES will have to reimplement as well or be left in the dust at least wh= en running in a DB backed mode with high concurrency.=20 -Andy View the original post : http://www.jboss.org/index.html?module=3Dbb&op=3Dv= iewtopic&p=3D3886474#3886474 Reply to the post : http://www.jboss.org/index.html?module=3Dbb&op=3Dpostin= g&mode=3Dreply&p=3D3886474 |
|
From: <sco...@jb...> - 2005-07-25 18:57:45
|
Yes send the doc so it can be incorporated into this thread. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886468#3886468 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886468 |
|
From: wytten <nu...@jb...> - 2005-07-25 18:35:44
|
Yes, we are using struts. When the problem occurs the container correctly challenges the user with a login page, but after authentication the blank page is delivered. I will try RC2 and see if that makes any difference. Thanks, Dale View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886461#3886461 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886461 |
|
From: <cle...@jb...> - 2005-07-25 18:23:18
|
Are you using struts? It looks like you have struts in the classpath. I never had any problems with jboss-profiler-noAOP.sar You can download a newer version of the profiler here: http://labs.jboss.com/portal/index.html?ctrl:id=page.default.downloads&project=jbossprofiler View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886458#3886458 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886458 |
|
From: wytten <nu...@jb...> - 2005-07-25 18:07:14
|
Hello, I have found that while RC1 works with a small web application, that when I try to profile a larger app, the behavior of that app changes dramatically: Instead of the markup the app is supposed to deliver, the app produces an empty HTML page. I realize that this is not a lot of information to go on, but I'm wondering what I can do in order to figure out what is failing. I tried using the Eclipse debugger but the app simply delivers an empty page without hitting any of the breakpoints I set. It seems to be the mere presence of the jboss-profiler-noAOP.sar file that causes the problem, because if I restart JBoss after adding the sar to the deploy directory, the app stops working even if I don't supply the runjbossInspector JVM argument. Below is some info from the JBoss server.log file. Thanks. Dale JAVA: /cygdrive/c/tools/jdk1.5.0_04/bin/java JAVA_OPTS: -Xmx512m -XX:MaxPermSize=128m -XrunjbossInspector:e:/temp/jboss,include=com,ignore=* -Dprogram.name=run.sh 12:43:58,308 INFO [Server] Release ID: JBoss [Zion] 4.0.1sp1 (build: CVSTag=JBoss_4_0_1_SP1 date=200506150216) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886451#3886451 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886451 |
|
From: mholzner <nu...@jb...> - 2005-07-25 18:04:46
|
What about a JACC module descriptor similar to login-config.xml ? Or even make JACC a part of login-config.xml ? After all it seems that the login module and the jacc module have to work together. JACC modules could have a contract similar to JAAS modules (stackable etc.), and should be just as easy to configure per application. I'd also like to mention that this module should allow to be extended to cover access control checks for things like portal resources, or workflow processed, etc, so that multiple PEP interceptors could call into one central PDP (via the JACC impl). I have a document written up describing one possible way (based on the 4.0.2 jacc implementation classes) that I could forward you if you are interested. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886448#3886448 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886448 |
|
From: <sco...@jb...> - 2005-07-25 17:17:04
|
As of the current head/4.0 (for 4.0.3) jbossxb schema resolution behavior, there is a DefaultSchemaResolver implementation of org.jboss.xb.binding.sunday.unmarshalling.SchemaBindingResolver that uses a JBossEntityResolver instance. The resolution logic of the SchemaBinding resolve(String nsUri, String localName,
String baseURI, String schemaLocation) call is:
Using the nsUri as the systemID in the JBossEntityResolver.resolve(publicID, systemID) call. Looking at how we currently have some j2ee1.4 schemas registered, it looks like the first call should be to use the nsUri as the publicID
Use the schemaLocation as the systemID in the JBossEntityResolver.resolve(publicID, systemID) call.
If the schema is still not found, and the baseURI is not null, the xsd is located using a URL created from: URL(baseURI, schemaLocation).
Otherwise, if the baseURI is null, the xsd is located using a URL created from the schemaLocation.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886437#3886437
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886437
|
|
From: <sco...@jb...> - 2005-07-25 17:07:58
|
The current hard-coded publicID to dtd/xsd mapping in the JBossEntityResolver needs to be externalized to allow for augmenting with user schemas. I created the following feature request issue: http://jira.jboss.com/jira/browse/JBAS-2038 The whole publicID/systemID/namespaceURI resolution behavior needs to be consistent across the various xml contexts. As I mention in the case I have not gotten the xml catalog resolver from apache to work as I would like, but I don't see a problem with using the xml catalog syntax for the externalization of the mappings. I need some feedback on how schemas are being resolved today in webservices and the like along with how this need to change with the introduction of jaxb. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886434#3886434 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886434 |
|
From: <sco...@jb...> - 2005-07-25 14:45:03
|
Create a jira issue for the unchecked roles issue so I can ensure the units tests are covering the usage. I'll validate the current roles iterator issue around the transport settings. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886403#3886403 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886403 |
|
From: yxyang <nu...@jb...> - 2005-07-25 14:41:30
|
Thanks Julien. I hope i can catch it up and then contribute my Instant messaging server for the jboss portal. regards Yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886397#3886397 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886397 |
|
From: tcherel <nu...@jb...> - 2005-07-25 14:40:34
|
Cool :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886402#3886402 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886402 |
|
From: <sco...@jb...> - 2005-07-25 14:38:38
|
Of course, that is the jboss way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886401#3886401 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886401 |
|
From: yxyang <nu...@jb...> - 2005-07-25 14:24:24
|
Thanks Julie. I hope i can catch it up and then contribute my Instant messaging server for the jboss portal. regards Yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886397#3886397 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886397 |
|
From: <ju...@jb...> - 2005-07-25 14:22:03
|
if you search a little bit more you will find several in portlet module too. the server one is for testing purpose. the portlet one is for testing the portlet container. the core one is the one we use in jboss portal core. each config is supposed to assemble and wire components together. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886396#3886396 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886396 |
|
From: yxyang <nu...@jb...> - 2005-07-25 14:18:22
|
I found that there are two definitions for portal:service=Server. One is in ./server/src/resources/portal-server-sar/META-INF/jboss-service.xml the other is located in ./core/src/resources/portal-core-sar/META-INF/jboss-service.xml Why is this? Is the first one only for the testing of server module? thanks yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886394#3886394 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886394 |
|
From: <ju...@jb...> - 2005-07-25 14:07:29
|
we use dependency injection and it is done by the microkernel using the file jboss-portal.sar/META-INF/jboss-service.xml | <mbean | code="org.jboss.portal.server.impl.ServerImpl" | name="portal:service=Server" | xmbean-dd="org/jboss/portal/server/impl/ServerImpl.xml"> | <depends optional-attribute-name="RequestController" proxy-type="attribute">portal:controller=Request</depends> | <depends optional-attribute-name="ContainerRegistry" proxy-type="attribute">portal:service=ContainerRegistry</depends> | </mbean> | means, declare the service Server and inject the services controller request and container registry in it when you deploy it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886388#3886388 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886388 |
|
From: yxyang <nu...@jb...> - 2005-07-25 14:02:44
|
Hi I checked out the jbp2.2 head. Where is the RequestController of ServerImpl set? I trace and read the source code and cannot find out where the value of RequestController is set. thanks yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886386#3886386 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886386 |
|
From: <ju...@jb...> - 2005-07-25 13:57:06
|
it is necessary in order to keep the user settings up to date with respect to the database that may change. but what could be improved here is to lookup the user according to its primary key and not user name, with that ID hibernate is capable to lookup users directly in the second level cache which avoid to going to the database on each request. the first time the user is accessed, we retrieve the user and put its ID in the session. on other access we use the user ID to get the user from the session by using a session.get() instead of performing a query. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886385#3886385 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886385 |
1965 messages has been excluded from this view by a project administrator.
