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: <mcu...@jb...> - 2005-07-30 17:54:18
|
Ben, This sounds like it has some potential. You might also want to think about ways this could aid in the creation of a JBossCashAOP applications / projects. A standard wizard we create for all of our major plugins is a "Project Wizard" which automatically places the necessary JARs etc in the users's project for compiling and using in their application. This removes the need for them to keep track of JARs manually in their classpath. Other things you might want to think about: - We have a very good AOP plugin that supports a pretty good subset of AOP's functionality in eclipse. We use visual cues all over the place to deliver useful information to AOP developers. You might want to expand / extend upon some of those visual cues for Cached POJO field or method interception, as an example. - I'm not sure how effecient or doable it is, but it's also nice in alot of cases to offer code completion wherever possible. Something that comes to mind would be for instance when looking up a POJO from the TreeCache, possibly a popup that shows all the current POJOs in the cache. This might be tough since it's runtime information, but just an idea. I'm sure there are more things specific to CacheAop that I haven't thought of as I only know the product on the surface =). At any rate, moving forward with discussion about the new extension, if you do decide that you want this done, do you have any ideas for who will be implementing? ATM we have our hands pretty full with the 4 of us on the IDE team. We can certainly be there to help smooth the transition etc, and give out best practices for developing with eclipse. I recommend you take a look at our developer cookbook guide to get a good feel for eclipse. It has a lot of good step-by-step examples for extending eclipse. Here's the URL: http://jboss.org/products/jbosside/docs Make sure to download the "Example Projects" .. it's a zip with lots of helpful source (the cookbook uses it). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887483#3887483 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887483 |
|
From: <mcu...@jb...> - 2005-07-30 17:53:12
|
Ben Wang, lead of the JBossCacheAop project, has proposed a new component / extension for JBossIDE in JBossCache JIRA here: http://jira.jboss.com/jira/browse/JBCACHE-239 Let's discuss.. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887481#3887481 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887481 |
|
From: llucifer <nu...@jb...> - 2005-07-30 16:57:38
|
"epbernard" wrote :
| You need to explicitly list your embedded superclasses in your persistence.xml
I'm using 4.0.3RC1 and have the same problem. I tried your tip but it fails. This is the persistence.xml I have:
<entity-manager>
| <class>foo.EmbeddedSuperClass</class>
| </entity-manager>
|
Where EmbeddedSuperClass is
@Embeddable
| @EmbeddableSuperclass
| public class EmbeddableSuperClass implements java.io.Serializable {
|
| ...
| }
and DerivedClass is
@Entity
| @Inheritance(strategy=InheritanceType.JOINED)
| public class DerivedClass extends EmbeddableSuperClass implements Serializable{
| ...
| }
But the properties derived from EmbeddableSuperClass are note created in the database. Is there a "conflict" because EmbeddableSuperClass is used as a @EmbeddableClass and a @Embeddable?
This kind of hierachy is driven by the following design. I have some global types which act as a default value and which are used as embedded instantec as well as in many-to-one relations. An example would be contract detail. In each order instance I have a reference to a "GlobalContractDetail" which is an instance of a ContractDetail and a used contract detail which store a snapshop of the GlobalContractDetail used a time of creation of the order. In my usecase I have a hierachie of ContractDetail. So the actual class model is:
@Embeddable, @EmbeddableSuperClass ContractDetail with basic properties.
@Entity GlobalContractDetail extends ContractDetail which adds a PK to ContractDetail
Order has a @many-to-one to GlobalContractDetali and a @embedded ContractDatail which stores the snapshot.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887478#3887478
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887478
|
|
From: bdaw <nu...@jb...> - 2005-07-30 14:38:35
|
I changed the mappings to one-to-one and It seems it's all right now. You were absolutely right - thanks a lot! I'll do some more tests to be sure and should commit it today in 2.0 branch. Problem with Editing post (http://jira.jboss.com/jira/browse/JBPORTAL-294) will be resolved also. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887440#3887440 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887440 |
|
From: yxyang <nu...@jb...> - 2005-07-30 12:52:08
|
I checked the source code and i found that it is strange to have many-to-one mapping is used:
In ./forums/src/main/org/jboss/portlet/forums/impl/TopocImpl.java
anonymous wrote :
| /**
| * @hibernate.many-to-one
| * column="jbp_first_post_id"
| * class="org.jboss.portlet.forums.impl.PostImpl"
| */
| public Post getFirstPost()
| {
| return firstPost;
| }
|
and
In ./forums/src/main/org/jboss/portlet/forums/impl/PostImpl.java:
anonymous wrote :
| /**
| * @hibernate.many-to-one
| * column="jbp_topic_id"
| * class="org.jboss.portlet.forums.impl.TopicImpl"
| */
| public Topic getTopic()
| {
| return topic;
| }
|
I feel that it should be one-to-one mapping and i think it could be the reason of deletion failure.
Please comment and If one-to-one mapping should be used, i will modify the codes.
THanks
Yang
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887435#3887435
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887435
|
|
From: yxyang <nu...@jb...> - 2005-07-30 10:00:50
|
reported on jira already View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887424#3887424 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887424 |
|
From: <ju...@jb...> - 2005-07-30 08:09:21
|
can you provide a jira bug report, bolek is working on the forums and he will be capable to fix it ? thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887421#3887421 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887421 |
|
From: yxyang <nu...@jb...> - 2005-07-30 06:23:21
|
Hi (For Jbp-2.0 branch) I experienced the deletion of a posts failure. I went through the database schema of jbp_forums_**** I found the foreign key constrains between jbp_forums_topics and jbp_forums_posts are a bit strange. That is to say, the foreign key constrain is bi-direction. Is this correct? I cannot even delete them manually through psql console. Please help! anonymous wrote : | jbossportal=# \d jbp_forums_posts | Table "public.jbp_forums_posts" | Column | Type | Modifiers | -----------------+-----------------------------+----------- | jbp_id | integer | not null | jbp_topic_id | integer | | jbp_edit_count | integer | | jbp_edit_date | timestamp without time zone | | jbp_create_date | timestamp without time zone | | jbp_subject | character varying(255) | | jbp_text | character varying(255) | | jbp_poster_id | integer | | Indexes: | "jbp_forums_posts_pkey" PRIMARY KEY, btree (jbp_id) | Foreign-key constraints: | "fkf2c0436d499bfc7a" FOREIGN KEY (jbp_poster_id) REFERENCES jbp_forums_posters(jbp_id) | "fkf2c0436dbfb64ffa" FOREIGN KEY (jbp_topic_id) REFERENCES jbp_forums_topics(jbp_id) | | | jbossportal=# \d jbp_forums_topics; | Table "public.jbp_forums_topics" | Column | Type | Modifiers | --------------------+-----------------------------+----------- | jbp_id | integer | not null | jbp_forum_id | integer | | jbp_view_count | integer | | jbp_replies | integer | | jbp_first_post_id | integer | | jbp_last_post_id | integer | | jbp_last_post_date | timestamp without time zone | | jbp_poster | integer | | jbp_type | integer | | jbp_status | integer | | jbp_subject | character varying(255) | | Indexes: | "jbp_forums_topics_pkey" PRIMARY KEY, btree (jbp_id) | Foreign-key constraints: | "fk6c1a04ca7892a9ba" FOREIGN KEY (jbp_forum_id) REFERENCES jbp_forums_forums(jbp_id) | "fk6c1a04ca577068cb" FOREIGN KEY (jbp_first_post_id) REFERENCES jbp_forums_posts(jbp_id) | "fk6c1a04ca145469a8" FOREIGN KEY (jbp_poster) REFERENCES jbp_forums_posters(jbp_id) | "fk6c1a04cac1b3e31f" FOREIGN KEY (jbp_last_post_id) REFERENCES jbp_forums_posts(jbp_id) | | | Thanks yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887416#3887416 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887416 |
|
From: <sco...@jb...> - 2005-07-30 03:07:24
|
I have no confidence that stopping/starting a deployment does the right thing in terms of restoring a completely functional deployment. Have you tested the 2002 patch with scoped deployments and actually used all deployment types after a stop/start? The mapping to our existing deployment model from the jsr88 DeploymentManager is as I described. I don't want to mess around with the deployment semantics in 4.0.x production line. The jsr77/jsr88 services need to be merged such that distribution of an application causes a jsr77 mbean to be created. The jsr77 layer needs to ignore the the CREATE_EVENT events for such mbeans. The MainDeployer.deploy will cause the deployments to reach their started state. The MainDeployer.deploy is invoked by the DeploymentManager.start. The DeploymentManager.stop event needs to use the MainDeployer.undeploy to make the application unavailable. The resulting DESTROY_EVENT events also need to be ingored for mbeans being managed by the jsr88 layer. Arguably the existing hot deployment service also needs to be merged/integrated with the jsr88 deployment service in order for there to be a consistent treatment of deployments. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887409#3887409 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887409 |
|
From: fabcipriano <nu...@jb...> - 2005-07-30 02:10:41
|
I agree with distribute, undeploy and redeploy procedure, but in my insigni= ficant opinion I think that start and stop should use MainDeployer. Because JBoss code map the JSR-77 status (starting, running, stopping etc) = to the ServiceMBean(starting, started, stopping etc). This form the JSR-88 = implementation will be like a suggestion of the j2ee deployment 1.1 specifi= cation item 4.6.2 Besides implementation of getAvailableModules and getNonRunningModules with= jsr-88=20 implemented this way it will force us to read all modules in the local disk= to find out the nonRunning modules.=20 In the other way the JSR-88 implementation let open this question when says= in the item 4.3: "A vendor may choose to initialize an application?s running environment when the archive is distributed to the system or wait until the= start action is called. The only requirement is that the application is no= t available to clients until the start action is called. Similarly a vendor= may choose to shut down a running application?s environment when stop is c= alled or wait until undeploy is called. The only requirement is that the ap= plication is made unavailable to clients when the stop action is called." I=C2=B4m using MC4J with jboss jsr-88 with the JBAS-2002 modification and I= had no problem until now. I can stop, start a Module and see the state in = the screen only a undeploy make my modules dissapear from the GUI. Am I missing something ? View the original post : http://www.jboss.org/index.html?module=3Dbb&op=3Dv= iewtopic&p=3D3887408#3887408 Reply to the post : http://www.jboss.org/index.html?module=3Dbb&op=3Dpostin= g&mode=3Dreply&p=3D3887408 |
|
From: <aco...@jb...> - 2005-07-30 02:09:51
|
don't I always? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887406#3887406 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887406 |
|
From: binario <nu...@jb...> - 2005-07-29 22:26:36
|
Thanks Emmanuel. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887395#3887395 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887395 |
|
From: <ad...@jb...> - 2005-07-29 22:11:18
|
"aco...@jb..." wrote : So I'm working like a dog on the izPack installer http://jira.jboss.com/jira/browse/JBMAIL-60. You are running around in circles making a lot of noise? :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887394#3887394 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887394 |
|
From: aguizar <nu...@jb...> - 2005-07-29 22:06:18
|
There are side effects. From the javadoc for getField(): anonymous wrote : Returns a Field object that reflects the specified public member field of the class or interface Effectively, getField() recurses upon superclasses, but only considers public fields. Conversely, getDeclaredField() considers all fields but does not recurse. Of course, jBPM should support inheritance of actions. Could you please open a JIRA issue? I propose that FieldInstantiator calls getDeclaredField() not only on the target class but all its superclasses until the field is found or Object.class is reached. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887393#3887393 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887393 |
|
From: <aco...@jb...> - 2005-07-29 22:04:38
|
So I'm working like a dog on the izPack installer http://jira.jboss.com/ji= ra/browse/JBMAIL-60. The new installer has a way to output a automated scr= ipt. That's how we'll do normal dev builds yet not have divergent jboss-se= rvice.xml files. The experience has made me put even more thought into som= ething I'd been a lot thinking about (http://linuxintegrators.com/acoliver/= code/?permalink=3Dx-0018.html http://linuxintegrators.com/acoliver/code/200= 5/07/10/x-0022.html)... configuration and wiring.. I've a new way I want t= o do things in the future. I'll go on about this probably tomorrow but my = eyes are feeling buggy as I'm working on 2 other [top secret open source li= ke Gavin does ;-)] projects at night as well. =20 The new installer is based on the the extensions and the JBoss installer (i= f you haven't checked out the JBAS installer go to downloads and try it now= !). It uses velocity for the jboss-service.xml file which is a lot cleaner= than the big piece of crap I fermented called Cheese (someone asked if I w= rote cheese to prove I couldn't do gui programming -- ha ha). While it is = a lot prettier, I don't think it is saving me a great amount of time frankl= y. One thing that was better about Cheese is that it was just ant tasks. = izPack is a bit too sophisticated for its own good in places.... Moreover = the debug cycle is painful... Screw something up? You'll find out after y= ou create the install and RUN the whole blasted thing. (I swear their ough= t to be a way to verify stuff. And the JB Extensions don't help either, I = think maybe it should run through the templates with velocity as a "test ru= n" to make sure they all parse at least so I can have compile-time checking= rather than install-time checking) It'll get easier once I get everything integrated into the build. I plan t= o put this "in your face" so there won't be a way to build JBMS without it.= Fortunately, it won't require a GUI for normal developer stuff and I thin= k it will actually make things easier there. Doing this also points out that JBossDNA er I mean JEMS will need a way to = do linked installers of a sort. The new JBMS installer will come in two fl= avors: Big and little...ha ha. Meaning the Big will include JBossAS and th= e little will assume you have it. Actually it may end up coming in 4 flavo= rs (big java web start, little java web start, big standalone, little stand= alone). Well, I really don't want to replicate the work on the JBoss inst= aller that lets you pick what features of the AS you want. I want to reuse= that work... I do need to say "x,y,z are required for JBMS so disable the = abillity to unselect them" but leave the rest up to the user... Maybe as a= n "advanced" install. =20 The first cut for M3 won't secure or trim down JBAS at all. I'll just incl= ude it all. We'll put a warning and a link to the securing wiki page in th= e readme. This will mean all-in-all that out of the box installation will be as simpl= e as a click on a web page and some questions about what all you want (POP,= POP/SSL...SMTP..etc) and what ports you want it on, your servername, etc..= The biggest pain is this business with the ssh key generation. I'm still= working on that. That was the most brittle part in the cheese install as = well. =20 Probably early next week I'll put out a preliminary "try me" before I start= integrating it into the build. I had origninally estimated this all at 2 = days...its taken a bit more than that..sssheesh. Meanwhile I really need help in clearing the remaining open M3 issues and b= ugs so we can kick that branch off and start M4. =20 PS thanks for the guys at JBoss who found izPack and did the extensions. T= hanks to Scott the infallible (http://linuxintegrators.com/acoliver/blog/20= 05/07/29/x-0033.html) for his help getting it all working. Thanks -Andy View the original post : http://www.jboss.org/index.html?module=3Dbb&op=3Dv= iewtopic&p=3D3887392#3887392 Reply to the post : http://www.jboss.org/index.html?module=3Dbb&op=3Dpostin= g&mode=3Dreply&p=3D3887392 |
|
From: <sco...@jb...> - 2005-07-29 21:58:38
|
See the related posting: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3887389#3887389 There needs to be a seperate jsr88 DeploymentManager service on the server side that maps the javax.enterprise.deploy.spi.DeploymentManager methods onto the MainDeployer methods: DeploymentManager.distribute : this needs to use the upload facility to make a deployment availble locally on the server. DeploymentManager.start : this invokes the MainDeployer.deploy for the locally uploaded module DeploymentManager.stop: this invokes the MainDeployer.undeploy for the locally uploaded module DeploymentManager.undeploy : this physically removes the uploaded module from the server. DeploymentManager.redeploy : this is simply a distribute/start combo. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887391#3887391 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887391 |
|
From: <sco...@jb...> - 2005-07-29 21:52:49
|
So related to: http://jira.jboss.com/jira/browse/JBAS-1997 There simply is no consistent notion of stopping a deployment as opposed to undeploying it. I have fixed the module type issue, and what happens now in the org.jboss.test.deployment.DeploymentTestCase.testListStartStopModules is that stopping the ear results in undeployment of the ejb and war modules, but does nothing to the ear deployment. The undeployment of the war/ejb do not result in removal of the jsr77 mbeans because the notification listener does not expect that a stop event equates to undeployment. Attempting to start the ear after this therefore results in error regarding duplicate jsr77 mbeans, and there is also a problem starting the war as the deployer cannot go from the stop state to the start state: | Caused by: javax.security.jacc.PolicyContextException: Operation not allowed | at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP | olicyConfiguration.java:201) | at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB | ossPolicyConfiguration.java:160) | at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347) | | ... 96 more | Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac | tion: linkConfiguration from state:inService | at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111) | at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP | olicyConfiguration.java:196) | In general, I don't see that we have a meaningful implementation of start/stop for our deployers based on MainDeployer ops. Until they are rewritten with these states in mind, there is no meaningful mapping of the DeploymentManager.start/stop operations. The alternative is to write a jsr88 facade to the MainDeployer that explicitly honors the distiction between distribution and starting, stopping and removal. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887389#3887389 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887389 |
|
From: epbernard <nu...@jb...> - 2005-07-29 21:52:22
|
I just answered the post older than the migration. I'm done now :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887388#3887388 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887388 |
|
From: epbernard <nu...@jb...> - 2005-07-29 21:51:15
|
Well this is not the actual code you used to test it, it does not compile. I've added a unit test and it's working fine for me. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887387#3887387 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887387 |
|
From: <ad...@jb...> - 2005-07-29 21:40:19
|
e.g. I pretty much ignore all traffic in the AOP dev forum because it is basically a user forum. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887385#3887385 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887385 |
|
From: <aco...@jb...> - 2005-07-29 21:37:15
|
okay good... I don't want to do JDK5 until M5 if possible. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887384#3887384 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887384 |
|
From: <ad...@jb...> - 2005-07-29 21:34:21
|
Emmanuel, please don't encourage people to post user questions in the dev forums. It is really annoying, and at it will mean is that most developers unsubscribe from watching this forums. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887383#3887383 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887383 |
|
From: epbernard <nu...@jb...> - 2005-07-29 21:30:36
|
Sometimes is a bit vague to find the problem. The cache is working. The invalidation is done by the persistence engine and/or your clache configuration automatically. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887382#3887382 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887382 |
|
From: epbernard <nu...@jb...> - 2005-07-29 21:26:32
|
you have to follow the javabean convention: j.innerClass View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887381#3887381 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887381 |
|
From: epbernard <nu...@jb...> - 2005-07-29 21:23:54
|
add an @Entity annotation to your subclasses and use the single table strategy (need a discriminator table, and most likely a custom discriminator value) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887380#3887380 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887380 |
1965 messages has been excluded from this view by a project administrator.
