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: <ovi...@jb...> - 2005-05-17 21:08:14
|
Tim wrote: anonymous wrote : | | Further to the discussion regarding asynchronous ACKs, here are some thoughts on how we can implement QueueBrowsing on the core classes and how it all works together. | | The assumption here is that we want to be able to browse any messages in a queue where delivery has not been attempted. We don't want to browse those messages where the message has been delivered but the JMS client has NACKed it. | | Currently the core classes don't allow us to distinguish those messages that have not had delivery attempted and those that have. | | A proposal would be modify the return value of Receiver.handle() from a boolean to one of three states: | | ACK - the message has been handled sychronously and acknowledged. | NACK-DeliveryAttempted - the message is not (yet) acknowledged but delivery is being attempted. | NACK-DeliveryNotAttempted - the message is not acknowledged and delivery has not been attempted. | | The acknowledgement store would also be modified to allow us to distinguish between NACK-DeliveryAttempted and NACK-DeliveryNotAttempted. I.e. it needs to store the tuple <receiver_id, message_id, nack_type (- one of delivery attempted or delivery not attempted)> | | For the case of a queue: | | If the queue has no consumers and messages arrive, nacks are stored with state NACK-DeliveryNotAttempted and the messages are stored. | | The QueueBrowser will only browse NACKed messages with state NACK-DeliveryNotAttempted, so it sees these messages. | | A consumer is now added to the queue, causing deliver() to be triggered. Messages with either of the two NACK states are sent for delivery. The consumer starts to accept messages for delivery, returning NACK-DeliveryAttempted to the router. | | A QueueBrowser will not see the messages with state NACK-DeliveryAttempted. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878102#3878102 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878102 |
|
From: mikezzz <nu...@jb...> - 2005-05-17 19:48:05
|
Aaaah, that sounds correct. I tend to use the deploy rather than the dev-deploy task. Write the code, make it work, send the patch (Ideally 2 patchs, one for the build and one for jASEN, so that we can verify each indenpendently). If it breaks something we'll fix it, or get you to fix it, or (in my case) shout, kick things and throw our toys from the pram :-).... Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878096#3878096 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878096 |
|
From: <ad...@jb...> - 2005-05-17 19:31:27
|
"sco...@jb..." wrote : So that is a good question. Actually the naming-tests should include the jnp-client.jar rather than jnp-server.jar, with the assumption that the consumer of the naming-tests export artifcact will configure the server given the naming-server artifcat. This illustrates a problem with semantic artifcat definition like a tests input artifcat. It depends on how the test is going to be run. If the test driver is a component like the jbossas testsuite, the jnpserver.jar should not be in the naming-tests. Even if the driver is a standalone unit test target that needs to configure a standalone naming server the, the unit test setup target should express that it needs both the naming-server and naming-tests component artifacts and dependencies. | That was my comment above about junit-config. However, I don't see any reason why jnpserver cannot be unit tested from standalone tests. Other complications like transport, security, ha enhancements would be tested elsewhere as part of integration tests. anonymous wrote : | For the common component dependency, I was assuming this was being used by the tests as in the case of the org.jboss.logging.Logger. There should also be a dependency on some base test harness which likely includes common. | This already exists in the "test" project. http://jira.jboss.com/jira/browse/JBAS-1768 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878095#3878095 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878095 |
|
From: wobbet <nu...@jb...> - 2005-05-17 19:25:10
|
When I go into Eclipse and run the "clean" target followed by the "xdoclet" target I get the files that you describe located in build/hbm/** When I run the dev-deploy task I go to build/deploy/dev/mail.har/org/jboss/mail and find only the msgstore directory in there, not the store directory that you are describing. I open up the actual .har file in WinZip and browse through the files and see that the files you describe are in the appropriate location. This tells me that the dev-deploy isn't including those files for the .har. I'm guessing someone updated the jar task but not the copyfiles task... Which is why I want to use common filesets. I would like explicit permission from Mike or Andrew to go forward with this since this is a substantive change in a common file versus simply adding my goodies in here and there... rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878094#3878094 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878094 |
|
From: <sco...@jb...> - 2005-05-17 19:24:00
|
So that is a good question. Actually the naming-tests should include the jnp-client.jar rather than jnp-server.jar, with the assumption that the consumer of the naming-tests export artifcact will configure the server given the naming-server artifcat. This illustrates a problem with semantic artifcat definition like a tests input artifcat. It depends on how the test is going to be run. If the test driver is a component like the jbossas testsuite, the jnpserver.jar should not be in the naming-tests. Even if the driver is a standalone unit test target that needs to configure a standalone naming server the, the unit test setup target should express that it needs both the naming-server and naming-tests component artifacts and dependencies. For the common component dependency, I was assuming this was being used by the tests as in the case of the org.jboss.logging.Logger. There should also be a dependency on some base test harness which likely includes common. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878092#3878092 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878092 |
|
From: <ad...@jb...> - 2005-05-17 19:18:32
|
When it comes to the final build of a project however, you want it to be as explicit as possible. You want to record exactly which versions were used to build the components such that you can reproduce it later. Currently, this is done by tagging things in CVS including all the thirdparty jars. One equivalent to this would be to add a target to the build that allows one to "materialize" the dependencies. i.e. build scripts are constructed that explcitly state their thirdparty versions and CVS tags. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878090#3878090 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878090 |
|
From: <ad...@jb...> - 2005-05-17 19:10:18
|
Ignoring the obvious mistake, yes. | <export id="naming-tests"> | <include input="jnpserver.jar"/> <!-- Can't run the tests unless you have the implementation :-) --> | <include input="jnp-tests.jar"/> | <include component="junit-junit"/> | <!--include component="common"/ This is used by the implementation not the tests? --> | </export> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878087#3878087 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878087 |
|
From: <ad...@jb...> - 2005-05-17 19:05:31
|
This gets a bit complicated because there are lots of different versions, I'll try to enumerate them: 1) The top level build version e.g. 4.0.2 2) The top level build branch e.g. JBoss4 3) The cvs version e.g. JBoss_4_0_2 4) The cvs branch e.g. Branch_4_0 5) The component version (if it is standalone or thirdparty) 6) The component specification version e.g. JMS1.1 7) Patch versions e.g. 4.0.2-JBAS1234 8) Different builds for different JVMs 1.3/1.4/5 When defining versions, the "head" description wants to be unspecific as possible where the top level is a federation of direct components like JBossAS and naming/transaction/jbossmq In other cases, the versions need to be specific. i.e. the JBossAS head branch uses log4j-1.2.8 until we say otherwise. Then there are the issues of compatiblity. e.g. JBossAS needs log4j-1.2.8 or does it need log4j-1.2.8+ or log4j-1.2.8-log4j-1.2.11 or maybe JBossAS 4.0.2 needs log4j-1.2.8+ but not log4j-1.2.10 etc. These issues fall into a number of different categories: 1) Who is reponsible for the versions used a) the top level buld b) the component c) something else 2) How are conflicts resolved a) by changing the top level build b) by changing the offending component c) other 3) How does this version information propogate a) in the build scripts b) in the artifacts 4) Who is responsible for verifying the information and how are problems signalled to the user a) the top level build b) cruise control c) testing View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878084#3878084 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878084 |
|
From: ScottMarlowNovell <nu...@jb...> - 2005-05-17 19:01:57
|
I looked at the code and I agree with your finding. The remotelyDeployed state should be cleared during startup processing but we leave it dirty. Nice find! The fix might be as simple as moving the "clear remotelyDeployed" flag to be before the "getState() == STARTING" test. Please create a Jira task for this (http://jira.jboss.com/jira/secure/BrowseProjects.jspa) and post the Jira bug report number here. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878083#3878083 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878083 |
|
From: <sco...@jb...> - 2005-05-17 18:58:56
|
So there seems to be a need to combine the artifacts export/import statements, so the naming component-info.xml exports might look like: | <export id="naming-server"> | <include input="jnpserver.jar"/> | <include component="apache-log4j"/> | <include component="common"/> | </export> | | <export id="naming-tests"> | <include input="jnp-tests.jar"/> | <include component="junit-junit"/> | <include component="common"/> | </export> | In general the artifacts from a component may need different dependent jars at runtime. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878081#3878081 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878081 |
|
From: <ad...@jb...> - 2005-05-17 18:52:00
|
The main issue as to whether this applies to the build is whether such a notion can be understood at the ant/repository level. e.g. can I go from | <project> | <component name="mdb"/> | </project> | and understand that the current jms1.1 implementation is jbossmq by default or if you want to override it | <project> | <component name="mdb"/> | <component name="jbossmessaging"/> | </project> | This also has issues where the implementation is external, e.g. the jms1.1 implementation is actually provided by an external jms. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878079#3878079 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878079 |
|
From: <ad...@jb...> - 2005-05-17 18:47:44
|
The assumption so far has been to reproduce the buildmagic model of project definitions. i.e. there is a list of components that have dependencies on other components which are built together. e.g. jbossas declares the transaction component which has dependencies on the j2ee component for the interfaces and common for the logging abstraction With the new build, these can either be expressed by importing the component or importing an artifact that the component exports. While this is fairly well understood (at least in the buildmagic way of doing this) this becomes more complicated when components are shared across top level builds. It also has the disadvantage that I have been complaining about for a long time that you get implementations depending on implementations with no real definition of what is really being expressed. If you look at an alternate approach like OSGI used by eclipse, you have the notion of defining integration points (interfaces) and implementations. These notions are of course versioned. For example you could have: | j2ee project: | <defines>JMS1.1</defines> | | mdb project: | <requires>JMS1.1</requires> | | jbossmq project | <implements>JMS1.1</implements> | | jboss/messaging project | <implements>JMS1.1</implements> | The requirement for consistent build would be that all "requires" have a "defines" and that each "defines" has an "implements". Of course, these can be mixed and matched, e.g. | jbossmq project | <implements>JMS1.1</implements> | <defines>jbossmq-il</defines> | | httpil project: | <implements>jbossmq-il</implements> | Such a feature can also be used to trim what is placed in a release or deployed/started at runtime. e.g. nobody "requires" JMS1.1, we can ignore the implementor and its dependencies. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878078#3878078 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878078 |
|
From: <ad...@jb...> - 2005-05-17 18:14:30
|
This brings in other configuration requirements. e.g. the jbossportal federation only wants jbossas as binaries, whereas the jbosscache federation wants it as source. So we need a configuration option that makes this explicit: | <project> | <info id="portal" | description="JBoss Portal" | repository="http://repository.jboss.com" | cvsroot="cvs.forge.jboss.com/cvsroot/portal" | </info> | <extends name="jbossas" type="binary"/> | <component name="bb"/> | <component name="wiki"/> | etc. | </project> | There are other requirements where the extension will be of mixed type, e.g. 1) Portal wants to include the license information, docs from jbossas 2) Portal does not want to run all the unit tests for jbossas when they run their unit tests Getting more complicated, the custom cache federation will probably only want to run tests for components where cache is actually used? You could even imagine the cache project wanting to make a workspace that "automagically" includes all the components/builds where the cache module is imported. Which would be good for cutting down the regression testing overhead but would be bad for people "fixing" tests rather than fixing the problem. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878075#3878075 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878075 |
|
From: ScottMarlowNovell <nu...@jb...> - 2005-05-17 18:09:00
|
anonymous wrote : My question: is this the intended behaviour and the date check is only a forgotten piece of code which was not supposed to work or is it a bug and the date check should be corrected? When starting the JBoss server, the cluster applications always overide the local applications. This helps avoid having different versions of your application on the cluster. If the application on your server is newer than what is on the cluster, then you need to copy the new application back to your server farm directory after the server is completely running. You might read a new posting related to this on the Wiki at http://wiki.jboss.org/wiki/Wiki.jsp?page=JoinTheClusterBeforeUpdatingTheFarmDirectory I hope this helps. I'll respond separately to your second posting. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878074#3878074 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878074 |
|
From: <ad...@jb...> - 2005-05-17 18:04:33
|
So a standalone build, just defines itself as the only primary component. A federated build allows you to "extend" other top level builds. Another example of federation would be to develop two builds together. e.g. the cache developers might build a workspace like: | <project> | <extends name="jbossas"/> | <extends name="jbosscache"/> | </project> | Allowing them to build jbossas and jbosscache from source together. This would automatically override jbossas's inclusion of jbosscache as a binary inclusion and make it a source project alongside the other jbossas components. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878073#3878073 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878073 |
|
From: <ad...@jb...> - 2005-05-17 18:00:10
|
I'll state the requirements through use cases and then we can move to something more concrete like defining a schema for each configuration. The xml will be pseudo for now. The basics of the top level build are to define some information about what we are building and the primary components that make up the build. It should provide enough information to be able to bootstrap the rest of the build. I'm going to ignore versioning for now and deal with that as a separate cross cutting concern on a different topic, but there will obviously be some overlap. Trivial example: | <project> | <info id="jbossas" | description=JBoss Application Server" | repository="http://repository.jboss.com" | cvsroot="cvs.forge.jboss.com/cvsroot/jboss" | </info> | <component name="naming"/> | <component name="transaction"/> | <component name="server"/> | etc. | </project> | Standalone example: | <project> | <info id="jbosscache" | description="JBoss Cache" | repository="http://repository.jboss.com" | cvsroot="cvs.forge.jboss.com/cvsroot/jboss" | </info> | <component name="jbosscache"/> | </project> | Federated example: | <project> | <info id="portal" | description="JBoss Portal" | repository="http://repository.jboss.com" | cvsroot="cvs.forge.jboss.com/cvsroot/portal" | </info> | <extends name="jbossas"/> | <component name="bb"/> | <component name="wiki"/> | etc. | </project> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878072#3878072 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878072 |
|
From: <ad...@jb...> - 2005-05-17 17:11:16
|
There appears to be some confusion here. junit is only used by the unit testing, but we still want to know that the junit module is required to run the unit tests if the project is distributed in binary form and federated into a greater test build. In fact, this is one drawback of defining the tests on the source element. Since you lose the notion of what are the tests (and what are any special test configuration) in the binary format | <source id="main" | rmic="**/NamingServer.class" | test="org/jnp/test/*Test.class" | > | <include includesref="thirdparty"/> | <include component="junit-junit"/> | <junit-elements> | <special config here/> | </junit-elements> | </source> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878069#3878069 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878069 |
|
From: <ad...@jb...> - 2005-05-17 17:01:20
|
What I propose we do is clearly define the current requirements with use cases explaining how they will be used. Then people can show counter examples or argue why it should be done a different way and we will more aware of why we are doing something in a particular way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878068#3878068 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878068 |
|
From: <ad...@jb...> - 2005-05-17 16:59:21
|
Further requirements that have been picked up along the way: 1) Being able to federate builds. e.g. jboss-portal includes jbossas i.e. one project is not based on a specfic list of components, it is based on a list provided by another project 2) Being able to version components to check their consistency 3) Provide a more rich definition of the component, e.g. licenses what "spec" it implements 4) Allow for custom release structures, e.g. being able to build testsuite configs using similar information that is used to build the main release 5) Making a lot of the component information available at runtime View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878067#3878067 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878067 |
|
From: <ad...@jb...> - 2005-05-17 16:55:08
|
Overtime, the requirements have changed and I believe we have a current structure something like the following: 1) A top level build that just defines the list of primary components 2) The component level build is made up of two files component-info which describes the external view of the component component build which desribes how the component is built 3) The tasks/macros as before The component-info is intended to describe what this component provides, but also what it uses. i.e. it could import other components (secondary components) e.g. the test module will import junit, there is no need in the top level build to define that we use junit because the test module provides that point of integration. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878066#3878066 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878066 |
|
From: <ad...@jb...> - 2005-05-17 16:50:36
|
First some history. The initial jbossbuild worked by having three different models. 1) The top level build model that defined all artifacts, these are the build/component/artifact elements 2) The component build model that defined how those artifacts were constructed componentdef/artifactdef/sourcedef 3) The tasks.xml that defined the artifact types and the macros that provide foreach type behaviour on the model above Assumptions: 1) The top level build information was shared by all the components and defined common/consistent properties. It also defined the release structure 2) The top level/component level model could be combined where you just had one project 3) Components were treated equivalently whether they were binary or source the only difference being whether an artifact's location was resolved to thirdparty/component or the ROOT/component/output 4) The build should be as declarative as possible, potentially allowing custom tasks to other build scripts to mine the build structure to provide other behaviour, e.g. cruisecontrol View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878064#3878064 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878064 |
|
From: <ad...@jb...> - 2005-05-17 16:44:02
|
After discussing this with Scott yesterday, we appear to have different views on what the build system should be providing. The requirements have certainly moved a long way since I initiated this work and 1) the jbossbuild project no longer appears to model what people are trying to achieve. 2) what people are trying to achieve is not clearly defined to me anymore View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878063#3878063 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878063 |
|
From: mikezzz <nu...@jb...> - 2005-05-17 16:29:11
|
They are generated into build/hbm during the build process. It sounds like the changes you made to the build.xml may have broken this. A clean and deploy generates all of the correct files for me. Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878060#3878060 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878060 |
|
From: wobbet <nu...@jb...> - 2005-05-17 16:01:06
|
I just took a look at the source tree in Eclipse (did another refresh from the root to make sure) and there is only one file in src/hbm and that is the HnStoredMessage xml file. Are the xml files generated or should they have been committed? rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878057#3878057 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878057 |
|
From: wobbet <nu...@jb...> - 2005-05-17 15:56:12
|
All I have is mail.ear/mail.har/org/jboss/mail/msgstore/hn/ that contains HnMessageStore.class HnStoredMessage.class I did an update from CVS right after I posted my message to see if I was out of date but that didn't help. rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878054#3878054 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878054 |
1965 messages has been excluded from this view by a project administrator.
