I have few panels in a JDialog which i need to disable for editing. basically i dont wont to gray-out the components and disable the components, but keeping the components as it is, i wont them to be un-editable, i know that components such as text boxes have that capability, but do other components such as check boxes and radio button have that? and on the other hand the solution which i'm thinking is basically to have a pane on top of the panel i wont to disable something like a glass pane.. will that be possible? or can i put any means of transparent component on top of the panel and control that...
i'm a bit new to jboss application server. i have deployed my bean on jboss and i'm trying to access the bean through a client which i developed... but i seem to not have done some stuff related to getting the initialcontext correctly.. please review the code..
the exception which i get when this is executed is as follows...
ok i think i figured the problem... i think i need to properly jar the file using the jar command in an ant script.. .i'm just zipping the files at the moment...
i'm trying to use JBoss to deploy my beans,,,, but when i try to deploy it.. it gives the following error message eventhough the application.xml file is included in the ear file... what can be the problem?
i just completed the EJB 2 certification and want to get some experience with EJB 3. in industry i have used xdoclets to help me in defining transactions etc. but after reading the features of EJB 3 i think those features are given by the spec it self...
i just wanted to clarify whether there's no differece between these two approaches. as in now annotations are just part of the spec it self where as earlier we had to use xdoclets or something simillar to get the work done..
i made a conclusion after referring some books... the return type of the findByPrimaryKey should be the component interface of the bean. and multiple finder methods should return a collection of them...
please add some description into this if any one of you have any more....
i have few doubts about the conclusions that i have come across for the following.. please comment on anything which i have interpreted wrongly or whether it is rite...
1) violating any rules put down to increase the portability of entity beans as an example not implementing any threads in the bean classes etc.. : what my idea is if you don't adhere to them you just dont have portability but you will still be able to successfully deploy the bean and run it..
2) what if narrowing is used to locate a local home interface of a bean.. : what my idea about this is that you can do this.. its just that the narrow will be a no-op method. but it wont give you any exceptions...
3) calling the remove method of a local session home interface which accepts the primary key... : when you try to use this method it will throw a RemoveException.. and if you try to execute the getPrimaryKey method of the local component interface of a session bean it will simply throw either a RemoteException or an EJBException according to the client type...
i have given some scenarios and the idea whic i have in mind.. pleaes let me know whether they are correct...
i'm a bit confused over some descriptions given in some questions regarding the return type of the findByPrimaryKey method....
some says that it should be the local interface of the entity bean and some says that it should be the same as the primary key type...
but what i think is it should be the type of the local component interface if this is a local entity bean or the type of the remote component interface if the entity bean is a remote type...
who is responsible of specifying the transaction-type of an enterprise bean in the dd.
is it the bean provider because if it is BMT then he should implement the beans accordingly... and if it is CMT the application assembler is responsible of specifying the transaction attributes fot the methods...