Enterprise Client Community

Tank you for that promising idea!

Interesting. And this opens a new Webstart instance?

Yes, a whole new instance indeed.

We need to have a completely independent session with own state and everything. And it should be in special mode, so just letting the user start a new instance the normal way would not work (if the user logs in as the same user, this would effectively invalidate the original session).

I think starting a new process is too error prone. Hm, maybe I find something. But thanks nonetheless!

BR

Hi @all,

what is the easiest way to open a new instance with a new session from within the application - ideally with the ability to pass extra arguments.
Thank you very much!

BR

Hi,

I remember some issues when scrolling with an opened combofield popup. AFAIK this has been fixed. But we experience the same problem when the field is inside a popup and this one is moved. What happens is that the combofield popup stays at the exact position, but the rest of the containing moves away. I'll attach a screenshot.

BR

Hi,

I think in general it is a good idea to use the Trusted-* attributes in the manifest:

Code:

The Trusted-Only attribute is used to prevent untrusted classes or resources from being loaded for an applet or application. Set the value of the attribute to true, for example:
 
 Trusted-Only: true
 This attribute prevents a privileged application or applet from being repurposed with untrusted components. All classes and resources in the application or applet must be signed and request all permissions.

So there are security advantages, though they might be of more a theoretical nature.. But you can never know when the JRE behavior is changed and the attributes are important. So at least thinking about the implications is an important step.
And yes, I also think that defaulting to Trusted-Only in CC can have implications in other deployments. :-/

Now back to techi stuff ;-)
Have a look at the Spec (JAR File Manifest Attributes for Security). It explains why the class could not be found: A different classloader is used for the "trusted" JAR's classes, so using Class.forName() for example can be faulty. I think changing some code might overcome implications of using the Trusted-* attributes. But I haven't checked the client's sources.

So for now everything is okay and this thread is kind of a sticky note for everyone who has to sign some JARs:

Resign eclnt.jar to use the above posted example manifest or leave the Trusted-* attributes in you own JAR.

BR

Hi @all,

I recognized that in the eclnt manifest, the attributes

Code:

<attribute name="Trusted-Only" value="true" />
 <attribute name="Trusted-Library" value="true" />

are missing. When I set the those in our own client library (client extensions), but they are not set in the "parent" JAR, you will get errors like the attached one. Note that the default CC class org/eclnt/client/elements/PageElement is not found, as well as our own (Stacktrace says org.eclnt.client.elements.impl.DOWNLOADDOKUMENTElement, but it'n in the package eclntextensions really...).
Please also note the wrong log line "Loading the component from package ecntextensions failed as well", this typo cost us some time. ;-)

Well after all, (read this as 'after I removed the two attributes from our own JAR'), it now seems to work.

Question is, in my opinion, whether the CC library should, as a default, ship with the Trusted-* attributes..? I don't exactly know if this could break other usage scenarios. Do you know more?

I am now thinking about overwriting/extending the default eclnt manifest. Until now I reused when resigning. What do you think?

BR

Alright, thanks for the information!

Any plan supporting any of this?

BR

Ah, I see. Then obviously I mixed up some things. Without explicitly testing (shame on me) I assumed that no operators are supported.

If I understand correctly: State now is that operators appended to the field .{attr >= 5}, but only iff they work with constants.
This means, no prepended operators (empty, which I often use) work and obviously a comparison with other dynamic content is also not possibly, correct?

Hi,

as of now it is not possible to use any EL operators inside grids (e.g. .{x != ""}) . I do understand that this is because the actual EL is calculated by CC.

What I imagine is at least limited recognition of operators, for example those which include only one operand (-, ! not, empty). These could be put at the beginning/end of the resulting EL expression.
Operators with 2 operands are more difficult as constants and references to attributes must be differentiated.

Do you think you can put some effort into this? In my opinion it would be very convenient.

BR

Hi,

is there a fix available to the right-click problem? I am experiencing the problem in the layout editor, which makes it very annoying (how to add components without right click?).

Also, I get some graphic issues like disappearing pixels, for example the Editor Titlebar is hardly readable or text parts of labels and fields are missing. This only occurred together with the right-click-problem. I guess it's connected, but I'm not sure.

I am running version 20141013. Strange thing is that my colleagues don't have this problem.

BR

PS: I added a screenshot showing the "first right click" inside the components tree. As you can see, the entry "Add before" is not complete. This is reproducible.

Hi,

I think both solutions are valid:

Closing the value help would be similar behavior to the combobox, as it also closes when scrolling.

And of course, having the popup attached to the field's position is also correct.

We do not prefer one of these solutions, it should fit to the framework's concept. But the current situation is confusing users. ;-)

BR

Hi,

we experienced a minor problem concerning the value help of combofields:
After the user opened the value help and scrolls outside, then, of course, the site is scrolling. But: The position of the value help is not fix regarding the field's position, but fix on the screen. You could say it is CSS position fixed.
We think that this is not intended?

I attached 2 screen shots to visualize this. We also reproduced this in the demo workspace.

BR

Hi,

this does indeed work. But it somehow seems a bit dirty. ;-)

Was the avoidroundtrips a bad decision?

BR