Ramakrishnan Viswanathan

The table width is fixed to 100%.

Now let us assume that the first Td is 70% (this could vary). What i thought was the second Td will span for the remaining 30%. But this does not happen if the first Td has a width of "auto". If I do not give the width as "auto", the first Td's width does not vary based on the content.

Hi All

I need to create the following structure. I have a table with 1 row having 2 columns.

The first column has content whose width might vary depending on the length of the actual content. The second column needs to span from the end of the first column all the way to the end of the table. The structure that I am trying to build goes something like this.

one css class defined
.columnWidth {width:auto}

<table>
<tr>
<td class="columnWidth">
some content goes in here
</td>
<td>
some other content
</td>
<tr>
</table>


The first column has "auto" width and it expands automatically based on the content inside it. But the second column's width is determined by its content and does NOT actually expand all the way to the end of the table.

Can someone let me know if this is doable? Or is there any other way to solve this problem?

Thanks so much
Ram

Congratulations!

https://coderanch.com/t/161275/java-EJB-SCBCD/certification/reg-ejbRemove

It sounds logical that ejbActivate() and ejbPassivate() methods would get called in response to a client request. However, there are situations where these methods might get invoked by the container. An entity bean can receive a series of passivation and subsequent activation calls while it is in a transaction. This is comlpetely at the discretion of the container. What is guaranteed however, is that the bean always gets an ejbStore() call prior to passivation.

These callbacks do get called as a result of client invocation - but not "always"...

Some more information. Please refer to the "Serialization vs. Remote Object References" subsection at the following place:

http://www.theserverside.com/articles/article.tss?l=ICommerce-Design-Strategies

When an object is serialized in Java, it is the transitive closure of the object that is serialized. The transitive closure is the complete set of all the objects to which an object holds references, and all the objects referenced by those objects.

This post gives a detailed explanation.

transitive closure

https://coderanch.com/t/161195/java-EJB-SCBCD/certification/Java-Beans-Vs-EJBs

It is the container's discretion whether to create one or two EJBObject(s). And each container may do this differently, so this is purely a vendor implementation. There is no guarantee that you have 2 instances created from the same home. What is guaranteed is that calling isIdentical() would return true no matter how the container handles the creation. So you wouldn't really have to know whether the server created two different objects or is just using one.

For stateless beans, the bean-client association happens only during a business method invocation. When an isIdentical() operation is performed, although the client can assume that it is comparing two EJBObject instances, the actual implementation (which is vendor independent) would just result in a comparison of their respective EJBHome-s.

NoSuchEntityException is an exception thrown by the bean to inform the container that the entity is missing. This can happen when the entity is removed (possibly by other means) from the persistent store.

If an attempt is made to invoke a method on an object that no longer exists, a NoSuchObjectLocalException or NoSuchObjectException will be thrown to the local or remote client respectively.

NoSuchEntityException is thrown by the bean to the container
NoSuchObject(Local)Exception is thrown by the container to the remote/local client
[ February 21, 2006: Message edited by: Ramakrishnan Viswanathan ]

I agree with Sathish. It would be a good idea to go through the complete EJB QL chapter in the EJB 2.0 spec in addition to the book(s) that you might be using for preparation.

Answer D is correct.

Please refer to the following section of EJB 2.0 Spec

10.8.3 Special case: Unknown primary key class
_________________________________________________

In special situations, the entity Bean Provider may choose not to specify the primary key class or the primary key fields for an entity bean with container-managed persistence. This case usually happens when the entity bean does not have a natural primary key, and/or the Bean Provider wants to allow the Deployer using the Container Provider�s tools to select the primary key fields at deployment time. The entity bean�s primary key type will usually be derived from the primary key type used by the underlying
database system that stores the entity objects. The primary key used by the database system may not be known to the Bean Provider.

In this special case, the type of the argument of the findByPrimaryKey method must be declared as java.lang.Object. The Bean Provider must specify the primary key class in the deployment descriptor as of the type java.lang.Object.

When defining the primary key for the enterprise bean, the Deployer using the Container Provider�s tools will typically add additional container-managed fields to the concrete subclass of the entity bean class (this typically happens for entity beans that do not have a natural primary key, and the primary keys are system-generated by the underlying database system that stores the entity objects). In this case, the Container must generate the primary key value when the entity bean instance is created (and before
ejbPostCreate is invoked on the instance.)

SCBCD Links

Congrats Devendar!